* gcc/genrecog.cc (print_nonbool_test): Fix type error of
SUBREG_BYTE
---
gcc/genrecog.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/genrecog.cc b/gcc/genrecog.cc
index 77f8fb97853..319e437e334 100644
--- a/gcc/genrecog.cc
+++ b/gcc/genrecog.cc
@@ -4619,6 +4619,7 @@ pr
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t it the converse that is true?
Assumed shape can be non-contiguous so have to be excluded, but assumed
size are contiguous, so valid candi
Le 18/09/2022 à 12:23, Thomas Koenig a écrit :
I think some of the desired behavior can still be salvaged. For
example, for
(...)
clobbers for the whole array can still be generated, but not for
call foo(a(2),2)
so one would have to look at the lower bound.
Well, my patches were for
This is in spirit a revert of:
r9-3032-gee7fb0588c6361b4d77337ab0f7527be64fcdde2
That commit added a condition to avoid generating ICE with clobbers
of variables with the SAVE attribute.
The test added at that point continues to pass if we remove that
condition now.
PR fortran/87395
From: Harald Anlauf
Before procedure calls, we clobber actual arguments whose associated
dummy is INTENT(OUT). This only applies to procedures with explicit
interfaces, as the knowledge of the interface is necessary to know
whether an argument has the INTENT(OUT) attribute.
This change also ena
This adds support for clobbering of allocatable and pointer scalar
variables passed as actual argument to a subroutine when the associated
dummy has the INTENT(OUT) attribute.
Support was explicitly disabled, but the clobber generation code seems
to support it well, as demonstrated by the newly add
For actual arguments whose dummy is INTENT(OUT), we used to generate
clobbers on them at the same time we generated the argument reference
for the function call. This was wrong if for an argument coming
later, the value expression was depending on the value of the just-
clobbered argument, and we
This is probably the most risky patch in the series.
A previous version of this patch allowing all exactly matching derived
types showed two regressions. One of them uncovered PR106817 for which
I added a fix in this series, and for the other I have excluded
types with allocatable components from
The fortran frontend, as result symbol for a function without
declared result symbol, uses the function symbol itself. This caused
an invalid clobber of a function decl to be emitted, leading to an
ICE, whereas the intended behaviour was to clobber the function result
variable. This change fixes
Hello,
this is the second version of a set of changes around the clobber we
generate in the caller before a procedure call, for each actual argument
whose associated dummy has the INTENT(OUT) attribute.
The clobbering of partial variables (array elements, structure components)
proved to be unsup
This adds support for clobbering of variables passed by reference,
when the reference is forwarded to a subroutine as actual argument
whose associated dummy has the INTENT(OUT) attribute.
This was explicitly disabled and enabling it seems to work, as
demonstrated by the new testcase.
PR fo
This is in spirit a revert of:
r9-3051-gc109362313623d83fe0a5194bceaf994cf0c6ce0
That commit added a condition to avoid generating ICE with clobbers
of ASSOCIATE variables.
The test added at that point continues to pass if we remove that
condition now.
PR fortran/87397
PR fortran/
This change inlines the clobber generation code from
gfc_conv_expr_reference to the single caller from where the add_clobber
flag can be true, and removes the add_clobber argument.
What motivates this is the standard making the procedure call a cause
for a variable to become undefined, which trans
On Wed, 14 Sep 2022 14:53:54 +0200
Jakub Jelinek wrote:
> On Tue, Sep 13, 2022 at 02:03:16PM -0700, Julian Brown wrote:
> > @@ -3440,6 +3437,50 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> > gfc_omp_clauses *clauses, {
> > if (pointer || (openacc && allocatable))
> >
On Sun, Sep 18, 2022 at 08:10:00PM +0100, Julian Brown wrote:
> I don't think any ATTACH clauses can appear during
> the gimplify_adjust_omp_clause_1 walk. So, how about this?
LGTM, thanks.
Jakub
On Wed, 14 Sep 2022 14:44:54 +0200
Jakub Jelinek wrote:
> On Tue, Sep 13, 2022 at 02:03:15PM -0700, Julian Brown wrote:
> > This patch moves GOMP_MAP_ATTACH{_ZERO_LENGTH_ARRAY_SECTION} nodes
> > to the end of the clause list, for offload regions. This ensures
> > that when we do the attach opera
On 18.09.22 12:23, Thomas Koenig via Gcc-patches wrote:
On 18.09.22 11:10, Mikael Morin wrote:
It is unfortunate as there is some desirable behavior within reach here.
I think some of the desired behavior can still be salvaged. For
example, for
subroutine foo(a,n)
integer :: n
Hello,
this patch fixed PR target/99184 which incorrectly rounded during 64-bit
(long) double to 16-bit and 32-bit integers.
The patch just removes the respective roundings from
libf7-asm.sx::to_integer and ::to_unsigned. Luckily, LibF7 does nowhere
use respective functions internally, the
> Am 18.09.2022 um 11:10 schrieb Mikael Morin :
>
> Le 18/09/2022 à 08:12, Richard Biener a écrit :
>>> On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin wrote:
>>>
>>> Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
I have a concern about this part, though. My understandin
On 18.09.22 11:10, Mikael Morin wrote:
Le 18/09/2022 à 08:12, Richard Biener a écrit :
On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin
wrote:
Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
I have a concern about this part, though. My understanding at the
time was that it is not
Hi Dimitar,
This patch broke avr and pru-elf cross builds:
gcc/libgcc/unwind-dw2-fde.c:680:28: error: unknown type name ‘uintptr_t’
680 |uintptr_t *range)
Should uintptr_t be replaced with __UINTPTR_TYPE__? Such change fixes the
above broken builds for me. But
Hi Dimitar,
This patch broke avr and pru-elf cross builds:
gcc/libgcc/unwind-dw2-fde.c:680:28: error: unknown type name ‘uintptr_t’
680 |uintptr_t *range)
Should uintptr_t be replaced with __UINTPTR_TYPE__? Such change fixes the
above broken builds for me. But
Le 18/09/2022 à 08:12, Richard Biener a écrit :
On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin wrote:
Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
I have a concern about this part, though. My understanding at the
time was that it is not possible to clobber an individual array
el
When the -fzero-call-used-regs command line option is used with an
unsupported value, indicate that it's a value problem instead of an
option problem.
Without the patch, the error is:
In file included from gcc/testsuite/c-c++-common/zero-scratch-regs-8.c:5:
gcc/testsuite/c-c++-common/zero-scratch-
On Fri, Sep 16, 2022 at 12:19:36PM +0200, Thomas Neumann via Gcc-patches wrote:
> The __register_frame/__deregister_frame functions are used to register
> unwinding frames from JITed code in a sorted list. That list itself
> is protected by object_mutex, which leads to terrible performance
> in mul
On 8/6/22 21:20, Thomas Schwinge wrote:
Hi Tom!
Hi Thomas,
thanks for doing this.
Series approved.
As I mentioned, I'm not completely happy with the multilib name, but I
don't think it makes sense to post-pone approval for this.
Thanks,
- Tom
Ping.
Grüße
Thomas
On 2022-07-27T17:4
On Fri, 02 Sep 2022 18:28:10 PDT (-0700), Palmer Dabbelt wrote:
We don't yet support vectorization on RISC-V.
gcc/testsuite/ChangeLog
* gcc.dg/tree-ssa/gen-vect-34.c: Skip RISC-V targets.
---
gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Fri, 09 Sep 2022 02:46:40 PDT (-0700), Palmer Dabbelt wrote:
I just happened to stuble on this one while trying to sort out the
RISC-V bits.
gcc/ChangeLog
* doc/tm.texi (TARGET_C_EXCESS_PRECISION): Add 16.
---
gcc/doc/tm.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
Hi Jakub,
The last version of this patch was slightly adapted to the latest changes of the
device-specific environment variable syntax
(https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601145.html), also
considering the latest related bug fixes (commits 994ea892bd02d and
7d37c7f67c1bb).
Pushed. We can address any further changes as follow-ups.
Thanks.
Aldy
On Fri, Sep 16, 2022 at 3:26 PM Aldy Hernandez wrote:
>
> On Fri, Sep 16, 2022 at 10:33 AM Richard Sandiford
> wrote:
> >
> > Aldy Hernandez via Gcc-patches writes:
> > > On Thu, Sep 15, 2022 at 9:06 AM Richard Biener
> >
30 matches
Mail list logo
