1. Finally resolved and this is how it has to be declared for a GCC-like C/C++ compiler:
"prefetcht0 %0;" : : "m" ( pvAddress )
and it compiles to an instruction in a *.s assembler file:
prefetcht0 DWORD PTR [ebp+8];
2. There is also another way to prefetch data with GCC-like compilers:
__builtin_prefetch( pvAddress, 0, CACHELINE_HINT_T0 );
3. A command line option '-masm=intel' broke functionality in some algorithms ( long time ago tested and
stabilized ) and next week I'll try to investigate why it happened. As soon as the '-masm=intel' is removed problems are gone.
Completed an investigation related to '-masm=Intel' command line option of a GCC-like compiler
and I confirm there is an issue with how it applies a cast from 'double' to 'uint' in Debug
Here is a piece of codes that became broken:
RTdouble dPartI = 0.0L;
RTdouble dPartF = CrtModf( dX, &dPartI );
// In Debug there is a problem with 'double'-to-'uint' cast
if( ( RTuint )dPartI != m_uiRows || ( RTuint )dPartI != m_uiCols )
// A corrected version without cast works properly
if( dPartI != m_uiRows || dPartI != m_uiCols )
All the rest C/C++ compilers that are used in the development process on my project don't have any problems with 'double'-to-'uint' cast.
Note: Variables dX, dPartI, dPartF, m_uiRows and m_uiCols are always positive.