Argument passing / atoi conversion sensitivity to compiler output about rev HOT 9 CLOSED

Additional comment: This reproducer fails when the args are not used so the use case is uninteresting and probably should be low priority. However, the original failure was a complex bit of code where adding 1 instruction to an inline assembly function would cause a crash but only on mem-hierarchy model. I think that is probably a separate problem related to dependencies for compact instructions.

Bottom line, I don't think it's worth spending too much time on this case unless I have a more interesting reproducer that shows the original sensitivity I was seeing. I just wanted to make sure this was documented in case others run into problems with command line arguments.

from rev.

This issue is becoming higher priority. I'm not sure if the problem is the args or the atoi function misbehaving.

from rev.

Is this C or CXX?

from rev.

It is CXX. The source suffix should be changed to .cc.

from rev.

ok, perfect. I think we can relegate this to being CXX only.

from rev.

Looking more like a memory corruption issue. In updown-accel/ud-sys-devel I have a more robust workaround by providing a system call that gives back each argv from the internally stored vector. If this would be helpful in the main rev repo I can create a PR for it.
Usage:
int argv1 = rev::atoi_argv(1);
int argv2 = rev::atoi_argv(2);
int argv3 = rev::atoi_argv(3);

from rev.

I added more checks in the test and provided an annotated trace that shows where argv[2][0] is referenced to check it's initial char value and where the reference is clobbered in the atoi code. Subsequent usage of the value referenced leads to the crash. See argc_bug.trace_annotated. Search for '###' for comments and '!!!' for errant behavior. This was run using macOS but the Ubuntu run is similar.

from rev.

Verified PR #288 fixes this bug. Will close when PR is approved and merged into devel branch

from rev.

confirmed

from rev.