and `c2`) should be acceptable.
The error goes away if compiled without -Wall, or if the calls to
`mapFunction` are replaced with calls to `mf` directly.
This doesn't occur with gfortran 13.3.0 so appears to be a regression.
-Andrew
--
* Andrew Benson: https://abensonca.github.io
* Gal
ugs/> for instructions.
This only occurs if the FINAL subroutine is ELEMENTAL.
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson
* Galacticus: https://github.com/galacticusorg/galacticus
I've opened PRs for both of these issues:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110548
-Andrew
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson
* Galacticus: https://github.com/galacticusorg/galacticus
On Wed
in ???
#9 0x4016cd in ???
#10 0x2ac992886d0c in ???
#11 0x401128 in ???
Segmentation fault
This appears to be due to the optional argument, helper_. If it is present in
the initial call, i.e.:
call tasker_%compute(helper_)
then this runs without a segfault.
-Andrew
--
* Andrew Benson: https://abensonca.github.io
* Galacticus: https://github.com/galacticusorg/galacticus
y if I:
1. Remove the "counter" variable from type "resourceManager"
2. Add a defined assignment for type "hdf5Object"
3. Change the "outputParameters" variable from a pointer to an allocatable.
--
* Andrew Benson: https://abensonca.github.io
* Galacticus: https://github.com/galacticusorg/galacticus
0 T __beamsm_MOD___final_beamsm_Table_t
> 0580 T __bsam_MOD___final_bsam_Bsa_info_t
> 01e0 T __bsam_MOD___final_bsam_Bsa_t
> 00a0 T __ffn_data_MOD___final_ffn_data_Fe_t
>
> I do not explicitly use finalization nor do I have
> subprograms named __fi
> Supported LTO compression algorithms: zlib
> gcc version 12.1.0 (GCC)
>
>
> What might the compiler be complaining about? Where can I find additional
> info on what to do?
> Any help greatly appreciated
>
> Salvatore
--
* Andrew Benson: https://abensonca.github.io
* Galacticus: https://github.com/galacticusorg/galacticus
eful to anyone;
b) it's indicative of a bug in gfortran;
c) anyone has a more elegant solution!
-Andrew
--
* Andrew Benson: https://abensonca.github.io
* Galacticus: https://bitbucket.org/abensonca/galacticus
11.2.1-20210728/obj-x86_64-redhat-lin
> > ux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver
> > --enable-gnu-indirect-function --enable-cet --with-tune=generic
> > --with-arch_32=i686 --build=x86_64-redhat-linux
> > Thread model: posix
> > Supported LTO compression algorithms: zlib zstd
> > gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC)
> > [sfilippo@lagrange newstuff]$ gfortran -o testfinal testfinal.f90
> > [sfilippo@lagrange newstuff]$ ./testfinal
> >
> > Allocating wrapper
> > Calling new_outer_type
> > Assigning outer%test_item
> > End of new_outer_type
> > DeAllocating wrapper
> > Called delete_test_type
> >
> > -
--
* Andrew Benson: https://abensonca.github.io
* Galacticus: https://github.com/galacticusorg/galacticus
leading brand and I thought that the leading brand was
> wrong.
>
> Give me a day or two and prod me if I do not come up with the goods by the
> end of the week.
>
> Paul
>
>
> On Wed, 15 Sept 2021 at 01:31, Andrew Benson via Fortran <
>
> fortran@gcc.gnu.org
I do not come up with the goods by the
> end of the week.
>
> Paul
>
>
> On Wed, 15 Sept 2021 at 01:31, Andrew Benson via Fortran <
>
> fortran@gcc.gnu.org> wrote:
> > I will (hopefully) have some time in the next few months to work on
> > gfortr
I will (hopefully) have some time in the next few months to work on gfortran.
I could pick up a few easy PRs to fix, but a more ambitious (and more useful)
task would be to work on some of the missing finalizations. For my own work
finalization of function results and stay constructors would be
12 matches
Mail list logo
