This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

non-volatile automatic variables in setjmp tests


Some setjmp/longjmp tests[1] depend on the value of an auto set before setjmp
to to be retained after returning from the longjmp. As I understand, this
behaviour is actually undefined, according to the gccint manual.

Section 3 "Interfacing to GCC Output" of gccint says:
  If you use longjmp, beware of automatic variables. ISO C says that automatic
  variables that are not declared volatile have undefined values after a
  longjmp. And this is all GCC promises to do, because it is very difficult to
  restore register variables correctly, and one of GCC’s features is that it
  can put variables in registers without your asking it to.
  
However, ISO C says [2]:
  ... values of objects of automatic storage duration are unspecified if they
  meet all the following conditions:
  * They are local to the function containing the corresponding setjmp()
    invocation.
  * They do not have volatile-qualified type.
  * They are changed between the setjmp() invocation and longjmp() call.

Technically this third condition is not satisfied in these tests, as the auto
variable is not modified between the setjmp and longjmp calls. But I'm assuming
the gccint manual overrides this.

gcc.dg/torture/stackalign/setjmp-1.c and
gcc.c-torture/execute/built-in-setjmp.c actually fail at execution for
msp430-elf @ -O1, because the auto being tested after the longjmp has not been
restored correctly.
These tests feature a contrived way of making the auto appear used up to the
longjmp, so I wonder if they have been written deliberately without a
volatile, or if it was just an oversight.
For msp430-elf @ -O1, this code to make the auto appear used is ineffective as
an optimization replaces the variable with a constant, which is what
triggers the test failure.

Are these tests that rely on the value of a non-volatile auto after a longjmp
invalid? I can patch them to make the auto variable a global instead.

Thanks,
Jozef

[1] The C setjmp/longjmp tests using autos:
gcc.c-torture/execute/built-in-setjmp.c
gcc.c-torture/execute/pr60003.c
gcc.dg/torture/pr66101.c
gcc.dg/torture/stackalign/setjmp-4.c
gcc.dg/torture/stackalign/setjmp-3.c
gcc.dg/torture/stackalign/setjmp-1.c
gcc.dg/torture/pr48542.c
gcc.dg/setjmp-4.c
gcc.dg/setjmp-3.c
gcc.dg/tree-prof/pr34999.c
gcc.dg/tree-ssa/pr79803.c

[2] http://pubs.opengroup.org/onlinepubs/009695399/functions/longjmp.html


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]