[Bug fortran/79861] i18n: add translator comment for "%s !$ACC LOOP loops not perfectly nested at %L"

2019-08-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79861

Eric Gallager  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Roland Illig from comment #0)
> from fortran/openmp.c:
> 
> gfc_error ("%s !$ACC LOOP loops not perfectly nested at %L",
>clause, >loc);
> 
> As an i18n translator, I have no idea what could be inserted for the "%s".
> Therefore a /* TRANSLATORS: ... */ comment should explain this by giving one
> or two examples.

svn blame says Thomas Schwinge did this part; cc-ing him

[Bug target/84911] typo: error ("invalid name (\"%s\")

2019-08-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84911

--- Comment #2 from Eric Gallager  ---
(In reply to Roland Illig from comment #0)
> In aarch64.c:
> 
>   error ("invalid name (\"%s\") in % pragma or
> attribute", str);
> 
> 
> Please use %qs instead of "%s"

I'd think -Wformat-diag should catch this first part now?

[Bug target/79870] i18n: combine structurally identical diagnostics

2019-08-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79870

Eric Gallager  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
cc-ing arc maintainer

[Bug target/79646] Typos in vax.opt

2019-08-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646

Eric Gallager  changed:

   What|Removed |Added

 CC||m...@3am-software.com

--- Comment #1 from Eric Gallager  ---
cc-ing vax maintainer

[Bug target/47093] [meta-bug]: broken configurations

2019-08-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47093

--- Comment #3 from Eric Gallager  ---
(In reply to Jeffrey A. Law from comment #2)
> Actually, it's not config-list.ml, though I did use that to help generate
> the list of targets I am testing.  None of them ones I'm testing would fall
> into the category as a "broken configuration".

Do you test with --enable-werror-always at all? Asking because bug 44756 is the
last bug open blocking this meta-bug.

[Bug middle-end/47081] Macro usage too clever for localization

2019-08-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47081

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #3)
> On Tue, 28 Dec 2010, pinskia at gcc dot gnu.org wrote:
> 
> > I don't know if generator files should be have translated error messages. 
> > Unlike other programs, the gen* programs are only used internally inside 
> > gcc.
> 
> If Basile's proposal to install gengtype goes ahead, 

Pretty sure that that did actually go ahead...

> then maybe it should all be properly internationalized.  Otherwise,
> gengtype-state.c should be added to po/EXCLUDES.

[Bug translation/42686] The output of options is not aligned when translate to some language

2019-08-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42686

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
I think there's another bug about this; I forget its number right now though...

[Bug lto/41731] The linker plugin should support translations

2019-08-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41731

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Rafael Avila de Espindola from comment #0)
> Joseph S. Myers says:
> 
> Is this callback interface defined to take translated or untranslated
> text?  If untranslated, there would be a problem with the callback knowing
> which textual domain to use for translation, so I'd guess it should be
> defined to take translated messages.  This means you should be translating
> the messages first, using dgettext to use the right domain (which I think
> should be "gcc" rather than inventing yet another domain for a few
> messages).  You also need to call bindtextdomain - see how cpplib does
> things for an example of one domain being used in a library in a program
> that mainly uses another domain (cpplib and gcc there, gcc and whatever
> domain the linker uses - it appears to be "gold" - here).  Then
> gcc/po/exgettext needs to get the messages extracted for translation into
> gcc/po/gcc.pot.

Where is this from?

[Bug fortran/91537] Memory leak involving nested allocatable derived types

2019-08-24 Thread townsend at astro dot wisc.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91537

--- Comment #3 from Rich Townsend  ---
(In reply to Thomas Koenig from comment #1)
> Comment on attachment 46748 [details]
> Leak demonstration program
> 
> Here's the output on current trunk:
> 
>   862548
>   872548
>   882548
>   892548
>   902548
>   912548
>   922548
>   932548
>   942548
>   952548
>   962548
>   972548
>   982548
>   992548
>  1002548
> 
> Same output with gcc 9.
> 
> So, I think the advice would be to upgrade to gcc 9.

Just tried upgrading, and the leak vanishes as you say. Also fixes the
production code that my example was based on.

Thanks for the quick response!

cheers,

Rich

[Bug c/91539] #pragma omp simd disables -ffp-contract=fast

2019-08-24 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91539

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Alexander Monakov  ---
(closing, not a bug)

[Bug fortran/91390] treatment of extra parameter in a subroutine call

2019-08-24 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Aug 24 21:12:45 2019
New Revision: 274902

URL: https://gcc.gnu.org/viewcvs?rev=274902=gcc=rev
Log:
2019-08-24  Thomas Koenig  

PR fortran/91390
PR fortran/91519
* frontend-passes.c (check_externals_procedure): New
function. If a procedure is not in the translation unit, create
an "interface" for it, including its formal arguments.
(check_externals_code): Use check_externals_procedure for common
code with check_externals_expr.
(check_externals_expr): Vice versa.
* gfortran.h (gfc_get_formal_from_actual-arglist): New prototype.
(gfc_compare_actual_formal): New prototype.
* interface.c (compare_actual_formal): Rename to
(gfc_compare_actual_formal): New function, make global.
(gfc_get_formal_from_actual_arglist): Make global, and move here from
* trans-types.c (get_formal_from_actual_arglist): Remove here.
(gfc_get_function_type): Use gfc_get_formal_from_actual_arglist.

2019-08-24  Thomas Koenig  

PR fortran/91390
PR fortran/91519
* gfortran.dg/bessel_3.f90: Add type mismatch errors.
* gfortran.dg/coarray_7.f90: Rename subroutines to avoid
additional errors.
* gfortran.dg/g77/20010519-1.f: Add -std=legacy. Remove
warnings for ASSIGN. Add warnings for type mismatch.
* gfortran.dg/goacc/acc_on_device-1.f95: Add -std=legacy.
Add catch-all warning.
* gfortran.dg/internal_pack_9.f90: Rename subroutine to
avoid type error.
* gfortran.dg/internal_pack_9.f90: Add -std=legacy. Add
warnings for type mismatch.
* gfortran.dg/pr39937.f: Add -std=legacy and type warnings. Move
here from
* gfortran.fortran-torture/compile/pr39937.f: Move to
gfortran.dg.


Added:
trunk/gcc/testsuite/gfortran.dg/pr39937.f
Removed:
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr39937.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bessel_3.f90
trunk/gcc/testsuite/gfortran.dg/coarray_7.f90
trunk/gcc/testsuite/gfortran.dg/g77/20010519-1.f
trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95
trunk/gcc/testsuite/gfortran.dg/internal_pack_9.f90
trunk/gcc/testsuite/gfortran.dg/pr24823.f

[Bug fortran/91519] [10 Regression] ICE error in 521.wrf_r

2019-08-24 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519

--- Comment #11 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Aug 24 21:12:45 2019
New Revision: 274902

URL: https://gcc.gnu.org/viewcvs?rev=274902=gcc=rev
Log:
2019-08-24  Thomas Koenig  

PR fortran/91390
PR fortran/91519
* frontend-passes.c (check_externals_procedure): New
function. If a procedure is not in the translation unit, create
an "interface" for it, including its formal arguments.
(check_externals_code): Use check_externals_procedure for common
code with check_externals_expr.
(check_externals_expr): Vice versa.
* gfortran.h (gfc_get_formal_from_actual-arglist): New prototype.
(gfc_compare_actual_formal): New prototype.
* interface.c (compare_actual_formal): Rename to
(gfc_compare_actual_formal): New function, make global.
(gfc_get_formal_from_actual_arglist): Make global, and move here from
* trans-types.c (get_formal_from_actual_arglist): Remove here.
(gfc_get_function_type): Use gfc_get_formal_from_actual_arglist.

2019-08-24  Thomas Koenig  

PR fortran/91390
PR fortran/91519
* gfortran.dg/bessel_3.f90: Add type mismatch errors.
* gfortran.dg/coarray_7.f90: Rename subroutines to avoid
additional errors.
* gfortran.dg/g77/20010519-1.f: Add -std=legacy. Remove
warnings for ASSIGN. Add warnings for type mismatch.
* gfortran.dg/goacc/acc_on_device-1.f95: Add -std=legacy.
Add catch-all warning.
* gfortran.dg/internal_pack_9.f90: Rename subroutine to
avoid type error.
* gfortran.dg/internal_pack_9.f90: Add -std=legacy. Add
warnings for type mismatch.
* gfortran.dg/pr39937.f: Add -std=legacy and type warnings. Move
here from
* gfortran.fortran-torture/compile/pr39937.f: Move to
gfortran.dg.


Added:
trunk/gcc/testsuite/gfortran.dg/pr39937.f
Removed:
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr39937.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bessel_3.f90
trunk/gcc/testsuite/gfortran.dg/coarray_7.f90
trunk/gcc/testsuite/gfortran.dg/g77/20010519-1.f
trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95
trunk/gcc/testsuite/gfortran.dg/internal_pack_9.f90
trunk/gcc/testsuite/gfortran.dg/pr24823.f

[Bug c/88944] Suggested alternative C stdbool.h

2019-08-24 Thread jg at jguk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88944

--- Comment #3 from Jonny Grant  ---
Hi Eric, Just ran

gcc (Compiler-Explorer-Build) 10.0.0 20190823 (experimental)


on godbolt.org, but it didn't suggest stdbool.h

https://godbolt.org/z/Bn_o7f

Does it work for you?

[Bug c/91539] #pragma omp simd disables -ffp-contract=fast

2019-08-24 Thread dmatthews at utexas dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91539

--- Comment #2 from Devin Matthews  ---
Indeed the suppression of FMA is from -std=c99 and not the pragma. Sorry for
the noise.

[Bug tree-optimization/91540] Missed optimization: simplification CFG

2019-08-24 Thread zamazan4ik at tut dot by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91540

--- Comment #1 from Alexander Zaitsev  ---
Godbolt playground: https://godbolt.org/z/MFSH1D

[Bug tree-optimization/91540] New: Missed optimization: simplification CFG

2019-08-24 Thread zamazan4ik at tut dot by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91540

Bug ID: 91540
   Summary: Missed optimization: simplification CFG
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zamazan4ik at tut dot by
  Target Milestone: ---

For the code below:

int Test(bool cond1, bool cond2)
{
if (cond1)
{
if (cond2)
{
return 42;
}
}
return 43;
}

gcc(trunk) with '-O3' produces:

Test(bool, bool):
  test dil, dil
  je .L3
  test sil, sil
  jne .L5
.L3:
  mov eax, 43
  ret
.L5:
  mov eax, 42
  ret

clang(trunk) with '-O3' produces:

Test(bool, bool): # @Test(bool, bool)
  mov eax, edi
  and eax, esi
  xor eax, 43
  ret

I think GCC can do it better.

[Bug target/91533] abs pattern generates MMX instructions but fails to call EMMS

2019-08-24 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91533

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-24
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |8.3
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
(In reply to Matthias Kretz from comment #0)
> Test case (cf. https://godbolt.org/z/IfL1mF):
> 
> using V [[gnu::vector_size(8)]] = int;
> 
> V f(V a, long double& x) {
> a = a < 0 ? -a : a;
> x += 1;
> return a;
> }
> 
> Compile with e.g. `-O2 -march=skylake`. This generates a call to `PABSD mm1,
> mm2/m64` but fails to call `EMMS`. It even interleaves the FPU instructions
> with the MMX instructions. GCC 10 has a fix, it simply calls `PABSD xmm1,
> xmm2/m128`.

Yes, I have to backport the fix. MMX patterns should not be named.

[Bug c/91539] #pragma omp simd disables -ffp-contract=fast

2019-08-24 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91539

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
No, -std=c99 or -std=c11 (as opposed to =gnu99/gnu11) disables fp contraction.
If you don't specify any -std= option, -std=gnu11 is default and thus
contraction to fma is enabled.

What are the exact compiler options that give you fmas from autovectorization?
I cannot reproduce this behavior.

[Bug c/91539] New: #pragma omp simd disables -ffp-contract=fast

2019-08-24 Thread dmatthews at utexas dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91539

Bug ID: 91539
   Summary: #pragma omp simd disables -ffp-contract=fast
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmatthews at utexas dot edu
  Target Milestone: ---

When compiling this program:

#include 

void foo(int n,
 const double* restrict a,
 const double* restrict b,
 const double* restrict c,
   double* restrict d)
{
#pragma omp simd
for (int i = 0;i < n;i++)
d[i] = a[i]*b[i]+c[i];
}

void bar(int n,
 const double* restrict a,
 const double* restrict b,
 const double* restrict c,
   double* restrict d)
{
#pragma omp simd
for (int i = 0;i < n;i++)
d[i] = fma(a[i],b[i],c[i]);
}

with gcc 9.2.0 and the options "-std=c99 -fopenmp-simd -O3 -march=core-avx2",
the "bar" function generates FMA instructions but the "foo" function does not.
Explicitly adding "-ffp-contract=fast" restores FMA in "foo". According to the
documentation, "-ffp-contract=fast" should be the default, and indeed
autovectorization (not using the #pragma) will generate FMA instructions
without explicitly specifying this option.

This issue is the same as the optimization issue reported in bug 91511, but is
*not* reflected in bug 61727 of which the former is marked a duplicate.

[Bug target/91520] AVX512 target assembler fails for x86_64 Darwin

2019-08-24 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91520

--- Comment #2 from Iain Sandoe  ---
hmm BZ autodetected "mbox" for the attachment .. it should also be applicable
as a regular diff.

[Bug target/91520] AVX512 target assembler fails for x86_64 Darwin

2019-08-24 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91520

--- Comment #1 from Iain Sandoe  ---
Created attachment 46749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46749=edit
Possible fix by modifying GCC output.


As noted, the LLVM backend is rejecting a disambiguation marker that is not
actually really required (the size of the operands is known when the operands
are registers).

This patch modifies the AVX512 output to omit the unnecessary disambiguation
marker in these cases, and updates the test suite to expect this form of the
instructions.

The patch fixes the fails on Darwin and doesn't regress Linux [at least with
GNU assembler (GNU Binutils for Debian) 2.28].

I suppose it would be possible to guard the changes on TARGET_MACHO and
likewise the tests, but that seems even more mess.

Given that the LLVM backend as been updated to allow the disambiguation markers
on register instructions - an alternative is to require Darwin to use updated
tools (however since most of the folks building on Darwin are using Xcode, they
have to wait for the update to arrive).



So, I am not currently planning on posting this patch for approval - but it is
posted here in case that is the "only solution" for some user.

-

I plan on publishing an update to my alternate assembler/linker pair that
incorporates the changes from LLVM-9 and isn't dependent on the release
schedule for Xcode.

[Bug c++/91538] ICE with generic lambda.

2019-08-24 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91538

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-24
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed, doesn't seem like a regression.

Clearly there's an infinite loop going on:

#1133 0x00ad5ba0 in tsubst (t=,
args=,
complain=0, in_decl=) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:14383
#1134 0x00ad1ed2 in tsubst_decl (t=, 
args=, complain=0) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:13516
#1135 0x00ac8513 in tsubst_pack_expansion (t=, 
args=, complain=0, in_decl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.c:12235
#1136 0x00ad1e24 in tsubst_decl (t=,
args=, 
complain=0) at /home/mpolacek/src/gcc/gcc/cp/pt.c:13507
#1137 0x00ad5ba0 in tsubst (t=,
args=, 
complain=0, in_decl=) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:14383
#1138 0x00ad1ed2 in tsubst_decl (t=, 
args=, complain=0) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:13516
#1139 0x00ac8513 in tsubst_pack_expansion (t=, 
args=, complain=0, in_decl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.c:12235
#1140 0x00ad1e24 in tsubst_decl (t=,
args=, 
complain=0) at /home/mpolacek/src/gcc/gcc/cp/pt.c:13507
#1141 0x00ad5ba0 in tsubst (t=,
args=, 
complain=0, in_decl=) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:14383
#1142 0x00ad1ed2 in tsubst_decl (t=, 
args=, complain=0) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:13516
#1143 0x00ac8513 in tsubst_pack_expansion (t=, 
args=, complain=0, in_decl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.c:12235
#1144 0x00ad1e24 in tsubst_decl (t=,
args=, 
complain=0) at /home/mpolacek/src/gcc/gcc/cp/pt.c:13507
#1145 0x00ad5ba0 in tsubst (t=,
args=, 
complain=0, in_decl=) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:14383
#1146 0x00ad1ed2 in tsubst_decl (t=, 
args=, complain=0) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:13516
#1147 0x00ac8513 in tsubst_pack_expansion (t=, 
args=, complain=0, in_decl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.c:12235
#1148 0x00ad1e24 in tsubst_decl (t=,
args=, 
complain=0) at /home/mpolacek/src/gcc/gcc/cp/pt.c:13507
#1149 0x00ad5ba0 in tsubst (t=,
args=, 
complain=0, in_decl=) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:14383
#1150 0x00ad1ed2 in tsubst_decl (t=, 
args=, complain=0) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:13516
#1151 0x00ac8513 in tsubst_pack_expansion (t=, 
args=, complain=0, in_decl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.c:12235
#1152 0x00ad1e24 in tsubst_decl (t=,
args=, 
complain=0) at /home/mpolacek/src/gcc/gcc/cp/pt.c:13507
#1153 0x00ad5ba0 in tsubst (t=,
args=, 
complain=0, in_decl=) at
/home/mpolacek/src/gcc/gcc/cp/pt.c:14383

[Bug c++/91538] New: ICE with generic lambda.

2019-08-24 Thread tyker at outlook dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91538

Bug ID: 91538
   Summary: ICE with generic lambda.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tyker at outlook dot com
  Target Milestone: ---

the following code make gcc trunk crash

void f() {
auto l = [](auto... args, decltype(args)...){};
l(0);
}

https://godbolt.org/z/kjwbcW

[Bug fortran/91537] Memory leak involving nested allocatable derived types

2019-08-24 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91537

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||9.2.0
 Resolution|--- |FIXED
  Known to fail||8.2.1

--- Comment #2 from Thomas Koenig  ---
I can confirm the failure with gfortran 8, by the way.

[Bug fortran/91537] Memory leak involving nested allocatable derived types

2019-08-24 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91537

--- Comment #1 from Thomas Koenig  ---
Comment on attachment 46748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46748
Leak demonstration program

Here's the output on current trunk:

  862548
  872548
  882548
  892548
  902548
  912548
  922548
  932548
  942548
  952548
  962548
  972548
  982548
  992548
 1002548

Same output with gcc 9.

So, I think the advice would be to upgrade to gcc 9.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

2019-08-24 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #17 from Thomas Koenig  ---
Simply passing on a huge number of arguments is not enough to trigger this.

Here's a perl script to generate test cases:

while ($n=shift)
{
open FOO, ">foo-$n.f90";

print FOO <