clang, asm. bug

Added by Kevin Thacker almost 5 years ago

_clang.jam

This line breaks .s assembler files.

C.Flags * : CC : -x c -Wno-unused-parameter ;

Change to:

C.Flags * : CC : -Wno-unused-parameter ;

then both c and assembler files now work.

in addition please consider:

-std=gnu99 for c
and -std=gnu++11 for c++.


Replies (3)

RE: clang, asm. bug - Added by Joshua Jensen almost 5 years ago

Kevin Thacker wrote:

_clang.jam

This line breaks .s assembler files.

C.Flags * : CC : -x c -Wno-unused-parameter ;

Change to:

C.Flags * : CC : -Wno-unused-parameter ;

then both c and assembler files now work.

Hmmm... it seems to me that .s assembler files should go through another path.

Do you have a simple Jam project with a .s file in it that I could use to fix the behavior all the way?

in addition please consider:

-std=gnu99 for c
and -std=gnu++11 for c++.

Have these been added to the standard Xcode build command-line? It has been a while since I looked.

Thanks.

-Josh

RE: clang, asm. bug - Added by Kevin Thacker almost 5 years ago

Joshua Jensen wrote:

Hmmm... it seems to me that .s assembler files should go through another path.

That is possible, although the asm file itself has #includes and uses #defines from a c++ header.
The function itself is not in an __asm block, but like normal asm with labels etc.

Do you have a simple Jam project with a .s file in it that I could use to fix the behavior all the way?

I don't have one I can send to you at this time, it's in our project which I can't send you.

in addition please consider:

-std=gnu99 for c
and -std=gnu++11 for c++.

Have these been added to the standard Xcode build command-line? It has been a while since I looked.

I don't know. They are the settings in our xcode project and I setup our jam from that.

RE: clang, asm. bug - Added by Steven Craft almost 4 years ago

I have this problem too. Please find attached a .s file that you can assemble to test with.

For what it is worth, it would make sense for .s assembly files to go down another path, as currently a bunch of compile options/defines are being passed to the assembly phase, which are probably not what is intended when a user calls C.CFlags (I guess maybe there should be a C.ASFlags or something).

(1-3/3)