[Bug ada/58151] "conflict of writable function parameter in construct with arbitrary order of evaluation" is often a spurious error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58151 Patrick Kelly changed: What|Removed |Added CC||p-kell at live dot com --- Comment #3 from Patrick Kelly --- I've faced an almost identical problem. Compilation under -gnat2012 fails with this error. Fallback to -gnat2005, and it reports that functions can only have an "in" parameter, which is correct for -gnat2005; however, they can be used in -gnat2012. Removing the "out" parameter and compiling with -gnat2005 resulted in a correct build. Immediately compiling with -gnat2012 resulted in a correct build. I was lucky in that I didn't actually need the "out" on those parameters. The current behavior is not following the ARM2012. Occurred on GCC 4.8.2.
[Bug ada/59671] New: Improper Ada behavior under -gnat2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59671 Bug ID: 59671 Summary: Improper Ada behavior under -gnat2012 Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: p-kell at live dot com Compilation under -gnat2012 fails with this error: "conflict of writable function parameter in construct with arbitrary order of evaluation" Fallback to -gnat2005, and it reports that functions can only have an "in" parameter, which is correct for -gnat2005; however, they can be used in -gnat2012. Removing the "out" parameter and compiling with -gnat2005 resulted in a correct build. Immediately compiling with -gnat2012 resulted in a correct build. I was lucky in that I didn't actually need the "out" on those parameters. (note: an unused "out" doesn't cause problems in an of itself) The current behavior is not following the ARM2012, which is why I've labeled this as a "blocker". "in out" parameters on functions is one of the major enhancements to Ada 2012. Other compilation flags: "-O2 -gnato -gnatE -fstack-check" Error still occurs without "-O2"
[Bug ada/59671] Improper Ada behavior under -gnat2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59671 Patrick Kelly changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #2 from Patrick Kelly --- Exactly why I marked this as blocker. There is no workaround. -gnat2012 will not compile properly, plain and simple. Adding "out" to a parameter of a function results in this error. Stepping back to -gnat2005 is not a workaround, it's moving to a different language; it's a less severe form of moving from, say Ada to ALGOL. I disagree with this being a duplicate, as the problem in that report, which I read prior to filing this one, is an issue with pragmas behavior, while this is with "out" parameters of functions; these are not the same thing. Two different issues are reporting the same error message; the error message is what is common, not the error.
[Bug ada/59671] Improper Ada behavior under -gnat2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59671 --- Comment #4 from Patrick Kelly --- Let's say I'm trying to build a library/package, tens thousands of lines long, provided by someone else. Is changing every instance of a function with an "out" parameter to a procedure with an "out" parameter, and an additional "out" for what used to be the return, really a workaround? For a convenient little test case, sure, it's a workaround. For real code projects, in no way is the proposed a valid workaround. Just because I happened to encounter this early on in a project, where I could work around it, doesn't mean it wouldn't be encountered late, possibly at release time. Nearly identical, yes, "nearly" having quite an important role in semantics. Code that fits the ARM2012 is not properly compiling under -gnat2012. The "duplicate" bug was in regards to pragmas causing this. This bug is in regards to "out" parameters on functions. I've already stated this. If you consider them to be identical issues, then at this point I ask how? How are directives and subroutines even closely related to each other? I thought I was clear of the steps needed to produce it. Compile, using the flags listed, with a function utilizing an "out" parameter. This would occur even in test packages, in which the function was the only member of the package.
