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 th
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
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
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 f
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%]
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/Chang
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/ge
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,
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, w
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 s
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/Chan
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 expres
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(-)
d
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
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
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
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
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-base
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.
lib
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
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 m
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 functio
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 (s
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
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
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
* 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} Ty
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.
_Float1
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-dar
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/gc
> 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
> 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
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
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 s
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'
35 matches
Mail list logo
