Intel® Software Network

Hi,

While writing a transactional program (rather converting a lock based program to use transactions) I came across the following assembler error message:

/tmp/iccMEnLT9as_.s: Assembler messages:
/tmp/iccMEnLT9as_.s:48: Error: junk `@nonTXN' after expression

And I see a tons of them. But it isn't to informative for me to find out the reason for this error. Any help will be appreciated.

Thanks,
Neelam

I came across the following assembler error message:

/tmp/iccMEnLT9as_.s: Assembler messages:
/tmp/iccMEnLT9as_.s:48: Error: junk `@nonTXN' after expression

Hmm, this could be a compiler or assembler problem. When generating tm_callable functions the compiler generates two "clones" of the function, one to execute inside a transaction and one to execute outside. The transactional version's name is suffixed with a special tag which includes '@', so it's possible that this problem is related to that. (More likely to pointers to functions...)

Can you post a small example which shows the problem, along with the compile line you used?

Or, failing that you could try compiling with -S (to save the assembler code), and then at least you can look at it and see if it is buggy...

HTH

---

Jim Cownie
(Intel Performance, Analysis and Threading Lab)

Thanks Jim.

I don't see these assembler errors when I try compiling with -S. So the problem seems to be in linking stage!!

I am not sure how I could post the code having problem, because I am not even sure where this assembler message is coming from. I was just wondering if this a commonly seen problem and if there is a common solution!

-Neelam

Are you compiling the program using -S or have assembly code in your program.  The STM compiler on whatif.intel.com has a bug when generating names for assembly file, uses a character which  the linker does not like.  Try removing the -S and generate object code directly using -c or if using assembly code put the assembly code in a different file.

I tried compiliing the code using -S and the compilation proceeds fine. But when I try generating the object code using -c option, I get the assembler messages.

Error: junk `@nonTXN' after expression

These messages seem to be related to the tm_callable annotated code. But I am not able to figure out the actual problem because this error message isn't too informative!!

Seems like you have inline assemble code in your program.  This may not be obvious,  the inline assemble code may be included into your program through some header file.  Next update of the compiler in Q2 should address this problem.

I tried compiliing the code using -S and the compilation proceeds fine.

OK, that's not surprising, since with -S the compiler generates the assembler file and then stops. So, as the error message is generated by the assembler (which isn't being run when you compile with -S), I'd expect it not to apper.

But when I try generating the object code using -c option, I get the assembler messages.
Error: junk `@nonTXN' after expression

The thing to do is to look at the assembler file which was generated by the -S compilation, and try to assemble it yourself. Now that you have the source which the assembler is seeing you should be able to see what's wrong with it, and, where in your source it came from. (Since each instruction is decorated with a comment giving the source line).

Of course it's possible that this is a compiler bug, and it's generating bad assembly code, but if you can slice out the line the assembler is complaining about (with a bit of context), and post it, then it'll be easier to tell...

---

Jim Cownie
(Intel Performance, Analysis and Threading Lab)

I do agree that I certainly have some inline assembly code through C library headers etc. But I am not sure if the problem really is with inline assembly. Because when I tried a simple test program having inline assembly, that compiled just fine with icc.

Hi Jim,

I followed your suggestion and tried to assemble the file myself and came across some annotation (tm_callable) related problems. Some of them seem to be with function pointers.

Thanks,
Neelam

When you mark a function tm_calleable we clone the function and mangle the cloned function name.  The compiler on whatif.intel.com mangles the name using a character which the assembler does not recognize along with the name @nonTXN,   hence you get a error from the assembler.  It is not a problem if the assembler is not invoked during the compilation.  If there is inline assembly code in the program, the compiler is forced to use the assembler.  As I said this is fixed and next update will address this issue. So a program without any  function marked tm_calleable it should compile.

This makes much more sense now. Can you tell me, when should we expect the next version to be released?

Thanks.

Next STM compiler update is tentatively scheduled for April. 

The new release has fixed many assembler issues.
But once again, I am facing these assembler problems. I am using some inline assembly in a __tm_pure function. And I see the following error message:

/tmp/icc04zZIsas_.s: Assembler messages:
/tmp/icc04zZIsas_.s:5528: Error: symbol `smallbuf.1636.0.9' is already defined

Any help is appreciated.
Neelam

neegoyal:

The new release has fixed many assembler issues.
But once again, I am facing these assembler problems. I am using some inline assembly in a __tm_pure function. And I see the following error message:

/tmp/icc04zZIsas_.s: Assembler messages:
/tmp/icc04zZIsas_.s:5528: Error: symbol `smallbuf.1636.0.9' is already defined

Any help is appreciated.
Neelam

Do you use IPO (inter-procedure optimizations, turned on by -ipo knob) for building your app? Some issue with versioned symbols (those with numbered names) was found just after 2nd release and fixed targeting the next update, but I believe it affected only some IPO-enabled builds. Source of versioned symbols duing IPO build is static functions with same names found in multiple source files.

Regards,
Serge.