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 #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 #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 #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 #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 #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
Bug ID: 110644
Summary: Error in gfc_format_decoder
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #10 from Kyle Shores ---
Ah, wait I lied. I must not have recompiled or something because everything
works now. Thank you again for addressing this and sorry for submitting a false
positive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #8 from Kyle Shores ---
Thanks for looking into this. I believe that this worked for you, but for me,
on both my machine and in the docker container, that addition did not fix the
problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #5 from Kyle Shores ---
New C++ source file:
```
#include
#include
#include
#include
#include
#include
extern "C" {
void Finit(void);
void get_names( CFI_cdesc_t * );
}
std::vector extract_names(CFI_cdesc_t* names){
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #4 from Kyle Shores ---
Sure, I'll attempt to remove gtest and cmake. I was merely slimming the example
down from my use case in case it mattered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #3 from Kyle Shores ---
Ah, the specific error message printed at runtime:
Fortran runtime error: Unexpected version 16 (expected 1) in CFI descriptor
passed to dummy argument the_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
Bug ID: 108618
Summary: ISO C-Fortran Interface fails to pass CFI descriptor
version check when using code coverage flags for
fortran
Product: gcc
Version: 13.0
16 matches
Mail list logo
