https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
Kyle Shores changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #25 from Kyle Shores ---
Ah, I see what you mean. Thank you for pointing this out. Closing now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #24 from Alberto Luaces ---
Hi, I am not a gfortran developer nor I am asking for a minimal working example
whatsoever.
I was just stating that the problem could have disappeared, and I tried just
building your whole software (succe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #23 from Kyle Shores ---
Alberto, I ended up making a PR last year which allowed tuv-x to compile with
gcc 13 (https://github.com/NCAR/tuv-x/pull/53). This involved reordering use
statements/moving them out of subroutine/function def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #22 from Alberto Luaces ---
Kyle, can you try again on your side?
Following your instructions on 2024/03/08, I checked out tuv-x version from
2024/03/04 and compiled it without problems, using gfortran 14.2.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #21 from Steve Kargl ---
On Fri, Mar 08, 2024 at 08:01:02PM +, kyle.shores44 at gmail dot com wrote:
>
> (In reply to Steve Kargl from comment #19)
> >
> > It seems your code is hitting a NULL pointer dereference when
> > gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #20 from Kyle Shores ---
(In reply to Steve Kargl from comment #19)
> On Fri, Mar 08, 2024 at 05:42:05PM +, kyle.shores44 at gmail dot com
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
> >
> > --- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #19 from Steve Kargl ---
On Fri, Mar 08, 2024 at 05:42:05PM +, kyle.shores44 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
>
> --- Comment #17 from Kyle Shores ---
> I was able to get tuv-x to co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #18 from Kyle Shores ---
(In reply to Steve Kargl from comment #16)
> On Fri, Mar 08, 2024 at 04:44:52PM +, kyle.shores44 at gmail dot com
> wrote:
> > I have not made a smaller example, but we have since removed json-fortran
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #17 from Kyle Shores ---
I was able to get tuv-x to compile by putting use statements in problematic
files at the top of the module. In one case, I had to match the use ordering to
the order that the objects were used in the module (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #16 from Steve Kargl ---
On Fri, Mar 08, 2024 at 04:44:52PM +, kyle.shores44 at gmail dot com wrote:
> I have not made a smaller example, but we have since removed json-fortran as a
> dependency for tuv-x.
>
> So it should be ea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #15 from Kyle Shores ---
To reiterate how this issue can sometimes be resolved, if I take use statements
out of subroutines and place them at the top of a module, files can then be
compiled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #14 from Kyle Shores ---
I have not made a smaller example, but we have since removed json-fortran as a
dependency for tuv-x.
So it should be easier to view the failure in tuv-x. I have not made the time
to try to reduce the code to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #13 from Jerry DeLisle ---
Any luck getting a reduced case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #12 from Alberto Luaces ---
It seems to be slightly different:
(gdb) p expr->ts.type
$7 = BT_PROCEDURE
(gdb) p expr->symtree->name
$8 = 0x770244e8 "@1179"
(gdb) p expr->where
$9 = {nextc = 0x0, lb = 0x0}
Maybe it will be clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #11 from Steve Kargl ---
On Fri, Oct 20, 2023 at 03:13:06PM +, aluaces at udc dot es wrote:
> Ok, indeed they were some warnings. I had to use &gfc_current_locus, as you
> suggested, so now all of them are pointed at the end of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #10 from Alberto Luaces ---
Ok, indeed they were some warnings. I had to use &gfc_current_locus, as you
suggested, so now all of them are pointed at the end of the file.
Yes, I am using OOP: we have a "states" class that has its as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #9 from Steve Kargl ---
On Thu, Oct 19, 2023 at 04:00:10PM +, aluaces at udc dot es wrote:
>
> No, I meant building *gcc* with those flags, but alas each gcc compilation
> stage was still building with "-O2" so almost all of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #8 from Alberto Luaces ---
No, I meant building *gcc* with those flags, but alas each gcc compilation
stage was still building with "-O2" so almost all of the compiler structures
are still optimized.
Nevertheless I did what you sugg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #7 from Steve Kargl ---
On Thu, Oct 19, 2023 at 08:00:27AM +, aluaces at udc dot es wrote:
>
> It says something about a non-recursive function likely calling itself. I
> will
> inspect my source, even it is a bit too big. Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #6 from Alberto Luaces ---
Thanks a lot for the guidance. This is the backtrace of the last call to
gcc_assert() that makes it crash.
It says something about a non-recursive function likely calling itself. I will
inspect my source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #5 from Steve Kargl ---
On Wed, Oct 18, 2023 at 03:56:32PM +, aluaces at udc dot es wrote:
> --- Comment #4 from Alberto Luaces ---
> I got the same error in almost the same circumstances (crash in
> error.cc:1078).
>
> I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
Alberto Luaces changed:
What|Removed |Added
CC||aluaces at udc dot es
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #3 from Kyle Shores ---
I'll try to create a smaller example, but as y'all know this can be hard...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
Ever c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
26 matches
Mail list logo
