fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
pwithnall has quit [Quit: pwithnall]
pwithnall has joined #systemtap
orivej has quit [Ping timeout: 276 seconds]
pwithnall[m] has joined #systemtap
pwithnall has quit [Ping timeout: 250 seconds]
bendlas has joined #systemtap
gromero has joined #systemtap
hpt has joined #systemtap
scox has joined #systemtap
gromero has quit [Ping timeout: 240 seconds]
irker651 has quit [Quit: transmission timeout]
sanoj has joined #systemtap
slowfranklin has joined #systemtap
lindi- has quit [Quit: No Ping reply in 180 seconds.]
lindi- has joined #systemtap
lindi- has quit [Changing host]
lindi- has joined #systemtap
pwithnall[m] has quit [Ping timeout: 240 seconds]
bendlas has quit [Ping timeout: 255 seconds]
sanoj has quit [Ping timeout: 240 seconds]
sanoj has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
orivej has joined #systemtap
sanoj has quit [Ping timeout: 276 seconds]
slowfranklin has joined #systemtap
hpt has quit [Ping timeout: 240 seconds]
hpt has joined #systemtap
hpt has quit [Client Quit]
pwithnall[m] has joined #systemtap
sanoj has joined #systemtap
bendlas has joined #systemtap
mjw has joined #systemtap
sanoj has quit [Ping timeout: 255 seconds]
mbenitez has joined #systemtap
drsmith_away is now known as drsmith
brolley has joined #systemtap
tromey has joined #systemtap
nkambo has quit [Ping timeout: 276 seconds]
orivej has quit [Ping timeout: 246 seconds]
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
brolley has quit [Quit: Leaving.]
brolley has joined #systemtap
<fche> drsmith, why do we use -std=c++0x rather than -std=c++11 ?
<fche> jistone, maybe you know
<drsmith> I wondered the same thing
<jistone> I think gcc.el6 doesn't know -std=c++11
<fche> not even the dts compiler?
<jistone> oh, I'm sure the dts compiler would
<jistone> if you're going to start using dts as your base, why stop at c++11? :)
<fche> too busy to play
<fche> :-)
<fche> the best part is the last three seconds
<jistone> commit c3ce3b26ec21065314db56d6d22d551d01357a59
<jistone> and relevant to that clip, 88e39987df7109b26343c9c33567646873d6f829
<fche> good old days
<fche> so anyway c++0x seems to be too weak in that it seems to pass for our 4.7 user, but our code includes constructs in excess of that
<fche> wonder if -std=c++0x -pedantic catches them
<jistone> c++0x fails, but c++11 works? I thought they were equivalent?
<fche> PR22572
<fche> wonder if we've tried building on rhel6 lately
<drsmith> I built there today, works fine.
<jistone> my guess it that -std=c++11 won't make any difference, but 4.7 doesn't have the feature used
<fche> I'm hoping autoconf c++11 would fail -iff- -std=c++11 fails to build stap
<jistone> I mean, autoconf doesn't try to build the whole project
<fche> yes, the presence of -std=c++11 is used as a proxy
<jistone> right, but the sordid history of c++11 makes that vague
<fche> ok. so apart from that, it'd be good to find out why his 4.6 / 4.7 can't build git stap
<fche> if it's just a matter of adding some casts, so be it
<fche> that error message glarbhvomitglarbh makes it hard to see the actual problem
<fche> but maybe
<fche> staptree.h:516:10: error: invalid conversion from ‘unsigned char’ to ‘print_format::width_type’ [-fpermissive]
<fche> staptree.h:516:10: error: invalid conversion from ‘unsigned char’ to ‘print_format::conversion_type’ [-fpermissive]
<fche> staptree.h:516:10: error: invalid conversion from ‘unsigned char’ to ‘print_format::precision_type’ [-fpermissive]
<fche> which is weird ... unsigned char to unsigned should be good ... everywhere?
<jistone> maybe that's part of C99 "extended integral types"? bottom of https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
<fche> dunno ... the enums confusing things?
<fche> or the synthesized copy constructor is wrong
<fche> hey tell me btw .... did that : 8 in format_component seem needed ?
<jistone> do you know what part of stap's code is triggering this?
<fche> staptree.cxx line 904
slowfranklin has left #systemtap [#systemtap]
<fche> when a vector<.._format> .push_back(.._format) by value
* fche suspects a compiler bug ... but if we can work around it by dropping the bigfield widths, that'd be good enough for me
<fche> BITFIELD dammit
<fche> it must be a tuesday
<jistone> d70e3afe95c84
<fche> could never get the hang of tuesdays
<jistone> part of my efforts to reduce memory
<jistone> those formats show up all over the place when stap parses tapsets
<fche> yeah. maybe we can measure how much difference it makes
<fche> weigh it against our own time for further analysis
<jistone> iirc qemu was the biggest culprit
<jistone> if you want to test with those in place
sanoj has joined #systemtap
orivej has joined #systemtap
slowfranklin has joined #systemtap
slowfranklin has quit [Client Quit]
sanoj has quit [Ping timeout: 255 seconds]
slowfranklin has joined #systemtap
ChanServ has quit [shutting down]
ChanServ has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
drsmith is now known as drsmith_away
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
mbenitez has quit [Quit: Leaving]
tromey has quit [Quit: ERC (IRC client for Emacs 26.0.90)]
hpt has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
brolley has left #systemtap [#systemtap]
mjw has quit [Quit: Leaving]
hpt has quit [Ping timeout: 260 seconds]