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
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
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
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 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
21 matches
Mail list logo
