Is anyone else seeing this?
Running /home/jerry/dev/gcc14/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/bind-c-contiguous-1.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal
compiler error: Segmentation fault)
FAIL: gfortran.dg/bind-c-con
How can I get a free Fortran 99 compiler without so much protocol, it
is to practice and update my knowledge, thank you.
Le 08/01/2025 à 18:23, Andre Vehreschild a écrit :
First of all the recursive attr must not be set on vtypes, neither on module
ones nor anywhere else. Strictly speaking is a vtype recursive, because by its
extends member it references itself through a pointer. But it is guaranteed
that the base
Le 08/01/2025 à 18:37, Jakub Jelinek a écrit :
On Wed, Jan 08, 2025 at 06:23:40PM +0100, Andre Vehreschild wrote:
gcc/fortran/ChangeLog:
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Prevent additional run
over (un-)signed ints and assign kind directly.
---
Am 08.01.25 um 19:18 schrieb Steve Kargl:
While working on f_c_string(), it never occurred to me
that the version number should have been bumped. Thanks
for the sleuthing you've done so far.
Same for me!
Best regards
Thomas
On Wed, Jan 08, 2025 at 10:33:53AM +0100, Jakub Jelinek wrote:
>
> As mentioned in the PR, there is a *.mod incompatibility between GCC 14 and
> GCC 15, at least when using iso_c_binding or iso_fortran_env intrinsic
> modules, because new entries have been added to those modules in the middle,
> c
On Wed, Jan 08, 2025 at 06:23:40PM +0100, Andre Vehreschild wrote:
> gcc/fortran/ChangeLog:
>
> PR fortran/118337
> * module.cc (use_iso_fortran_env_module): Prevent additional run
> over (un-)signed ints and assign kind directly.
> ---
> gcc/fortran/module.cc | 13 ++---
Hi all,
I like to take Jakub's patch a little bit further and add two things, that
annoy me:
First of all the recursive attr must not be set on vtypes, neither on module
ones nor anywhere else. Strictly speaking is a vtype recursive, because by its
extends member it references itself through a po
On Wed, Jan 08, 2025 at 04:34:18PM +0100, Jakub Jelinek wrote:
> I'm testing for that instead:
> --- gcc/module.cc.jj 2025-01-08 15:23:54.511732946 +0100
> +++ gcc/module.cc 2025-01-08 16:32:14.963984426 +0100
> @@ -7122,9 +7122,11 @@ use_iso_fortran_env_module (void)
>
>i = 0;
> #defin
On Wed, Jan 08, 2025 at 04:09:36PM +0100, Andre Vehreschild wrote:
> One of the issues are lines:
>
> module.cc 7125-7130: Here it is assumed that the signed and unsigned types are
> adjacent maybe?!
>
> I have changed this:
>
> diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
> index
One of the issues are lines:
module.cc 7125-7130: Here it is assumed that the signed and unsigned types are
adjacent maybe?!
I have changed this:
diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
index c4312b641c1..05bc802957e 100644
--- a/gcc/fortran/module.cc
+++ b/gcc/fortran/module.
On Wed, Jan 08, 2025 at 03:48:46PM +0100, Andre Vehreschild wrote:
> Hi,
>
> I have added this small patch (attached). Unfortunately I got regressions
>
> some in iso_fortran_env_8.f90
> and several in unsigned_NN.f90 tests.
>
> Just retesting w/o my patch and already seeing the iso_fortran_env
Hi,
I have added this small patch (attached). Unfortunately I got regressions
some in iso_fortran_env_8.f90
and several in unsigned_NN.f90 tests.
Just retesting w/o my patch and already seeing the iso_fortran_env one again.
I am also not totally sure, that I applied both your patches correctly.
On Wed, Jan 08, 2025 at 03:16:46PM +0100, Mikael Morin wrote:
> I think your patch is enough, we don't need to target same-bytes formats
> between module versions.
I can confirm the ICE on the small reproducer I've posted is gone with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/6729
Le 08/01/2025 à 14:13, Jakub Jelinek a écrit :
On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote:
Le 08/01/2025 à 11:42, Jakub Jelinek a écrit :
The full list of changes with the posted patches is
(first a.mod, then b.mod, 14 -> 15) below.
I have no idea what adds those __copy_* elt
On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote:
> Le 08/01/2025 à 11:42, Jakub Jelinek a écrit :
> >
> > The full list of changes with the posted patches is
> > (first a.mod, then b.mod, 14 -> 15) below.
> > I have no idea what adds those __copy_* elts etc. and whether they could be
Le 08/01/2025 à 11:42, Jakub Jelinek a écrit :
The full list of changes with the posted patches is
(first a.mod, then b.mod, 14 -> 15) below.
I have no idea what adds those __copy_* elts etc. and whether they could be
forced to be in the middle rather than at the end and what is an ABI break
and
Le 08/01/2025 à 12:16, Andre Vehreschild a écrit :
That sounds like a feasible solution when finding the erroneous (to my belief)
setting of flag takes longer than expect.
Mikael, do you know your way around the module export stuff and can you point
me directly to the line in question? I haven't
On Wed, Jan 08, 2025 at 12:42:39PM +0100, Andre Vehreschild wrote:
> Er, call me stupid, but what is the easiest way to apply your patch? 'git am'
> on
> the part from the date-line to the end stripping your greetings, always leads
> to unrecognized patch format. Using `patch -p1` did not work eit
Er, call me stupid, but what is the easiest way to apply your patch? 'git am' on
the part from the date-line to the end stripping your greetings, always leads
to unrecognized patch format. Using `patch -p1` did not work either. What am I
not seeing?
- Andre
On Wed, 8 Jan 2025 10:44:50 +0100
Jakub
That sounds like a feasible solution when finding the erroneous (to my belief)
setting of flag takes longer than expect.
Mikael, do you know your way around the module export stuff and can you point
me directly to the line in question? I haven't worked in that area. Just
asking. If you don't know
On Wed, Jan 08, 2025 at 11:53:53AM +0100, Andre Vehreschild wrote:
> Well, thinking about it, it smells like a side-effect of the 116669 fix. A
> type
> getting the recursive marker enforces the generation of the vtype for it. I
> don't see yet, why the iso_c_binding_C_funptr should be marked as r
Ok, I was merely asking, if I need to stop my current fault finding immediately
and fix it within the next hours, or if a fix is ok by say beginning of next at
latest.
I will finish my current fault finding and then extend your patch.
- Andre
On Wed, 8 Jan 2025 12:04:15 +0100
Jakub Jelinek wrot
Hello,
Le 08/01/2025 à 11:34, Andre Vehreschild a écrit :
The flag is used now to indicate, that a type can (indirectly) reference
itself. Not having the marker lead to endless recursion during construction of
copy or deallocate operations on an object of the type.
Can it be removed from the
Well, thinking about it, it smells like a side-effect of the 116669 fix. A type
getting the recursive marker enforces the generation of the vtype for it. I
don't see yet, why the iso_c_binding_C_funptr should be marked as recursive. I
will investigate. How much time do I have?
- Andre
On Wed, 8 J
On Wed, Jan 08, 2025 at 11:34:35AM +0100, Andre Vehreschild wrote:
> marking the vtypes as recursive is odd, but should not be taken as any
> incompatibility marker. Pre version 15 gfortran does not check the recursive
> attr on types. So whether it is set or not, is of no concern to gfortran <=
>
Hi and best wishes to all for this new year.
I would like to know if there is a way to track kernel execution at run
time when offloading with openMP target in gfortran 14 (Nvidia GPU).
I mean identifying the kernel (file and line number), the amount of data
transferts, the time spent in the
Hi Jakub,
marking the vtypes as recursive is odd, but should not be taken as any
incompatibility marker. Pre version 15 gfortran does not check the recursive
attr on types. So whether it is set or not, is of no concern to gfortran <= 14.
The pr that motivated the change
is: https://gcc.gnu.org/bug
On Wed, Jan 08, 2025 at 10:47:39AM +0100, Richard Biener wrote:
> I wonder if we can somehow add some test coverage? Are .mod files
> target independent and thus can we include them in the testsuite?
They are, but they are compressed and having binary data in the testsuite
is a problem. But perh
On Wed, Jan 8, 2025 at 10:45 AM Jakub Jelinek wrote:
>
> Hi!
>
> Based on the comments in the PR, I've tried to write a patch which would
> try to keep backwards compatibility with the GCC 11-14 *.mod files.
>
> Testcase was
> module a
> use, intrinsic :: iso_c_binding
> end module a
> module b
Hi!
Based on the comments in the PR, I've tried to write a patch which would
try to keep backwards compatibility with the GCC 11-14 *.mod files.
Testcase was
module a
use, intrinsic :: iso_c_binding
end module a
module b
use, intrinsic :: iso_fortran_env
end module b
and zcat a.mod; zcat b.mo
Hi!
As mentioned in the PR, there is a *.mod incompatibility between GCC 14 and
GCC 15, at least when using iso_c_binding or iso_fortran_env intrinsic
modules, because new entries have been added to those modules in the middle,
causing changes in the constants emitted in the *.mod files.
Also, I
On Wed, 8 Jan 2025, Jakub Jelinek wrote:
> On Wed, Jan 08, 2025 at 09:14:59AM +0100, Eric Botcazou wrote:
> > > So, this patch is an alternative to the
> > > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html
> > > patch, which had the major problem that it required changing all t
May be add a feature request PR for this for Ada and Fortran to prevent us
from forgetting to evaluate the necessity or ability to provide that
flag/information?
Sorry for me using a wrong term or expression above. I have not yet any
knowledge or gotten in touch with DWARF stuff.
- Andre
On Wed,
On Wed, Jan 08, 2025 at 09:14:59AM +0100, Eric Botcazou wrote:
> > So, this patch is an alternative to the
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html
> > patch, which had the major problem that it required changing all the
> > DWARF consumers to be able to debug C17 or
35 matches
Mail list logo
