Not many newlib targets (AFAIK the only targets where
GFC_INTEGER_4 alias int32_t is a typedef of long int)
build libgfortran.
These breaks happen from time to time. I wish there was a
method to stop int32_t (and its typedef-alias GFC_INTEGER_4)
being type-compatible with int. The commit message
Not many newlib targets (IIRC the only targets where
int32_t is a typedef of long int) build libgfortran.
Building and testing fortran testsuite is usually a cheap
way to get additional coverage for a port, except that a
couple of times a year, there are these silly type-related
breakages.
Maybe
Only because I wrote earlier that I'd do this patch.
Committed as obvious. Sanity-checked by running the test in
a native tree as "make check-gcc-fortran
RUNTESTFLAGS=dg.exp=open_errors_2.f90"
-- >8 --
Now that fort.N files are removed by the testsuite
framework, remove this single "manual" file
I forgot to point out that while having my revenge on the
PR116701, I incidentally discovery that
gfortran.fortran-torture contains tests with dg-directives.
Those are ignored. From "git grep dg-":
compile/pr66352.f90:! { dg-additional-options "-fprofile-generate" }
compile/pr85863.f:! { dg-do co
> Date: Wed, 25 Sep 2024 13:51:07 +0200
> From: Andre Vehreschild
> Hi Hans-Peter,
>
> preface: I am not a testsuite nor an m4 expert.
Neither am I. Luckily, this has nothing to do with m4, and
not really that much to do with tcl or dejagnu either, being
just basic code, no language-specific t
Changes since v1:
- Rename gfortran-dg-rmunits to fortran-delete-unit-files.
- Move it to lib/fortran-modules.exp.
- Tweak commit message accordingly and mention cause of placement of
the proc.
- Tweak proc comment to mention why keeping removals unique despite
comment.
Here's a general approa
Thanks for the review!
> Date: Tue, 24 Sep 2024 17:10:27 -0700
> Cc: Jerry D
> From: Jerry D
> On 9/23/24 11:21 PM, Hans-Peter Nilsson wrote:
> > I hope the inclusion of gfortran-dg.exp in
> > fortran-torture.exp is not controversial, but there's no
> > fortra
Here's a general approach to handle PR116701. I considered
adding manual deletions as quoted below and mentioned in the
PR, but seeing the handling of "integer 8" in
fortran-torture-execute I decided to follow that example:
better scan the source for open-statements than relying on
manual annotati
> From: Thomas Koenig via Gcc-patches
> Date: Fri, 22 Apr 2022 15:59:45 +0200
> Hi Mikael,
>
> > Ping for the four patches starting at
> > https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html :
> > https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html
> > https://gcc.gnu.org/pipe
> From: Bernhard Reutner-Fischer
> Date: Thu, 12 Aug 2021 09:03:50 +0200
> On Thu, 12 Aug 2021 00:09:21 +0200
> Hans-Peter Nilsson via Fortran wrote:
>
> > I had a file-path to sources with the substring "new" in it,
> > and (only) this test regressed compa
I had a file-path to sources with the substring "new" in it,
and (only) this test regressed compared to results from
another build without "new" in the name.
The test does
! { dg-final { scan-tree-dump-times "new" 4 "original" } }
i.e. the contents of the tree-dump-file .original needs to match
t
11 matches
Mail list logo
