This is the mail archive of the gcc-bugs@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]

[Bug middle-end/68436] New: [5 Regression] wrong code on x86_64-linux-gnu


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68436

            Bug ID: 68436
           Summary: [5 Regression] wrong code on x86_64-linux-gnu
           Product: gcc
           Version: 5.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36773&action=edit
preprocessed source

[forwarded from https://bugs.debian.org/800543]

last rechecked with 20151028 from the branch.

On line 15054 of the attached preprocessed output of 'file.c', the
following code:

 x->sm.sm_buffer = 0;
 x->sm.sm_object0 = (unzipped ? make_cons(sSAallow_gzipped_fileA,unzipped) :
sLcharacter);
 x->sm.sm_object1 = fn;
 x->sm.sm_int0 = x->sm.sm_int1 = 0;
 (*vs_top++ = (x));
 setup_stream_buffer(x);


referring to the function setup_stream_buffer on line 14810 in the same file:

void
setup_stream_buffer(object x) {



  if (!(!setvbuf(x->sm.sm_fp,x->sm.sm_buffer=({void * v;bool
w=writable_malloc;writable_malloc=1;v=malloc(
# 314 "file.d" 3 4
 8192
# 314 "file.d"
 );writable_malloc=w;v;}),
# 314 "file.d" 3 4
 0
# 314 "file.d"
 ,
# 314 "file.d" 3 4
 8192
# 314 "file.d"
 )))
assert_error("!setvbuf(x->sm.sm_fp,x->sm.sm_buffer=writable_malloc_wrap(malloc,void
*,BUFSIZ),_IOFBF,BUFSIZ)",314,"file.d",__FUNCTION__);

}


is miscompiled at -O3, with the line

 x->sm.sm_buffer = 0;

omitted and optimized away.  Apparently there is some sort of escape
analysis in which the write to x->sm.sm_buffer in setup_stream_buffer is
detected and determined to be side effect free, maybe because 'malloc'
is assumed to have certain properties.  This is GCL, however, which
supplies its own malloc on top of a native garbage collector, which then
fails when examining 'x' with an uninitialized sm.sm_buffer field.

-O2 works fine.

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