_array_result;
>bool contiguous;
> --
> 2.45.2
>
> Sorry for the breakage.
>
> Regards,
> Andre
>
> On Thu, 11 Jul 2024 11:06:47 +0200
> Richard Biener wrote:
>
> > On Thu, Jul 11, 2024 at 11:04 AM Andre Vehreschild
> > wrote:
> &
On Thu, Jul 11, 2024 at 11:04 AM Andre Vehreschild wrote:
>
> Hi Richard,
>
> I am sorry to hear that. Shall I revert?
I would suggest to instead fix by initializing the variable with NULL
(and a comment).
> - Andre
> On Thu, 11 Jul 2024 10:57:48 +0200
> Richard Biener wro
On Thu, Jul 11, 2024 at 10:54 AM Richard Biener
wrote:
>
> On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild wrote:
> >
> > Hi Harald,
> >
> > thank you very much for ok'ing this large patch. Merged as
> > gcc-15-1965-ge4f2f46e015
> >
&
On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild wrote:
>
> Hi Harald,
>
> thank you very much for ok'ing this large patch. Merged as
> gcc-15-1965-ge4f2f46e015
>
> Looking forward to get (no) bug reports ;-)
This seems to break bootstrap with
../../gcc/gcc/fortran/trans-array.cc: In function
issue by side-stepping the use of a
variable-length typed variable.
> Regtests ok on x86_64-pc-linux-gnu/Fedora 39. Ok for mainline?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankens
On Tue, May 28, 2024 at 9:46 PM Harald Anlauf wrote:
>
> Hi Andre,
>
> On 5/28/24 14:10, Andre Vehreschild wrote:
> > Hi all,
> >
> > the attached patch fixes a memory leak with unlimited polymorphic return
> > types.
> > The leak occurred, because an expression with side-effects was evaluated
On Tue, Mar 26, 2024 at 2:24 AM Jerry D wrote:
>
> On 3/25/24 3:30 PM, Harald Anlauf wrote:
> >> On 3/25/24 12:53 PM, Harald Anlauf wrote:
> >>> I noticed by chance that we have quite a lot of improperly specified
> >>> do-do
> >>> directives in the testsuite.
> >>>
> >>> %
> Am 03.02.2024 um 19:15 schrieb Benson Muite :
>
> On 03/02/2024 19.13, Steve Kargl wrote:
>>> On Sat, Feb 03, 2024 at 02:37:05PM +0100, Richard Biener wrote:
>>>
>>>> Am 03.02.2024 um 01:22 schrieb Steve Kargl
>>>> :
>>>
> Am 03.02.2024 um 01:22 schrieb Steve Kargl
> :
>
> All,
>
> Suppose one is working in a funding-constrained environment
> such as an academician with limited grant funding. If one
> wanted to dabble in GPU offloading with gcc/gfortran, what
> recommendations would one have for minimum
On Fri, Oct 27, 2023 at 4:28 PM Thomas Schwinge wrote:
>
> Hi!
>
> Richard, as the original author of 'SSA_NAME_POINTS_TO_READONLY_MEMORY':
> 2018 commit 6214d5c7e7470bdd5ecbeae668c2522551bfebbc (Subversion r263958)
> "Move const_parm trick to generic code"; 'gcc/tree.h':
>
> /* Nonzero if
On Thu, Oct 12, 2023 at 6:54 PM Paul Richard Thomas
wrote:
>
> I have posted the version 4 of Ian Chivers and Jane Sleightholme's F2008
> compliance table as an attachment to PR39627.
>
> With Harald Anlauf's help it has been updated to correspond to gfortran 13.2.
> In the previous return for
On Thu, 12 Oct 2023, Richard Biener wrote:
> The following handles byte-aligned, power-of-two and byte-multiple
> sized BIT_FIELD_REF reads in SRA. In particular this should cover
> BIT_FIELD_REFs created by optimize_bit_field_compare.
>
> For gcc.dg/tree-ssa/ssa-dse-
The following handles byte-aligned, power-of-two and byte-multiple
sized BIT_FIELD_REF reads in SRA. In particular this should cover
BIT_FIELD_REFs created by optimize_bit_field_compare.
For gcc.dg/tree-ssa/ssa-dse-26.c we now SRA the BIT_FIELD_REF
appearing there leading to more DSE, fully
On Wed, Sep 27, 2023 at 11:48 PM Jeff Law via Fortran
wrote:
>
>
>
> On 9/27/23 12:21, Toon Moene wrote:
>
> >
> > The lto-ing of libgfortran did succeed, because I did get a new warning:
> >
> > gfortran -O3 -flto -flto-partition=none -static -o xlintstrfz zchkrfp.o
> > zdrvrfp.o zdrvrf1.o
On Tue, Sep 26, 2023 at 4:44 PM Lingadahally, Vishakha (2023)
wrote:
>
> Dear GCC Team,
>
> I'm running Ubuntu 22 on my Mac virtually and my gfortran version is 11.4.0.
> When I try to install a certain software package, I encounter the following
> error:
>
> gfortran: error: unrecognized
The GCC 12 branch is now frozen in preparation for a GCC 12.3 release
candidate and the release of GCC 12.3 next week.
All changes require release manager approval.
Quality Data
Priority # Change from last report
--- ---
P1
On Thu, Apr 13, 2023 at 6:43 PM Steve Kargl via Fortran
wrote:
>
> All,
>
> The systems that I've used while hacking on gfortran
> bugs and features are starting to show their age. I'm
> in the early stage of put together the wishlist for
> a budget friendly replacement. While I'll likely go
>
ve
> >> > Does the job and is portable.
> >> >
> >>
> >> I think -frwapv (as suggested by Jakub) would be the better choice.
> >> The problem is the linear congruential pseudo-random number generators
> >> which were much used in earlier times
> Am 10.03.2023 um 18:54 schrieb Thomas Koenig via Fortran
> :
>
> Hello world, here's the patch that was discussed.
>
> Regression-tested. OK for trunk?
>
> Since this appeared only in gcc13, I see no need for a backport.
> I will also document this in the changes file.
The „problem“ is
On Thu, 9 Mar 2023, Thomas Koenig wrote:
> On 08.03.23 22:35, I wrote:
> > On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote:
> >> As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
> >> runs successfully at -O2.
> >
> > I can confirm that.
> >
> >> I presume that
On Wed, 8 Mar 2023, Thomas Koenig wrote:
> On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote:
> > As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
> > runs successfully at -O2.
>
> I can confirm that.
>
> > I presume that this is a serious regression since it
rnflow 0.00 4129984 23.49 2 0.7449
>test_fpu2 0.00 3940944 53.29 2 0.2561
>tfft2 0.00 3622040 36.56 2 0.1026
>
> Geometric Mean Execution Time = 24.33 seconds
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
On Wed, 8 Mar 2023, Paul Richard Thomas wrote:
> The alternative is that the patch be reviewed and committed as it is. I
> have been neglecting my daytime job to get to this point and must spend
> some time catching up.
That works for me as well - I understand the work to be done is on
the
On Wed, 8 Mar 2023, Thomas Koenig wrote:
> On 08.03.23 09:14, Richard Biener wrote:
> > While Fortran is not considered release critical it would be bad to
> > break say the build of SPEC CPU 2017 or Polyhedron very late in the
> > cycle. I'd lean towards postponing
On Wed, 8 Mar 2023, Thomas Koenig wrote:
> Hi Paul,
>
> > Last night, I scoped out the work required to get the patch ready to commit.
> > Sorting out the testcases will be the main load since they have grown
> > "organically". I propose to change over to one test for each paragraph of
> > F2018
On Mon, Feb 20, 2023 at 5:23 PM Tobias Burnus wrote:
>
> Hi Richard, hi all,
>
> On 20.02.23 13:46, Richard Biener wrote:
> > + /* TODO: A more middle-end friendly alternative would be to use
> > NULL_TREE
> > +as upper bound and store the valu
On Mon, Feb 20, 2023 at 12:57 PM Jakub Jelinek wrote:
>
> On Mon, Feb 20, 2023 at 12:48:38PM +0100, Tobias Burnus wrote:
> > On 20.02.23 12:15, Jakub Jelinek wrote:
> > > On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote:
> > > > As mentioned in the TODO for 'deferred', I think we
On Mon, Feb 20, 2023 at 11:05 AM Tobias Burnus wrote:
>
> On 17.02.23 17:27, Steve Kargl wrote:
> > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> >> OK for mainline?
> > Short version: no.
>
> Would you mind to write a reasoning beyond only a single word?
>
> >> subroutine
On Sun, Jan 8, 2023 at 5:21 PM Thomas Koenig wrote:
>
> Hi Richard,
>
> >> Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran
> >> :
> >>
> >> Hi Thomas,
> >>
> >> Following your off-line explanation that the seemingly empty looking
> >> assembly line forces an effective reload from
> Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran
> :
>
> Hi Thomas,
>
> Following your off-line explanation that the seemingly empty looking
> assembly line forces an effective reload from memory, all is now clear.
It’s not a full fix (for register vars) and it’s ‚superior‘
On Tue, Dec 13, 2022 at 5:29 PM Tobias Burnus wrote:
>
> This is a 12/13 regression as come changes to fix the GFC/CFI descriptor
> that went into GCC 12 fail with the (bogus) descriptor passed via by a
> GCC-11-compiled program.
>
> As later GCC 12 changes moved the descriptor to the front end,
On Thu, Dec 8, 2022 at 12:07 PM Richard Biener via Fortran
wrote:
>
> For the testcase in this PR what fold-const.cc optimize_bit_field_compare
> does to bitfield against constant compares is confusing the uninit
> predicate analysis and it also makes SRA obfuscate instead of optimiz
For the testcase in this PR what fold-const.cc optimize_bit_field_compare
does to bitfield against constant compares is confusing the uninit
predicate analysis and it also makes SRA obfuscate instead of optimize
the code. We've long had the opinion that those optimizations are
premature but we do
Status
==
The GCC development branch which will become GCC 13 is now in
bugfixing mode (Stage 3) until the end of Jan 15th.
As usual the first weeks of Stage 3 are used to feature patches
posted late during Stage 1. At some point unreviewed features
need to be postponed for the next Stage
On Mon, Nov 14, 2022 at 10:10 AM Bernhard Reutner-Fischer via
Gcc-patches wrote:
>
> yearly ping. Ok for trunk after re-regtesting?
OK.
> thanks,
>
> On Sun, 31 Oct 2021 13:57:46 +0100
> Bernhard Reutner-Fischer wrote:
>
> > From: Bernhard Reutner-Fischer
> >
> > gcc/fortran/ChangeLog:
> >
>
On Fri, Nov 11, 2022 at 3:13 PM Thomas Schwinge wrote:
>
> Hi!
>
> For example, for Fortran code like:
>
> write (*,*) "Hello world"
>
> ..., 'gfortran' creates:
>
> struct __st_parameter_dt dt_parm.0;
>
> try
> {
> dt_parm.0.common.filename =
>
On Mon, Sep 19, 2022 at 9:31 AM Mikael Morin wrote:
>
> Le 18/09/2022 à 12:48, Richard Biener a écrit :
> >
> >> Does *([1]) count as a pointer dereference?
> >
> > Yes, technically.
> >
> >> Even in the original dump it is already simplified
> 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 :
>>>>
&g
On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin wrote:
>
> Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
> >
> > Hi Mikael,
> >
> >> This adds support for clobbering of partial variable references, when
> >> they are passed as actual argument and the associated dummy has the
> >>
On Sat, Apr 30, 2022 at 1:26 AM Bernhard Reutner-Fischer
wrote:
>
> On Fri, 29 Apr 2022 20:03:55 +0200
> Thomas Koenig wrote:
>
> > On 28.04.22 19:17, Bernhard Reutner-Fischer wrote:
> > > ISTM that this should be s/mod.e/mode./ ?
> >
> > Yep, fixed as obvious and simple on trunk with
> >
On Wed, Apr 27, 2022 at 10:34 PM Thomas Koenig via Fortran
wrote:
>
> Hi,
>
> as we say in German "Nicht documentiert ist nicht gemacht", if
> it is not documented, it wasn't done.
>
> So I thought it would be time to document the changes to the various
> ways of specifying CONVERT before gcc12
On Sat, Apr 16, 2022 at 6:57 PM Mikael Morin via Gcc-patches
wrote:
>
> Hello,
>
> this is a fix for PR102043, which is a wrong code bug caused by the
> middle-end concluding from array indexing that the array index is
> non-negative. This is a wrong assumption for "reversed arrays",
> that is
On Tue, Apr 5, 2022 at 6:12 AM Sandra Loosemore wrote:
>
> On 3/25/22 20:03, Sandra Loosemore wrote:
> > I've got another patch forthcoming (stage 1 material) that adds some new
> > diagnostics for non-rectangular loops during gimplification of OMP
> > nodes. When I was working on that, I
> Am 26.03.2022 um 12:28 schrieb Thomas Koenig :
>
> On 25.03.22 12:34, Jakub Jelinek via Fortran wrote:
>> What is the behavior with a RANGE_EXPR when one has { [0..10] = ++i;
>> }, is that applying the side-effects 11 times or once ?
>
> For side effects during the evaluation of
On Fri, Mar 25, 2022 at 12:34 PM Jakub Jelinek wrote:
>
> On Fri, Mar 25, 2022 at 12:16:40PM +0100, Richard Biener wrote:
> > On Fri, Mar 25, 2022 at 11:13 AM Tobias Burnus
> > wrote:
> > >
> > > On 25.03.22 09:57, Jakub Jelinek via Fortran wrote:
>
On Fri, Mar 25, 2022 at 11:13 AM Tobias Burnus wrote:
>
> On 25.03.22 09:57, Jakub Jelinek via Fortran wrote:
> > On the gfortran.dg/pr103691.f90 testcase the Fortran ICE emits
> >static real(kind=4) a[0] = {[0 ... -1]=2.0e+0};
> > That is an invalid RANGE_EXPR where the maximum is smaller
Status
==
The GCC master branch is now in regression and documentation fixing
mode (Stage 4) in preparation for the release of GCC 13. Re-opening
of general development will happen once we reach zero P1 regressions
which is when we branch for the release. Time wise history projects
that
Status
==
The GCC development branch is open for general bugfixing (Stage 3)
and will transition to regression and documentation fixing only
(Stage 4) on the end of Jan 16th.
Take the quality data below with a big grain of salt - most of the
new P3 classified bugs will become P1 or P2
On Tue, 30 Nov 2021, Mikael Morin wrote:
> On 30/11/2021 14:25, Richard Biener wrote:
> > On Tue, 30 Nov 2021, Mikael Morin wrote:
> >
> >> Le 29/11/2021 ? 16:03, Richard Biener via Gcc-patches a ?crit :
> >>> diff --git a/gcc/fortran/frontend-passes.c b/gcc/f
On Tue, 30 Nov 2021, Mikael Morin wrote:
> Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit :
> > diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
> > index f5ba7cecd54..16ee2afc9c0 100644
> > --- a/gcc/fortran/frontend-passes.c
This fixes an appearant mistake in gfc_insert_parameter_exprs.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
2021-11-29 Richard Biener
gcc/fortran/
* decl.c (gfc_insert_parameter_exprs): Only return after
resetting type_param_spec_list
Status
==
The GCC development branch now is open for general bugfixing (Stage 3).
Take the quality data below with a big grain of salt - most of the
new P3 classified bugs will become P1 or P2 (generally every
regression against GCC 11 is to be considered P1 if it concerns
primary or
On Thu, Nov 11, 2021 at 10:45 AM Jan Hubicka via Gcc-patches
wrote:
>
> > > >
> > > > I think the patch causes the following on x86_64-linux-gnu:
> > > > FAIL: gfortran.dg/inline_matmul_17.f90 -O scan-tree-dump-times
> > > > optimized "matmul_r4" 2
> > >
> > > I get that failure even with
On Wed, Nov 10, 2021 at 4:00 PM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> the testcase tests for out of bound accesses warnings and with ipa-modref
> improvements
> it now triggers a new warning:
>
> /aux/hubicka/trunk-git/gcc/testsuite/gfortran.dg/do_subscript_3.f90:11:9:
> Warning: (1)
>
On Thu, Nov 4, 2021 at 11:05 AM Martin Liška wrote:
>
> On 11/2/21 16:56, Sandra Loosemore wrote:
> > On 11/2/21 9:20 AM, Martin Liška wrote:
> >> On 11/2/21 15:48, Sandra Loosemore wrote:
> >>> On 11/2/21 2:51 AM, Martin Liška wrote:
> On 11/2/21 00:56, Sandra Loosemore wrote:
> > I'll
On Sat, Oct 16, 2021 at 8:24 PM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> >
> > FAIL: gfortran.dg/deferred_type_param_6.f90 -O1 execution test
> > FAIL: gfortran.dg/deferred_type_param_6.f90 -Os execution test
> Sorry for the breakage. This time it seems like bug in Fortran FE
> which
On Mon, Oct 4, 2021 at 12:08 PM Jakub Jelinek via Fortran
wrote:
>
> Hi!
>
> On powerpc64le-linux target, one can select between two incompatible
> long double formats (both of them are 16-byte), __ibm128 which is
> a sum of two doubles, and __float128 (note, not implemented through
>
On Sun, Aug 29, 2021 at 10:07 AM Tobias Burnus wrote:
>
> Hi all, hi Richard,
>
> On 27.08.21 21:48, Richard Biener wrote:
> >> It looks really nice with "-O1 -fno-inline" :-)
> >>The callee 'rank_p()' is mostly optimized and in the
> >>
On Tue, Aug 24, 2021 at 8:47 AM Arjen Markus via Fortran
wrote:
>
> Hi Tobias,
>
> thanks for these tips - this should come in handy indeed.
>
> One thing though: when I tried to run my freshly built gfortran compiler on
> one of the test programs, I got the message that it could not find the
in (or mingw for that) might make GCC development more
painful than necessary. It might be
that using a WSL2 based setup is easier if you're stuck to a Windows
host. Using Linux in a virtual machine
might be another option of course.
Richard.
> Regards,
>
> Arjen
>
> Op vr 20 au
On Fri, Aug 20, 2021 at 9:59 AM Arjen Markus via Fortran
wrote:
>
> I am trying to build the compiler suite to test the two patches Steve Kargl
> posted. But I run into a problem with the mpfr and mpc libraries: the
> linker claims it cannot find them.
>
> I checked this, in fist instance they
On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe wrote:
>
> Hi,
>
> A while ago had a report of build failure against a Darwin branch on
> the latest OS release. This was because (temporarily) the symlink
> from libm.dylib => libSystem.dylib had been removed/omitted.
>
> libm is not needed on
.
Richard.
>From e5a23d54d189f3d160c82f770683288a15c3645e Mon Sep 17 00:00:00 2001
From: Richard Biener
Date: Mon, 9 Aug 2021 13:12:08 +0200
Subject: [PATCH] Adjust volatile handling of the operand scanner
To: gcc-patc...@gcc.gnu.org
The GIMPLE SSA operand scanner handles COMPONENT_REFs that are
not mark
On Wed, 11 Aug 2021, Richard Biener wrote:
> On Tue, 10 Aug 2021, Eric Botcazou wrote:
>
> > > The question is whether we instead want to amend build3 to
> > > set TREE_THIS_VOLATILE automatically when the FIELD_DECL has
> > > it set. At least for the Fortran FE
On Tue, 10 Aug 2021, Eric Botcazou wrote:
> > The question is whether we instead want to amend build3 to
> > set TREE_THIS_VOLATILE automatically when the FIELD_DECL has
> > it set. At least for the Fortran FE cases the gimplifier
> > fails to see some volatile references and thus can generate
>
On Tue, Aug 10, 2021 at 1:41 PM Richard Biener via Gcc-patches
wrote:
>
> The GIMPLE SSA operand scanner handles COMPONENT_REFs that are
> not marked TREE_THIS_VOLATILE but have a TREE_THIS_VOLATILE
> FIELD_DECL as volatile. That's inconsistent in how TREE_THIS_VOLATILE
> testing
s
it set. At least for the Fortran FE cases the gimplifier
fails to see some volatile references and thus can generate
wrong code which is a latent issue.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
2021-08-09 Richard Biener
gcc/
* tree-ssa-ope
Status
==
The GCC 11 branch is now frozen for the upcoming GCC 11.2 release.
All changes require release manager approval now.
Quality Data
Priority # Change from last report
--- ---
P1
P2 260 -
On April 22, 2021 9:09:28 PM GMT+02:00, Michael Meissner
wrote:
>On Wed, Apr 21, 2021 at 10:10:07AM +0200, Tobias Burnus wrote:
>> On 20.04.21 08:58, Richard Biener via Fortran wrote:
>> >On Mon, Apr 19, 2021 at 9:40 PM Michael Meissner via Fortran
>> > wrote:
>>
On Mon, Apr 19, 2021 at 9:40 PM Michael Meissner via Fortran
wrote:
>
> Fix Fortran rounding issues, PR fortran/96983.
>
> I was looking at Fortran PR 96983, which fails on the PowerPC when trying to
> run the test PR96711.F90. The compiler ICEs because the PowerPC does not have
> a floating
On Thu, Mar 18, 2021 at 3:48 PM Tobias Burnus wrote:
>
> Richard,
>
> On 18.03.21 13:35, Richard Biener via Fortran wrote:
> > [...]
> > Since the libgfortran MATMUL should be vectorized
> > I think it's not reasonable to inline any but _very_ small
> > M
On Thu, Mar 18, 2021 at 8:49 AM Steve Kargl via Fortran
wrote:
>
> It seems that gfortran will inline MATMUL with optimization.
> This produce very poor performance. In fact, gfortran will
> inline MATMUL even if one specifies -fexternal-blas. This is
> very bad.
>
> % cat a.f90
> program main
On Wed, Mar 10, 2021 at 8:39 PM mscfd via Fortran wrote:
>
> > which version of gfortran, and which operating system?
> I have seen this on two different Linux distros on x86 with a recently
> compiled version, but also some time ago with an older gfortran 10 version.
>
> Using helgrind on a
73 matches
Mail list logo
