Note that works as expected if you change “int” to “volatile int”.
-GregOn Tue, Jan 27, 2015 at 10:43 PM, Greg Fitzgerald gar...@gmail.com wrote:
Yep, still looks like a clang bug to me. I’ll keep digging.
-Greg
On Tue, Jan 27, 2015 at 10:11 PM, gmhwxi gmh...@gmail.com wrote:
Please try (clang -O1) and (clang -O2) on the following code:
#include <stdio.h>
#include <stdlib.h>
#include <setjmp.h>static jmp_buf buf;
void
second(int *p) {
*p = 1000000;
printf(“second: *p = %i\n”, *p);
longjmp(buf,1); // jumps back to where setjmp was called -
making setjmp now return 1
}void
first(int *p) {
second(p);
printf(“first\n”); // does not print
}int main() {
/*
int x = 0;
*/
int p;
p = malloc(sizeof(int));
/
printf(“main: p = %p\n”, p);
*/
if (p == 0)
{
fprintf (stderr, “malloc: failed!\n”); exit(1);
}*p = 0;
if (!setjmp(buf) ) {
first(p); // when executed, setjmp returns 0
} else { // when longjmp jumps back, setjmp returns 1
printf(“main: *p = %i\n”, *p); // prints
}
return 0;
}On Wednesday, January 28, 2015 at 12:59:15 AM UTC-5, gmhwxi wrote:
I thought that I had understood the issue; I apparently did not.
“”“”
All accessible objects have values, and all other components of the
abstract
machine have state, as of the time the longjmp function was called, except
that the
values of objects of automatic storage duration that are local to the
function containing
the invocation of the corresponding setjmp macro that do not have
volatile-qualified type
and have been changed between the setjmp invocation and longjmp call are
indeterminate.
“”“”If you use (clang -O1) to compile the following code and then execute the
generate object code,
you should get:second
main: x = 1000000If you use (clang -O2), you should get
second
main: x = 0I understood this behavior: the value in x is really indeterminate; either
0 or 1000000 is okay.What I do not understand is that you get the same results even if x is
heap-allocated. This does
not follow from the above description: if x is heap-allocated, it is
considered a state; so its content
should not be indeterminate. Right?#include <stdio.h>
#include <setjmp.h>static jmp_buf buf;
void
second(int *p) {
*p = 1000000;
printf(“second\n”); // prints
longjmp(buf,1); // jumps back to where setjmp was called -
making setjmp now return 1
}void
first(int *p) {
second(p);
printf(“first\n”); // does not print
}int main() {
int x = 0;
if (!setjmp(buf) ) {
first(&x); // when executed, setjmp returns 0
} else { // when longjmp jumps back, setjmp returns 1
printf(“main: x = %i\n”, x); // prints
}
return 0;
}On Tuesday, January 27, 2015 at 7:30:59 PM UTC-5, Greg Fitzgerald wrote:
From Reid Kleckner:
So this is almost undoubtedly a setjmp issue. Relevant C standard quote
[7.13.2.1 p5]:“”"
All accessible objects have values, and all other components of the
abstract
machine249)
have state, as of the time the longjmp function was called, except that
the
values of
objects of automatic storage duration that are local to the function
containing
the
invocation of the corresponding setjmp macro that do not have
volatile-qualified type
and have been changed between the setjmp invocation and longjmp call are
indeterminate.
“”"As the variable tmp502 is not declared volatile, its value is
indeterminate. I
think this is working as intended with nothing to do in LLVM.On Tue, Jan 27, 2015 at 2:49 PM, Greg Fitzgerald gar...@gmail.com wrote:
Thanks for doing that work to ensure is in clang and not in
ATS-generated code. I opened a discussion on the llvmdev email list
and added a bug report at llvm.org:http://llvm.org/bugs/show_bug.cgi?id=22360
I’ll keep you posted on progress. Feel free to jump in on the
discussion.-Greg
On Tue, Jan 27, 2015 at 12:11 AM, Hongwei Xi gmh...@gmail.com wrote:
I finally found a way to circumvent the problem.
The following code is taken from:
https://github.com/githwxi/ATS-Postiats/blob/master/src/pats_lintprgm.dats
implement{a}
myintvec_cffgcd
{n}(iv, n) = let
//
var res
: myint(a) = myint_make_int (0)
val p_res = &res
//
// HX-2015-01-27:
// fixing a bug in (clang-3.5 -O2)
//
// HX: a dummy to force clang
// not to optimize the value stored in [res]
val ((void)) = ptr_as_volatile(p_res)
//If the call to ptr_as_volatile is removed, then clang-3.5
may use the (linear) value in [res] repeatedly, causing this
value to be freed more than once.The C code is attached. Searching for ‘pats_as_volatile’ should lead
you to the spot where the bug occurs.On Tue, Jan 27, 2015 at 12:36 AM, Greg Fitzgerald gar...@gmail.com wrote:
As I see it, the chance of fixing such a bug is really next to
none.Fixing clang 3.4 or 3.5? That sounds accurate. But if we move
quickly we might be able to squeeze a fix into 3.6. Can you send me
an isolated C fragment.Thanks,
GregOn Mon, Jan 26, 2015 at 5:58 PM, Hongwei Xi gmh...@gmail.com wrote:
I followed your suggestions.
There were 22M bytes of leaks reported (-fsanitize=address)
There were no undefined behaviors reported (-fsanitize=undefined)Leaks are expected because I turned off GC.
As I see it, the chance of fixing such a bug is really next to
none.On Mon, Jan 26, 2015 at 8:18 PM, Greg Fitzgerald gar...@gmail.com wrote:
Today, I noted that neither (Clang-3.4 -O2) nor (Clang-3.5 -O2)
can
succeed in
compiling ATS2. The patsopt generated by these compilers crashes
immediately.It is expected for this class of error to occur if ATS2 depends on
undefined behavior. For example, if you use memcpy() instead of
memset() to copy overlapping regions, then bumping up to -O2 may
pull
in a vectorized version, which could manifest itself as a memory
corruption. To weed out runtime instances of undefined behavior,
compile and link your code with “-fsanitize=undefined”, and then
run
‘patsopt’ from the command-line. If undefined behavior is
detected,
the runtime will report an error message on stderr.Another useful one is “-fsanitze=address”, which is used the same
way.
Just before segfaulting, it should spit out a stack trace of where
the
memory violation occurred. That might solve your problem as well,
but
for this particular case (upgrading the compiler or enabling more
optimizations) checking for undefined behavior first should be
better
for determining the root cause.-Greg
On Mon, Jan 26, 2015 at 4:05 PM, gmhwxi gmh...@gmail.com wrote:
FYI.
I once used (Clang-3.2 -O2) to compile ATS2 successfully.
Today, I noted that neither (Clang-3.4 -O2) nor (Clang-3.5 -O2)
can
succeed
in
compiling ATS2. The patsopt generated by these compilers crashes
immediately.
However, (Clang-3.5 -O1) can do it. So it is very suspicious
that new
optimizations
added into Clang-3.4 and Clang-3.5 were the cause of this
failure.
This
is a
very
unfortunate situation!For now, (Gcc-4.8 -O2) is the only optimizing compiler that can
compile
ATS2.–
You received this message because you are subscribed to the
Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from
it,
send
an
email to ats-lang...@googlegroups.com.
To post to this group, send email to
ats-l...@googlegroups.com.
Visit this group at
http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit–
You received this message because you are subscribed to the Google
Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to ats-lang...@googlegroups.com.
To post to this group, send email to ats-l...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit–
You received this message because you are subscribed to the Google
Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to ats-lang...@googlegroups.com.
To post to this group, send email to ats-l...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit–
You received this message because you are subscribed to the Google
Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to ats-lang...@googlegroups.com.
To post to this group, send email to ats-l...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit–
You received this message because you are subscribed to the Google
Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to ats-lang...@googlegroups.com.
To post to this group, send email to ats-l...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit–
You received this message because you are subscribed to the Google Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/83e98e70-e320-4d7d-8776-5a6fa2804b94%40googlegroups.com.
