Hello again,
I must revise my comments ;-)
The problem was not the compiler..
Before updating vs2017 we pulled the recent opensg source from git. There's a commit from 21.08.2016 which breaks the suspicious function.
Line 318 was commented out, but indexBegin needs to be reset to 0;
Patch is attached.
Michael
Gesendet: Donnerstag, 30. November 2017 um 10:30 Uhr
Von: "Michael Raab" <michael-r...@gmx.de>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] OpenSG2: vs2017 Optimization error
Von: "Michael Raab" <michael-r...@gmx.de>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] OpenSG2: vs2017 Optimization error
Hello Carsten, Hello Johannes,
thanks for your suggestions. I've solved the issue by turning optimizations off for the problematic function. All other attempts did not work.
I've attached the patch. Is that something you want to commit to the git repository?
Michael
Gesendet: Dienstag, 28. November 2017 um 16:33 Uhr
Von: "Carsten Neumann" <carsten.p.neum...@gmail.com>
An: opensg-users@lists.sourceforge.net, "Michael Raab" <michael-r...@gmx.de>
Betreff: Re: [Opensg-users] OpenSG2: vs2017 Optimization error
Von: "Carsten Neumann" <carsten.p.neum...@gmail.com>
An: opensg-users@lists.sourceforge.net, "Michael Raab" <michael-r...@gmx.de>
Betreff: Re: [Opensg-users] OpenSG2: vs2017 Optimization error
Hello Michael,
On 2017-11-28 05:14, Michael Raab wrote:
> we're trying to build the recent OpenSG source with vs2017 (vc141). We
> noticed that the compiler produces faulty code for release builds when
> optimization (/O2) is activated.
> OSGTextVectorFace.cpp
> Line 273:
> indexEnd = tIt->second;
> Here, the assignment to indexEnd nevers happens. Assembly looks like this:
> 000007FEE316324A mov r8d,dword ptr [r12+4]
> 000007FEE316324F mov dword ptr [index],r8d
> Looks like the value is written to a variable 'index' instead of
> indexEnd... :-(
> Do you have any ideas how to fix this without deactivating
> optimizations? Do you have experienced other similar problems?
hmm, from just staring at the code I don't see anything that jumps out
as wrong/suspicious to me.
That it seems to store to index instead of indexEnd in the assembly
could also be because the compiler has concluded that it can materialize
the value of one variable from the other in a way that is cheaper than
using a register or stack slot.
You could try these things and see if that helps:
- move the scope of indexBegin, indexEnd into the for loop. I notice
that there is another set of variables with the same name around line
319, perhaps that confuses the compiler?
- #define OSG_ASSERT() to assert() at the top of the file, so the
compiler sees the assertions - some compilers derive optimization
knowledge from assertions.
- I assume you've used other methods (than reading assembly ;) ) to
track the problem to this function/loop, i.e. it is fairly unlikely that
the problem is elsewhere?
Cheers,
Carsten
On 2017-11-28 05:14, Michael Raab wrote:
> we're trying to build the recent OpenSG source with vs2017 (vc141). We
> noticed that the compiler produces faulty code for release builds when
> optimization (/O2) is activated.
> OSGTextVectorFace.cpp
> Line 273:
> indexEnd = tIt->second;
> Here, the assignment to indexEnd nevers happens. Assembly looks like this:
> 000007FEE316324A mov r8d,dword ptr [r12+4]
> 000007FEE316324F mov dword ptr [index],r8d
> Looks like the value is written to a variable 'index' instead of
> indexEnd... :-(
> Do you have any ideas how to fix this without deactivating
> optimizations? Do you have experienced other similar problems?
hmm, from just staring at the code I don't see anything that jumps out
as wrong/suspicious to me.
That it seems to store to index instead of indexEnd in the assembly
could also be because the compiler has concluded that it can materialize
the value of one variable from the other in a way that is cheaper than
using a register or stack slot.
You could try these things and see if that helps:
- move the scope of indexBegin, indexEnd into the for loop. I notice
that there is another set of variables with the same name around line
319, perhaps that confuses the compiler?
- #define OSG_ASSERT() to assert() at the top of the file, so the
compiler sees the assertions - some compilers derive optimization
knowledge from assertions.
- I assume you've used other methods (than reading assembly ;) ) to
track the problem to this function/loop, i.e. it is fairly unlikely that
the problem is elsewhere?
Cheers,
Carsten
textOpt2.diff
Description: Binary data
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
