Compiler/TMS320C6654: optimisation remove mandatory functions

Let me check this with the CCS team.
Best Regards,
Yordan

My guess is those functions are not missing, but inlined.  When a function is inlined, a call to the function is replaced with the source for the function. If every call to a function is inlined, then a call-able version of the function may not be emitted.

Here is one way to tell.

Add the option --src_interlist.  This tells the compiler to keep the auto-generated assembly file, and to add comments to it which make it easier to understand.  The assembly file has the same name as the source file, with the extension changed to .asm.  Inspect that file.  Towards the end, you will see lines similar to ...

;; Inlined function references:
;; [1] name_of_missing_function

In this specific case, you can search the rest of the assembly file for [1] to find the spots where a function called name_of_missing_function gets inlined.

Thanks and regards,

-George

Hi George,

My issue concerns 1 constructor and 1 function that are both in different library

Regarding the function issue, it's declared as inlined in h file and it's called 2 times (only inside the library).
In linux generated map file, the function have an address and a size of around 4kB. So it seems to not have been inlined.
In windows generated map file, this function is not visible.
In both map files, function's caller have a size of only 120 B, so I'm sure that it's not inlined.
so it looks like this function is like the schrodinger's cat : inlined and not inlined

Regarding the constructor, it contains only initialisation list and initialized class also only initialisation list.

The issue is not always reproducible, and a touch to the callers file is enough to make the function appear in map file.

Check of generated asm is complicated as I have 2 files with the same name but different path, so generated asm file is only the last one.

regards

I'm not sure what to focus on.  No functions have disappeared.  Instead, they get inlined.  Do you agree with that?  

When the functions get inlined, your code does not work.  Is that correct?  If so, I need more details.  How do you know it doesn't work?  Exactly how do you see that?

Thanks and regards,

-George

Hi,

The fonction to blame is 4kB, and the 2 callers are only 120 B, so it have not been inlined.

I discover the issue with the constructor. When I try to load and execute windows generated binary from ccs, I get abnormal behaviour.
I go, step by step, to the branch to this guilty constructor. After the branch, disassembly show me the name of my constructor, but call stack show me another function (assembly correspond to function pointed by call stack)

It's difficult to explain, but my feeling is that I want to branch to a function that have not been placed into the binary. It seems that it affects only 1 constructor and 1 function which is very very few in my complete project. For an unknow reason this function and this constructor have been removed by optimizer

I get the same behaviour with windows cgt 8.3.4 and 8.3.5 (under ccs 8.3.1 and ccs 9.2)

Gildas

It is generally true that compiler optimization degrades the debug experience.  That may be what is happening here.

Gildas ROLLAND said:

I go, step by step, to the branch to this guilty constructor. After the branch, disassembly show me the name of my constructor, but call stack show me another function (assembly correspond to function pointed by call stack)

For the source file that contains the branch to the guilty constructor, and the source file which contains the constructor (which may be the same source file), please follow the directions in the article How to Submit a Compiler Test Case.  In addition, next to the branch to the guilty constructor, add the comment // PROBLEM BRANCH.

Thanks and regards,

-George

Hi,

I've discovered that the issue is present in the first compilation in a clean environment but disappear if I just touch the file and compile again.

So I've compare all generated files between the first and second build:
For both guilty constructor and guilty function, the generated .obj files differs (and of course generated .lib file). So the issue is not on the caller side, but In the library compilation

This make me found that guilty sources files have the same name but different path than another file in its respective library.

After a search on the forum, it appears that you have already open a defect on this point
https://e2e.ti.com/support/tools/ccs/f/81/t/768389?tisearch=e2e-sitesearch&keymatch=same%2525252525252520name%2525252525252520file
It's really surprising that this defect have been rejected

I've tried to disable parallel build from a clean environnement and it's working but it's really not a long term solution

regards

Gildas ROLLAND said:

After a search on the forum, it appears that you have already open a defect on this point. ...
It's really surprising that this defect have been rejected

When that issue was discovered, an entry was first filed against the compiler tools.  After some investigation, it was clear the root of the problem was not in the compiler, but in how CCS invoked the compiler.  So, the issue filed against the compiler was rejected, and a new issue was opened against CCS.  The ID of this issued filed against CCS is CCDSK-3494.  

However, none of that is useful here, because I am convinced your problem is different.  In CCDSK-3494, none of the generated object files have any problems similar to what you describe.  The problem of CCDSK-3494 appears in the assembly files that are kept if you use compiler options like --src_interlist.  The problem you describe says that, due to some files in different directories having the same name, the object files are incorrect somehow.  That is behavior I have not seen before, and I need a test case from you which lets me reproduce it.

The best test case is your CCS project.  Please zip up the project as described in the article Sharing Projects, then attach it to your next post.

Thanks and regards,

-George

I've tried to disable parallel build, and the issue disappear (a pity with a 12 cores processor...)
I've tried to remove --keep_asm option and the issue disappear

It's may be an other behaviour of this defect, but I'm also convinced that my issue is due to the combination of : same name files + parallel build + keep_asm

Change these options also fix another issue I have. Some time, when I compile, I get error message on generated asm files and I have to relaunch build to make the error disappear (and I'm sure it was always on files which have a duplicate name in different folder). This also disapear

.obj and .d files (and also .lst if I remember well) keep the original folders organization. Is it difficult to do the same for generated asm?

Defect CCDSK-3494 should not be public

I agree your situation has some similarities to CCDSK-3494, but I am confident it is not the same.  So, for now, it is best to handle it like a new problem.

To pursue this issue, we still need the CCS project I requested in my last post.  If you are not comfortable posting it to the forum, then you are welcome to attach it to a private message you send to me.  Hover your mouse over my screen name or avatar. A box will pop up. Click on Send a private message. In the message compose interface which comes up, use the paper clip icon to attach the zip file.

Thanks and regards,

-George