hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
hkaiser has joined #ste||ar
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
hkaiser has quit [Ping timeout: 268 seconds]
eschnett_ has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
eschnett_ has quit [Quit: eschnett_]
nanashi55 has quit [Ping timeout: 246 seconds]
nanashi55 has joined #ste||ar
RostamLog has quit [Ping timeout: 268 seconds]
RostamLog has joined #ste||ar
david_pfander has joined #ste||ar
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
aserio has joined #ste||ar
hkaiser has quit [Quit: bye]
<K-ballo>
I'm stuck on a project that does git submodules and does them badly, instead of each repo having its dependencies as submodules there is a parent super-repo with submodules to all the childs (a la boost, llvm, etc)
<K-ballo>
I need to make a change to the super project that affects all of the childs, I cannot change the childs first because without the super bits they would break, and I cannot change the super first because it would also break all of the childs
<K-ballo>
I cannot change both at the same time, because merging changes to submodules creates new commit hashes which are the ones the super project has to actually point to
<K-ballo>
so I first have to add a temporary change to super, then change all the childs to use it, then change the super for the real change, then the childs to use it, then finally the super to remove the temporary change
<zao>
I tolerate submodules now that I have recursive git checkout support in EasyBuild.
<ste||ar-github>
hpx/vc_compat 3e608e3 Hartmut Kaiser: Make sure DATAPAR settings are conveyed to depending projects
ste||ar-github has left #ste||ar [#ste||ar]
ste||ar-github has joined #ste||ar
<ste||ar-github>
[hpx] hkaiser opened pull request #3574: Make sure DATAPAR settings are conveyed to depending projects (master...vc_compat) https://github.com/STEllAR-GROUP/hpx/pull/3574
ste||ar-github has left #ste||ar [#ste||ar]
<hkaiser>
K-ballo: yt?
<K-ballo>
hkaiser: yes
<hkaiser>
hey,
<hkaiser>
I'm having issues with the new empty_function stuff that was merged yesterday
<K-ballo>
what did I breake?
<K-ballo>
alright..
<hkaiser>
essentially all HPX application fail
<hkaiser>
two issues: one I can fix (and I will)
<hkaiser>
the other issue is more difficult
<hkaiser>
the get_empty_function_table function creates a static variable in each module it is compiled which prevents for .empty() to work correctly
<K-ballo>
ouch, my bad
<K-ballo>
works fine within a single TU :P
<hkaiser>
figures
<hkaiser>
;-)
<hkaiser>
not sure why all tests were fine :/
<K-ballo>
are you sure about that diagnostic? doesn't linker have to uniquify those?
<hkaiser>
at least MSVC does do it
<hkaiser>
does NOT do it
<hkaiser>
gcc might, why the tests were fine, I presume
<K-ballo>
what's the other issue?
<hkaiser>
it's an HPX issue where empty functions may be invoced
<K-ballo>
new?
<hkaiser>
but it might gotten exposed by the first issue
<hkaiser>
it's unrelated and has to be fixed anyways
<hkaiser>
any idea how to fix this?
<hkaiser>
(nothing works for me :/ )
<K-ballo>
get_empty_function_table() used to be function_base::get_empty_vtable(), and presumably that was working before
<hkaiser>
it was
<K-ballo>
I can't think of a semantic difference between those
<ste||ar-github>
hpx/hotfix_function_use ffe467c Hartmut Kaiser: Make sure empty startup/shutdown functions are not being used
ste||ar-github has left #ste||ar [#ste||ar]
<K-ballo>
couldn't I have just broken empty() instead?
ste||ar-github has joined #ste||ar
<ste||ar-github>
[hpx] hkaiser opened pull request #3576: Make sure empty startup/shutdown functions are not being used (master...hotfix_function_use) https://github.com/STEllAR-GROUP/hpx/pull/3576
ste||ar-github has left #ste||ar [#ste||ar]
<hkaiser>
yah, I think that's what's happening
<hkaiser>
see ^^ for the fix I mentioned
<hkaiser>
empty() compares to vtbl pointers, both are empty but refer to different statics
<hkaiser>
two*
<K-ballo>
that would make more sense, it would mean there were two different statics before as well
<hkaiser>
hmmm, worked before
<K-ballo>
before each static had a bool empty; entry
<hkaiser>
it was comparing that tag, wasn't it?
<hkaiser>
nod
<K-ballo>
should the vtable creation function have been exported? does that even make sense?
<hkaiser>
wouldn't work as it's a template
<hkaiser>
well, you could export the specializatipon for empty_function
<hkaiser>
and create a static in that function only, returning the pointer
<hkaiser>
or reference
<K-ballo>
the type of the vtable itself changes by signature and capability (unique|serializable)
<hkaiser>
even for the empty function?
<K-ballo>
yes
<hkaiser>
does it have to?
<K-ballo>
yes
<hkaiser>
for the empty function, I mean)
<K-ballo>
yes
<hkaiser>
ok
<K-ballo>
empty function<int(int)> has to point to a different vtable than function<int(int, float)>
<hkaiser>
nod
<K-ballo>
not because the empty case needs it, but because the type system needs it
<hkaiser>
but you initialize the vtable in get_empty_function from a non-template type
<K-ballo>
the type of the vtable itself changes
<hkaiser>
K-ballo: could you create a hotfix that reintroduces the bool until we have a better solution?
<K-ballo>
yeah, I'm working on it
<hkaiser>
thanks
<K-ballo>
I don't think there's a better solution, though I'd like to be sure what the problem is
<K-ballo>
my next work on function removes the dependency on empty vtable identity anyways
<hkaiser>
good
<hkaiser>
K-ballo: I think the is the problem iare the addresses of the created statics
<hkaiser>
empty_vtbl identity depends on its address
<K-ballo>
do both statics have the same types? is one being defined inside the hpx dll and another one in the exe?
<hkaiser>
yes
<K-ballo>
so this is the usual issue with odr and dynamic linking
<hkaiser>
function local statics in msvc have module local scope