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 (genera
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 to
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 tha
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 the gfortran.dg/pr103691.f90 testcase
> 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 expression,
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 discove
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 ar
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 we
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
> > r13-49-
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
> >> INTENT(
> 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 Mon, Sep 19, 2022 at 9:31 AM Mikael Morin wrote:
>
> Le 18/09/2022 à 12:48, Richard Biener a écrit :
> >
> >> Does *(&a[1]) count as a pointer dereference?
> >
> > Yes, technically.
> >
> >> Even in the original dump it is already simplified to a straight a[1].
> >
> > But this not anymore.
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 =
> &"source-gcc/libgomp/test
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:
> >
> >
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 1.
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
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
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, t
> 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 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
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 foo(n
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 real
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 value, e.g. as GFC_DECL_STRING_LEN.
> > +
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 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 this to early stage1 and event
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 testsu
On Wed, 8 Mar 2023, Paul Richard Thomas wrote:
> Hi All,
>
> I ran the polyhedron testsuite with the patched gfortran-13.0.1 and 7.4(as
> used in the posted Linux test). The timings are comparable except for
> rnflow.f90.
>
> As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 bu
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 involv
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 thi
> 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 l
On Wed, 15 Mar 2023, Paul Richard Thomas wrote:
> Hi All,
>
> I am awaiting a green light to commit this patch or not.
I'd say go ahead.
Richard.
> Cheers
>
> Paul
>
>
> On Fri, 10 Mar 2023 at 16:49, Paul Richard Thomas <
> paul.richard.tho...@gmail.com> wrote:
>
> > Hi Thomas,
> >
> >
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
> w
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 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 argume
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 zdrvr
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 simp
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 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
> >
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 poin
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 Wed, Jun 2, 2021 at 12:47 PM Julian Brown wrote:
>
> For historical reasons, it seems that extract_base_bit_offset
> unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF
> nodes from component accesses. I verified that the two ways of performing
> the operation gave the same re
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 on GENERIC refs works which requires operand zero of
component references to mirror TREE_THIS_VOL
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 on GENERIC refs
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 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 cases the gimplifier
> > > fails
On Wed, 11 Aug 2021, Eric Botcazou wrote:
> > So I'm leaning towards leaving build3 alone and fixing up frontends
> > as issues pop up.
>
> FWIW fine with me.
OK, so I pushed the original change (reposted below).
Bootstrapped / tested on x86_64-unknown-linux-gnu.
Richard.
>From e5a23d54d189f3
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 Darwin,
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 wer
On Fri, Aug 20, 2021 at 12:55 PM Arjen Markus wrote:
>
> Okay, that solved that error, now I get:
>
> -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
> -fdiagnostics-show-location=once -ffunction-sections -fdata-sections
> -frandom-seed=fs_ops.lo -fimplicit-templates -g -O2 -c
> ../../..
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 file
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
> >>caller only those struct elements are set, which ar
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
> libquadmath)
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 wa
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 w
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)
> /a
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 d70
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 second
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.
---
g
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
> > +++ b/gcc/fortran/frontend
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/fortran/frontend-passes.c
> >>> index
60 matches
Mail list logo
