On Tue, Jun 18, 2013 at 4:59 PM, Glenn Fowler <[email protected]> wrote: > > On Tue, 18 Jun 2013 15:24:27 +0200 Roland Mainz wrote: >> On Tue, Jun 18, 2013 at 4:34 AM, Glenn Fowler <[email protected]> wrote: >> > >> > ast-ksh alpha 2013-06-13 source posted to >> > http://www.research.att.com/sw/download/alpha/ >> > >> > still a work in progess, but progress has been made in the >> > handling of signals in libast/vmalloc and ksh >> > >> > more comments later this morning ... > >> Thanks... :-) > >> ... here are some build warnings which may trigger issues with some >> compilers (warnings are from SuSE 12.3/AMD64/64bit build with gcc >> 4.7): >> -- snip -- >> 1. Build warnings in the memory allocation subsystem (note: the >> "strict-aliasing" warnings are very important and can trigger major >> issues with "clang"): >> /home/test001/work/ast_ksh_20130613/build_i386_64bit_opt/src/lib/libast/vmalloc/vmbest.c: >> In function 'chktree': > > right, code malloc without aliasing and pointer punning ...
Mhhh... aliasing occurs when the compiler has two different pointers to the same chunk of memory... and by (type-)casting a pointer you are generating a new (temporary) pointer. Things may go wrong badly if the optimiser reorders the machine instructions (for example) and issues something like a read before a write to the same address (through different (temporary) pointers). This is why gcc complains and "clang"-build executables trip over such issues. The problem is now... this is a |union| ... the mortal enemy of strict aliasing... ;-( See http://dbp-consulting.com/tutorials/StrictAliasing.html for general help... > do you recall if we got rid of the strict-aliasing warnings in the previous > vmalloc implementation? No... not without diffing all the sources release-by-release... that's where svn/git/etc. with something like LXR, GitWeb or (preferably) OpenGrok (should I start ranting about BugZilla ? ;-(( ) would be very very usefull... ;-/ ... grrr... digging.... ... grrr... digging.... ... grrr... digging.... ... grrr... digging.... ... the only one I could find was... -- snip -- 10-11-10 regex/regnexec.c,vmalloc/vmstat.c: eliminate strict-aliasing puns -- snip -- ... which refers to the following diff for vmalloc... -- snip -- diff -r -u ast_ksh_20101026/build_sparc_64bit_opt/src/lib/libast/vmalloc/vmstat.c ast_ksh_20101112/build_sparc_64bit_opt/src/lib/libast//vmalloc/vmstat.c --- ast_ksh_20101026/build_sparc_64bit_opt/src/lib/libast/vmalloc/vmstat.c Thu Apr 8 18:03:14 2010 +++ ast_ksh_20101112/build_sparc_64bit_opt/src/lib/libast//vmalloc/vmstat.c Wed Nov 10 08:36:23 2010 @@ -91,7 +91,10 @@ } else /* get the real size */ { if(vd->mode&VM_MTDEBUG) - s = DBSIZE(DB2DEBUG(DATA(b))); + { /* strict-aliasing dance */ + void* d = DB2DEBUG(DATA(b)); + s = DBSIZE(d); + } else if(vd->mode&VM_MTPROFILE) s = PFSIZE(DATA(b)); if(s > st->m_busy) -- snip -- ... and the following diff for regex... -- snip -- --- ast_ksh_20101026/build_sparc_64bit_opt/src/lib/libast/regex/regnexec.c Fri Dec 11 06:21:20 2009 +++ ast_ksh_20101112/build_sparc_64bit_opt/src/lib/libast//regex/regnexec.c Wed Nov 10 08:30:03 2010 @@ -234,10 +234,9 @@ regmatch_t save[1]; } Match_frame_t; -#define matchframe stkdata(stkstd,Match_frame_t) #define matchpush(e,x) ((x)->re.group.number?_matchpush(e,x):0) -#define matchcopy(e,x) ((x)->re.group.number?memcpy(matchframe->match,matchframe->save,matchframe->size):(void*)0) -#define matchpop(e,x) ((x)->re.group.number?memcpy(matchframe->match,matchframe->save,matchframe->size),stkpop(stkstd):(void*)0) +#define matchcopy(e,x) do if ((x)->re.group.number) { Match_frame_t* fp = (void*)stkframe(stkstd)->data; memcpy(fp->match, fp->save, fp->size); } while (0) +#define matchpop(e,x) do if ((x)->re.group.number) { Match_frame_t* fp = (void*)stkframe(stkstd)->data; memcpy(fp->match, fp->save, fp->size); stkpop(stkstd); } while (0) #define pospop(e) (--(e)->pos->cur) -- snip -- ... does that help somehow ? :-) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
