error: expected a ";"

error: expected a ";"

I'm trying to compile Firefox with the new ICC13. I keep getting this error, and am not sure why. This doesn't occur when compiling with MSVC:

The code where this occurs:

    /**

     * Whenever "memory-pressure" is observed, it calls AgeAllGenerations()

     * to minimize memory usage.

     */

    class ExpirationTrackerObserver MOZ_FINAL : public nsIObserver {

    public:

      void Init(nsExpirationTracker *obj) {

        mOwner = obj;

        nsCOMPtr obs = mozilla::services::GetObserverService();

        if (obs) {

          obs->AddObserver(this, "memory-pressure", false);

        }

      }

      void Destroy() {

        nsCOMPtr obs = mozilla::services::GetObserverService();

        if (obs)

          obs->RemoveObserver(this, "memory-pressure");

      }

      NS_DECL_ISUPPORTS

      NS_DECL_NSIOBSERVER

    private:

      nsExpirationTracker *mOwner;

    };

17 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The compiler is hitting a syntax error.

I assume MOZ_FINAL is a macro that gets expanded to something?

Please preprocess the file using -E -P andshow uswhat the source looks like afterpreprocessing.

thanks
Judy

I am able to compile theFirefox JS engine only. which module are you building? are you using VS2010? how do you change the config to use icl?

Jennifer

Quoting Judith Ward (Intel)

The compiler is hitting a syntax error.

I assume MOZ_FINAL is a macro that gets expanded to something?

Please preprocess the file using -E -P andshow uswhat the source looks like afterpreprocessing.

thanks
Judy

MOZ_FINAL prevents inheriting.

Also the code I quoted was from the .h file itself:

http://hg.mozilla.org/mozilla-central/file/bfc259be3fa2/xpcom/ds/nsExpirationTracker.h

Do you want me to preprocess the file where the error first occurs (SourceSurfaceD2DTarget.cpp)? Sorry if my question seems a bit stupid.

Yes please preprocess SourceSurfaceD2DTarget.cpp (just take the compilation command line shown in your log above and add -P to it). This should create a preprocessed file called SourceSurfaceD2DTarget.i. Look in that file for the line that gets the compilation error.

From what I found here:

http://whereswalden.com/2011/11/26/introducing-moz_final-prevent-inheriting-from-a-class-or-prevent-overriding-a-virtual-function/

It looks like the MOZ_FINAL macro uses the C++11 keyword "final" which is not yet implemented in our 12.1 compiler (or by MSVC++ 2010). So wherever that macro is beingdefined in the libraryit should not be expanded to anything.

If that really is a problem then adding -DMOZ_FINAL= to the command line may help.

thanks,
Judy

Quoting Judith Ward (Intel)

Yes please preprocess SourceSurfaceD2DTarget.cpp (just take the compilation command line shown in your log above and add -P to it). This should create a preprocessed file called SourceSurfaceD2DTarget.i. Look in that file for the line that gets the compilation error.

From what I found here:

http://whereswalden.com/2011/11/26/introducing-moz_final-prevent-inheriting-from-a-class-or-prevent-overriding-a-virtual-function/

It looks like the MOZ_FINAL macro uses the C++11 keyword "final" which is not yet implemented in our 12.1 compiler (or by MSVC++ 2010). So wherever that macro is beingdefined in the libraryit should not be expanded to anything.

If that really is a problem then adding -DMOZ_FINAL= to the command line may help.

thanks,
Judy

I'm using version 13 of the Intel Compiler. Here is the preprocessed file and the compiler output (~200,000 lines?):

SourceSurfaceD2DTarget.i

Quoting Jennifer Jiang (Intel)

I am able to compile the Firefox JS engine only. which module are you building? are you using VS2010? how do you change the config to use icl?

Jennifer

I'm using VS2010. Do you mean SpiderMonkey by itself or within Firefox? I'm trying to compile the whole of Firefox with version 13 of the Intel Compiler. Here's what my mozconfig looks like:

. $topsrcdir/browser/config/mozconfig
#Host computer options

ac_add_options --enable-application=browser

ac_add_options --target=x86_64-pc-mingw32

ac_add_options --host=x86_64-pc-mingw32

ac_add_options --with-windows-version=601

ac_add_options --with-branding=browser/branding/waterfox

WIN32_REDIST_DIR=$VCINSTALLDIR/redist/x64/Microsoft.VC100.CRT
#Options for client.mk

mk_add_options MOZ_MAKE_FLAGS=-j8

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir
#Commands to send to the linker

export MOZ_OPTIMIZE_LDFLAGS="-MACHINE:X64 -opt:ref,icf libm.lib libtcmalloc_minimal.lib /INCLUDE:__tcmalloc"

mk_add_options MOZ_OPTIMIZE_LDFLAGS="-MACHINE:X64 -opt:ref,icf libm.lib libtcmalloc_minimal.lib /INCLUDE:__tcmalloc"
#Enable wanted features

ac_add_options --enable-optimize="-O2 -w"

ac_add_options --enable-shared-js

ac_add_options --enable-crypto

ac_add_options --enable-image-decoders=icon,png,gif,jpeg,bmp

ac_add_options --enable-extensions=default

ac_add_options --enable-installer
#Disable unwanted features

ac_add_options --disable-auto-deps

ac_add_options --disable-debug

ac_add_options --disable-tests

ac_add_options --disable-debug-symbols

ac_add_options --disable-ipdl-tests

ac_add_options --disable-updater

ac_add_options --disable-update-channel

ac_add_options --disable-update-packaging

ac_add_options --disable-crashreporter

ac_add_options --enable-debugger-info-modules=no

ac_add_options --disable-debugger-info-modules

ac_add_options --disable-activex

ac_add_options --disable-activex-scripting

ac_add_options --disable-mochitest

ac_add_options --disable-mochitests

ac_add_options --disable-accessibility

#ac_add_options --disable-parental-controls

ac_add_options --disable-windows-mobile-components

And my batch file:

@echo off

SETLOCAL
SET MOZ_MSVCVERSION=10
SET MOZBUILDDIR=%~dp0
SET MOZILLABUILD=%MOZBUILDDIR%

echo "Mozilla tools directory: %MOZBUILDDIR%"

REM Get MSVC paths
call "%MOZBUILDDIR%guess-msvc.bat"

REM Use the "new" moztools-static
set MOZ_TOOLS=%MOZBUILDDIR%moztools-x64

rem append moztools to PATH
SET PATH=%PATH%;%MOZ_TOOLS%\bin

if "%VC10DIR%"=="" (
if "%VC10EXPRESSDIR%"=="" (
ECHO "Microsoft Visual C++ version 10 was not found. Exiting."
pause
EXIT /B 1
)

if "%SDKDIR%"=="" (
ECHO "Microsoft Platform SDK was not found. Exiting."
pause
EXIT /B 1
)

rem Prepend MSVC paths
call "%VC10EXPRESSDIR%\bin\amd64\vcvars64.bat" 2>nul
if "%DevEnvDir%"=="" (
rem Might be using a compiler that shipped with an SDK, so manually set paths
SET "PATH=%VC10EXPRESSDIR%\Bin\amd64;%VC10EXPRESSDIR%\Bin;%PATH%"
SET "INCLUDE=%VC10EXPRESSDIR%\Include;%VC10EXPRESSDIR%\Include\Sys;%INCLUDE%"
SET "LIB=%VC10EXPRESSDIR%\Lib\amd64;%VC10EXPRESSDIR%\Lib;%LIB%"
)

rem Don't set SDK paths in this block, because blocks are early-evaluated.

rem Fix problem with VC++Express Edition
if "%SDKVER%" GEQ "6" (
rem SDK Ver.6.0 (Windows Vista SDK) and newer
rem do not contain ATL header files.
rem We need to use the Platform SDK's ATL header files.
SET USEPSDKATL=1
)
rem SDK ver.6.0 does not contain OleAcc.idl
rem We need to use the Platform SDK's OleAcc.idl
if "%SDKVER%" == "6" (
if "%SDKMINORVER%" == "0" (
SET USEPSDKIDL=1
)
)
) else (
rem Prepend MSVC paths
rem The Win7 SDK (or newer) should automatically integrate itself into vcvars32.bat
ECHO Using VC 10 built-in SDK
call "%VC10DIR%\bin\amd64\vcvars64.bat"
)

if "%VC10DIR%"=="" (
rem Prepend SDK paths - Don't use the SDK SetEnv.cmd because it pulls in
rem random VC paths which we don't want.
rem Add the atlthunk compat library to the end of our LIB
set "PATH=%SDKDIR%\bin\x64;%SDKDIR%\bin;%PATH%"
set "LIB=%SDKDIR%\lib\x64;%SDKDIR%\lib;%LIB%;%MOZBUILDDIR%atlthunk_compat"

if "%USEPSDKATL%"=="1" (
if "%USEPSDKIDL%"=="1" (
set "INCLUDE=%SDKDIR%\include;%PSDKDIR%\include\atl;%PSDKDIR%\include;%INCLUDE%"
) else (
set "INCLUDE=%SDKDIR%\include;%PSDKDIR%\include\atl;%INCLUDE%"
)
) else (
if "%USEPSDKIDL%"=="1" (
set "INCLUDE=%SDKDIR%\include;%SDKDIR%\include\atl;%PSDKDIR%\include;%INCLUDE%"
) else (
set "INCLUDE=%SDKDIR%\include;%SDKDIR%\include\atl;%INCLUDE%"
)
)
)

call "C:\Program Files (x86)\Intel\Composer XE 2013\bin\ipsxe-comp-vars.bat" intel64 vs2010
set CC=icl
set CXX=icl
set AR=xilib -NOLOGO -OUT:"$@"
set LD=xilink

cd "%USERPROFILE%"

"%MOZILLABUILD%\msys\bin\bash" --login -i

For some reason the backslashes aren't appearing in the syntax highli

I'm unable to see anything in the .i file. Is it empty? May be it's too big.

What I was asking you to do was toadd -P to all your normal compilationoptions -- not toreplace all your options with just that one.

So the command line should look like:

icl (all your normal compilation options here) -P SourceSurfaceD2DTarget.cpp

then we canlook at the resulting .i file andsee the line (after macro expansion) that's causing the compilation error.

If you're using 13.0 then you must be in the beta program so perhaps you should just file a bug
report through the normal channels.

thanks,
Judy

The first 1000 lines of the .i file I uploaded before are blank, but then code appears after that for some reason.
Here is the file when used with the usual compilation options, which seems to not have as many blank lines:

SourceSurfaceD2DTarget.i

Also the same problem occurs on ICC 12.1 Update 9, so I'm not so sure it is just a problem with just ICC 13.

It appears than when compiling without Pymake (python) the first file with the problem is Factory.cpp:
http://i45.tinypic.com/2l9o36b.png

And here is the preprocessed file:
Factory.i

Which thankfully isn't as large as the other preprocessed files.

Hello,

there's no progress on this thread and so I took a look.

The preprocessed output does not fit to the error displayed:
On the command-line the error occurs for class ExpirationTrackerObserver but this one does not exist in the preprocessed output.

Are you sure you executed the very same icl command when creating the preprocessed output?

Best regards,

Georg Zitzlsberger

Hi everybody,

It would be very useful if somebody will attach nsExpirationTracker.h, gfxFont.h and a header file with MOZ_FINAL macro declaration.

I think the problem could be reproduced in a small test-case.

Best regards,
Sergey

Quoting Georg Zitzlsberger (Intel)Hello,

there's no progress on this thread and so I took a look.
...

Hi Georg, Did you see a couple of comments about 'MOZ_FINAL' macroat:

https://bugzilla.mozilla.org/show_bug.cgi?id=704687
https://bugzilla.mozilla.org/show_bug.cgi?id=704127 [Edited] Added

Please take a look.

Best regards,
Sergey

[Edited] Added: A google search with 'MOZ_FINAL' returns 1,370 results!

And one more to look at:

https://bug704127.bugzilla.mozilla.org/attachment.cgi?id=575855

Herearetwo very interesting pieces of codes from a patch:

[ 1 ]
...
#elif defined(_MSC_VER)
# if _MSC_VER >= 1400 [SergeyK] For VS2005, VS2008, etc
# define MOZ_HAVE_CXX11_OVERRIDE
+ /* MSVC currently spells "final" as "sealed". */
+# define MOZ_HAVE_CXX11_FINAL sealed
# endif
#endif
...

[ 2 ]
...
+/*
+ * MOZ_FINAL indicates that some functionality cannot be overridden through
+ * inheritance. It can be used to annotate either classes/structs or virtual
+ * member functions.
+ *
+ * To annotate a class/struct with MOZ_FINAL, place MOZ_FINAL immediately after
+ * the name of the class, before the list of classes from which it derives (if
+ * any) and before its opening brace. MOZ_FINAL must not be used to annotate
+ * unnamed classes or structs. (With some compilers, and with C++11 proper, the
+ * underlying expansion is ambiguous with specifying a class name.)
+ *
+ * class Base MOZ_FINAL
+ * {
+ * public:
+ * Base();
+ * ~Base();
+ * virtual void f() { }
+ * };
+ * // This will be an error in some compilers:
+ * class Derived : public Base
+ * {
+ * public:
+ * ~Derived() { }
+ * };
+ *
+ * One particularly common reason to specify MOZ_FINAL upon a class is to tell
+ * the compiler that it's not dangerous for it to have a non-virtual destructor
+ * yet have one or more virtual functions, silencing the warning it might emit
+ * in this case. Suppose Base above weren't annotated with MOZ_FINAL. Because
+ * ~Base() is non-virtual, an attempt to delete a Derived* through a Base*
+ * wouldn't call ~Derived(), so any cleanup ~Derived() might do wouldn't happen.
+ * (Formally C++ says behavior is undefined, but compilers will likely just call
+ * ~Base() and not ~Derived().) Specifying MOZ_FINAL tells the compiler that
+ * it's safe for the destructor to be non-virtual.
+ *
+ * In compilers implementing final controls, it is an error to inherit from a
+ * class annotated with MOZ_FINAL. In other compilers it serves only as
+ * documentation.
+ *
+ * To annotate a virtual member function with MOZ_FINAL, place MOZ_FINAL
+ * immediately before the ';' terminating the member function's declaration, or
+ * before '= 0;' if the member function is pure. If the member function is
+ * defined in the class definition, it should appear before the opening brace of
+ * the function body. (This placement is identical to that for MOZ_OVERRIDE.
+ * If both are used, they should appear in the order 'MOZ_FINAL MOZ_OVERRIDE'
+ * for consistency.)
+ *
+ * class Base
+ * {
+ * public:
+ * virtual void f() MOZ_FINAL;
+ * };
+ * class Derived
+ * {
+ * public:
+ * // This will be an error in some compilers:
+ * virtual void f();
+ * };
+ *
+ * In compilers implementing final controls, it is an error for a derived class
+ * to override a method annotated with MOZ_FINAL. In other compilers it serves
+ * only as documentation.
+ */
+#if defined(MOZ_HAVE_CXX11_FINAL)
+# define MOZ_FINAL MOZ_HAVE_CXX11_FINAL
+#else
+# define MOZ_FINAL /* no support */
+#endif
+
...

and I wonder if:

#undef MOZ_HAVE_CXX11_FINAL

at some header will help. However I'm not sure because the 'sealed' keyword has to be supported, or a declaration:

...
#if< Intel C++ compiler >
#define MOZ_HAVE_CXX11_FINAL
#endif
...

is not defined?

Hello all,

sometimes its hard to see the forest for the trees... I missed that MOZ_FINAL was defined in the command line:

The problem: The macro MOZ_FINAL is only defined but not initialized.
Solution: Use -DMOZ_FINAL="" to initialize it.

Btw.: Sergey, _MSC_VER is implicitly set by our compilers. There's no need for special handling here.

Best regards,

Georg Zitzlsberger

Hi Georg, It would be nice togeta responsefrom 'AlexBoy94'.

Also, I was thinking about your great discovery and I think a test-case to reproduce the problem could look like:

Note:Template-based pseudo-codes / I didn't try to compile / Non-Template-based version also could be considered

...
#define _CLASS_FINAL
//#define _CLASS_FINAL sealed // For C++ compiler A
//#define _CLASS_FINAL final// For C++ compiler B
//#define _CLASS_FINAL abcdefgh // To breakC++compilers A and B

//#undef _CLASS_FINAL

template < class T > class TTestClassA
{
public:
TTestClassA(){};
~TTestClassA(){};
};

template < class T > class TTestClassB _CLASS_FINAL : publicTTestClassA
{
public:
TTestClassB(){};
~TTestClassB(){};
};
...
void main( void )
{
TTestClassB< int > tcB;
}
...

What do you think?

Best regards,
Sergey

Quoting Georg Zitzlsberger (Intel)...
Btw.: Sergey, _MSC_VER is implicitly set by our compilers. There's no need for special handling here.
...

Intel C++ compiler could set it but I don't think that itchanges it from a default value defined by a Visual Studio.

- Let's assume that Intel C++ compiler was installed with Visual Studio 2008 Professional Edition
- In that case _MSC_VER has to beequal to 1500
- If Intel C++ compiler will set a different value it could create a "chaos" in some headers ( Platform SDK, TBB, etc )

Here are two exampleswhen TBB uses _MSC_VER macro:

< TBB - concurent_vector.h >

...
#if _MSC_VER==1500 && !__INTEL_COMPILER
// VS2008/VC9 seems to have an issue; limits pull in math.h
#pragma warning( push )
#pragma warning( disable: 4985 )
#endif
...

< TBB - scalable_allocator_vector.h >

...
#if _MSC_VER >= 1400
#define __TBB_EXPORTED_FUNC __cdecl
#else
#define __TBB_EXPORTED_FUNC
#endif
...

Thereisfreedom with Intel specific macros, like__INTEL_COMPILER, etc.

Quoting Sergey KostrovQuoting Georg Zitzlsberger (Intel) ...
Btw.: Sergey, _MSC_VER is implicitly set by our compilers.
There's no need for special handling here.
...

...
- If Intel C++ compiler will set a different value it could create a "chaos" in some headers ( Platform SDK, TBB, etc )
...

That is why on our project there is ablock of codes that does averification for Visual Studio version:

...
#if defined ( _WIN32_MSC )
#define _CPPCOMPILER_VER( _MSC_VER )
#endif
...
#if _CPPCOMPILER_VER < 1200
#define _SCALIB_CPPCOMPILER_VER"5.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual C++ v5.0 is NOT supported ***" )
#endif

#if _CPPCOMPILER_VER == 1200
#define _SCALIB_CPPCOMPILER_VER"6.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 98 ***" )
#endif

#if _CPPCOMPILER_VER == 1300
#define _SCALIB_CPPCOMPILER_VER"7.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 2003 ***" )
#endif

#if _CPPCOMPILER_VER == 1310
#define _SCALIB_CPPCOMPILER_VER"7.1"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 2003 ***" )
#endif

#if _CPPCOMPILER_VER == 1400
#define _SCALIB_CPPCOMPILER_VER"8.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 2005 ***" )
#endif

#if _CPPCOMPILER_VER == 1500
#define _SCALIB_CPPCOMPILER_VER"9.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 2008 ***" )
#endif

#if _CPPCOMPILER_VER == 1600
#define _SCALIB_CPPCOMPILER_VER"10.0"
#pragma message ( "*** ScaLib Message: Compiling with Visual Studio 2010 ***" )
#endif
...

So, if Intel C++ compiler would changea default ( correct )value of _MSC_VER macro a Software Developer woulddetect it during compilation.

An output looks like:

------ Build started: Project: ScaLibTestApp, Configuration: Debug Win32 ------
Compiling...
Stdphf.cpp
*** ScaLib Message: Compiling with Visual Studio 2008 ***
...

Leave a Comment

Please sign in to add a comment. Not a member? Join today