In D151271#4368998, @vzakhari wrote:

Just for thought, I would only implement the memcmp check at the place the temporary for the constant is created.

Unfortunately, there is no currently a way to detect whethe the temporary copy is created for a constant. The temporary copy and the copy-in/copy-out code are created inside sub around the call to sub2, and at this point i is just a regular dummy argument.

I would like to proceed with this commit, if you do not mind.  I will create a github issue for the runtime check feature.  Does it sound acceptable to you?

Aha. I see where the difficulty lies now, but isn't this approach causing all possible attempts to define an undefinable entity to just be silently ignored? Or is there some comparison done at the completion of a call to detect whether the temporary copy was (re/un)defined? If not I think something to that effect should be added (possibly conditioned on certain compiler flags for run-time checking).

In D151271#4368507, @vzakhari wrote:

In D151271#4366595, @everythingfunctional wrote:

A program that did this would be invalid. Wouldn't you want it to crash, rather than silently do something else?

Please note that the there is no definition/redefinition of i inside sub2.

It depends on what sub2 tries to do with i. Putting the relevant pieces together:

A program that did this would be invalid. Wouldn't you want it to crash, rather than silently do something else?

In D150159#4346752, @klausler wrote:

In D150159#4346067, @everythingfunctional wrote:

I'm fairly sympathetic to @MehdiChinoune 's argument here. You're essentially asking an open-source community to support your proprietary technology. Maybe it's widely enough used that it deserves to be (I'm at least open to the argument), but you should definitely be open and upfront about wanting to do that, and ask the community through the proper procedures first. I think it would have a been a violation of the community's trust if it had been approved and made it into the official repository without anybody outside Nvidia having a chance to comment. Maybe I missed it, but I don't remember hearing about this plan before the patches got submitted. And based on the number of reviewers listed here, it doesn't look like you were trying to publicise it very broadly.

I've left these reviews open for comment for a long time, and will continue to do so to collect relevant comments from people who actually participate in the project.

I'm fairly sympathetic to @MehdiChinoune 's argument here. You're essentially asking an open-source community to support your proprietary technology. Maybe it's widely enough used that it deserves to be (I'm at least open to the argument), but you should definitely be open and upfront about wanting to do that, and ask the community through the proper procedures first. I think it would have a been a violation of the community's trust if it had been approved and made it into the official repository without anybody outside Nvidia having a chance to comment. Maybe I missed it, but I don't remember hearing about this plan before the patches got submitted. And based on the number of reviewers listed here, it doesn't look like you were trying to publicise it very broadly.

The generics subgroup actually would like to allow scalar arguments to these procedures. It would be an extension for now, but is likely to be standards conforming at some point in the future.

Update with main to see if tests have been fixed.

Address conflicts with main branch and fix new tests

rebase to get fix for build/test failure

Fix the flang program path