Add support for the TASKING compiler family, and its MIL linking feature #12342

gerioldman · 2023-10-08T01:30:36Z

This PR adds support for the TASKING compiler family, and its MIL linking feature as mentioned in #11866.

mesonbuild/compilers/c.py

tristan957 · 2023-10-09T20:38:35Z

Can you squash your commits where appropriate? Git history isn't making sense.

gerioldman · 2023-10-09T20:44:29Z

I'll wait for the checks to finish, after that I will try

gerioldman · 2023-10-09T20:45:33Z

I'll wait for the checks to finish, after that I will try

gerioldman · 2023-10-10T21:23:19Z

@tristan957 Is it better now?

tristan957 · 2023-10-11T15:35:34Z

Here are the commits I envision:

Add tricore to CPU families
Add TASKING compiler support

Should there be any other reason for more commits?

gerioldman · 2023-10-12T15:21:41Z

Fair enough, done :)

bruchar1

I know nothing about those compilers, but here are some general comments.

docs/markdown/Builtin-options.md

bruchar1 · 2023-12-22T17:07:31Z

mesonbuild/compilers/detect.py

+            else:
+                raise EnvironmentException('Failed to detect linker for TASKING VX-toolset compiler. Please update your cross file(s).')
+
+            tasking_ver_match = re.search(r'v(\d+)\.(\d+)r(\d+) Build (\d+)', err)


Please use [0-9] instead of \d

bruchar1 · 2023-12-22T17:08:01Z

mesonbuild/compilers/detect.py

+            return cls(
+                ccache, compiler, tasking_version, for_machine, is_cross, info,
+                exe_wrap, full_version=full_version, linker=linker)
+        # TODO add detection logic here


Will you do it?

I think I have left that there by mistake, I'll take that comment out.

mesonbuild/compilers/mixins/tasking.py

bruchar1 · 2023-12-22T17:09:58Z

mesonbuild/compilers/mixins/tasking.py

+tasking_buildtype_args: T.Dict[str, T.List[str]] = {
+    'plain': [],
+    'debug': ['-g3', '-O0'],
+    'debugoptimized': ['-g3', '-O2'],
+    'release': ['-O3'],
+    'minsize': ['-O3', '--tradeoff=4'],
+    'custom': []
+}


Please use optimization and debug args instead of buildtype. -g3 is already in debug args. Other options are for optimization.

bruchar1 · 2023-12-22T17:13:17Z

mesonbuild/backend/ninjabackend.py

+                    rules += [f"{rule}{ext}" for rule in [self.get_compiler_rule_name('tasking_mil_compile', compiler.for_machine)]
+                              for ext in ['', '_RSP']]


This line is overcomplicated. Please imbricated for loops instead. Not sure why you iterate through a one-item list.

mesonbuild/backend/ninjabackend.py

jpakkane · 2023-12-30T14:15:49Z

The MIL thing is a bit problematic as it is unique to this compiler and thus makes it a notable maintenance burden (as we don't have access to said compiler at all). All other compilers that I know of do this by outputting plain .o files with extra data in them (this is how link-time optimization works in e.g. Clang et al).

Is there any data on how effective it is compared to plain unity builds? That is, if people could get the same performance using builtin unity support rather than this very toolchain specific thingy, would we need to support MIL at all?

gerioldman · 2023-12-30T14:39:59Z

Unfortunately, I do not have any performance data. At first I didn't want to implement the MIL linking for the very reason you mention, but I was unable to make unity build work for the project I was converting to Meson due to some conditional compilation pattern used in almost all files, which pull in a specified part generated headers. With MIL linking, this is not a problem, files are compiled in an identical manner until this MIL intermediate language part.

Not sure how to approach the fact that the compiler is not available for use, the best that I could think of was writing a dummy CLI emulation of the compiler, so some tests could run at the very least.

afahmy-ANGENG · 2024-01-12T15:59:42Z

Thanks for the TASKING Compiler support PR, I successfully used it with TASKING v6.3r1 to build firmware for Infineon TriCore TC375. The output hex file was flashed and it runs successfully on target.

tsetsong · 2024-01-23T08:56:16Z

Hi, Is it possible to share sample files or configurations required to set up a build directory for Tasking Tricore please? Thank you.

The cross_build.txt file I am using is attached.
cross_build.txt

I ran command :

meson setup --cross-file cross_build.ini builddir

But I am getting errors :

Source dir: D:\work\buildsystem\meson_crossbuild
Build dir: D:\work\buildsystem\meson_crossbuild\builddir
Build type: cross build
Project name: tc_hello
Project version: 1.0
Activating VS 17.8.4
C compiler for the host machine: d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\cctc.exe (cctc 6.3.1.19041558)
Traceback (most recent call last):
  File "c:\Python310\lib\site-packages\meson-1.2.99-py3.10.egg\mesonbuild\mesonmain.py", line 194, in run
    return options.run_func(options)
... snip ...
  File "c:\Python310\lib\site-packages\meson-1.2.99-py3.10.egg\mesonbuild\interpreter\interpreter.py", line 1549, in add_languages_for
    mlog.bold(' '.join(comp.linker.get_exelist())), comp.linker.id, comp.linker.version)
  File "c:\Python310\lib\site-packages\meson-1.2.99-py3.10.egg\mesonbuild\linkers\linkers.py", line 160, in get_exelist
    return self.exelist.copy()
AttributeError: 'NoneType' object has no attribute 'copy'

meson.build:1:0: ERROR: Unhandled python exception

    This is a Meson bug and should be reported!

One other question, I don't understand why I am getting :

Activating VS 17.8.4

Is there something I missed in my configurations ? I am not expecting my Visual Studio installation to be used in this build.

Thank you.

gerioldman · 2024-01-23T15:23:20Z

This should work, however, I did not implement support for C++. Not sure why it wants VS, for good measure I would pass in --wipe when configuring.

[constants]
tools_folder = 'd:/Bitbucket/Tools_Inv_HMC_IDM'
compiler_path = tools_folder / 'Compiler'
[built-in options]
c_args = ['-D__CPU__=tc37x', '-D__CPU_TC37X__','-D_TASKING_C_TRICORE_','-g','--align=4','--iso=99']
[project options]
[binaries]
c = compiler_path / 'ctc' / 'bin' / 'cctc.exe'
#cpp = compiler_path / 'ctc' / 'bin' / 'cctc.exe' I did not implement support for C++, it would be cptc.exe
ld = compiler_path / 'ctc' / 'bin' / 'cctc.exe'
ar = compiler_path / 'ctc' / 'bin' / 'artc.exe'
as = compiler_path / 'ctc' / 'bin' / 'cctc.exe'
exe_wrapper = 'meson_exe_wrapper.sh'

[properties]

[host_machine]
system = 'none'
#subsystem = ''
kernel = 'none'
cpu_family = 'tricore'
cpu = 'TC377'
endian = 'little'

tsetsong · 2024-01-24T06:56:44Z

Hi @gerioldman,

Thank you for your reply.
I tried the settings you gave but it did not help. I am still getting the same error.

I will continue to look into this as my team is trying to switch to meson/ninja. We are on a gmake based build system currently.
I think the VS 17.8.4 may be suspicious. I do have VS (Visual Studio) and VS build Tools installed but they shouldn't be used or detected in this case.

update :
I ported meson and my project to a computer without a VS (Visual Studio) installation, and I got the following :

WARNING: Failed to activate VS environment: Could not find C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe
But I am still getting the same error as in the previous post.

regards,
TseTsong, Teo

afahmy-ANGENG · 2024-01-24T09:09:59Z

Hi @tsetsong
Are you sure you are running this PR meson and not a previous version of it ?
Try running it as:
<PR checkout location>/meson.py setup --cross-file cross_build.ini builddir

tsetsong · 2024-01-24T09:28:33Z

Hi @tsetsong Are you sure you are running this PR meson and not a previous version of it ? Try running it as: <PR checkout location>/meson.py setup --cross-file cross_build.ini builddir

Thank you @afahmy-ANGENG for your reply.
I should have attached details of the version of the repo I am using.

I work on a Windows 10 machine.

Here are repository details and how I get the error :

D:\work\mesontasking>git log -1
commit 4f44bbea6d81b059cd5d00fc3b976d5f034d0ba4 (HEAD -> TaskingCCompiler, origin/TaskingCCompiler)
Author: Krisztián Gergő <[email protected]>
Date:   Fri Dec 22 20:30:04 2023 +0100

    Update mesonbuild/backend/ninjabackend.py

    Co-authored-by: Charles Brunet <[email protected]>

D:\work\mesontasking>git branch
* TaskingCCompiler
  master

D:\work\mesontasking>git remote
origin

D:\work\mesontasking>git remote -v
origin  https://github.com/gerioldman/meson.git (fetch)
origin  https://github.com/gerioldman/meson.git (push)

And I built and installed my meson like this :

cd d:\work\mesontasking
python setup.py build
python setup.py install

My python installation is at

C:\Program Files\Python311

D:\work\mesontasking>python --version
Python 3.11.6

My Ninja is at :
c:\Ninja

According to your instructions, I have done the following from my project folder :

d:\work\mesontasking>meson.py setup --cross-file cross_build.txt --wipe builddir

The output is the same :

The Meson build system
Version: 1.2.99
Source dir: D:\work\meson_crossbuild
Build dir: D:\work\meson_crossbuild\builddir
Build type: cross build
Project name: tc_hello
Project version: 1.0
WARNING: Failed to activate VS environment: Could not find C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe
C compiler for the host machine: d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\cctc.exe (cctc 6.3.1.19041558)
Traceback (most recent call last):
  File "D:\work\mesontasking\mesonbuild\mesonmain.py", line 194, in run
    return options.run_func(options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\msetup.py", line 356, in run
    app.generate()
  File "D:\work\mesontasking\mesonbuild\msetup.py", line 179, in generate
    return self._generate(env, capture, vslite_ctx)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\msetup.py", line 201, in _generate
    intr = interpreter.Interpreter(b, user_defined_options=user_defined_options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreter\interpreter.py", line 331, in __init__
    self.parse_project()
  File "D:\work\mesontasking\mesonbuild\interpreterbase\interpreterbase.py", line 132, in parse_project
    self.evaluate_codeblock(self.ast, end=1)
  File "D:\work\mesontasking\mesonbuild\interpreterbase\interpreterbase.py", line 188, in evaluate_codeblock
    raise e
  File "D:\work\mesontasking\mesonbuild\interpreterbase\interpreterbase.py", line 180, in evaluate_codeblock
    self.evaluate_statement(cur)
  File "D:\work\mesontasking\mesonbuild\interpreterbase\interpreterbase.py", line 194, in evaluate_statement
    return self.function_call(cur)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreterbase\interpreterbase.py", line 520, in function_call
    res = func(node, func_args, kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreterbase\decorators.py", line 260, in wrapper
    return f(*nargs, **wrapped_kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreterbase\decorators.py", line 579, in wrapper
    return f(*wrapped_args, **wrapped_kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreter\interpreter.py", line 1308, in func_project
    self.add_languages(proj_langs, True, MachineChoice.HOST)
  File "D:\work\mesontasking\mesonbuild\interpreter\interpreter.py", line 1476, in add_languages
    success = self.add_languages_for(args, required, for_machine)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreter\interpreter.py", line 1549, in add_languages_for
    mlog.bold(' '.join(comp.linker.get_exelist())), comp.linker.id, comp.linker.version)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\linkers\linkers.py", line 160, in get_exelist
    return self.exelist.copy()
           ^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'copy'

meson.build:1:0: ERROR: Unhandled python exception

tsetsong · 2024-01-26T06:46:54Z

Hi all,

Update :

The line :

WARNING: Failed to activate VS environment: ...

or

Activating VS 17.8.4

Will not show if you have gcc installed. The section of meson code responsible for this is in Interpreter.py :

.. snip ...
    if not force:
        if shutil.which('cc'):
            return False
        if shutil.which('gcc'):
            return False
        if shutil.which('clang'):
            return False
        if shutil.which('clang-cl'):
            return False

It is possible to follow the instructions to install MinGW here :
https://dev.to/gamegods3/how-to-install-gcc-in-windows-10-the-easier-way-422j
and include the path to gcc.exe in PATH.

This will allow the shutil.which('gcc') to be True, and the function will return with 'False'.

However, this does not solve the original problem of the generation crash. I am still looking into this.

tsetsong · 2024-01-26T08:34:35Z

Hi,

Update :

I am now able to generate my build folder.

An additional modification is needed in my cross_build.txt file.

The

ld = compiler_path / 'ctc' / 'bin' / 'cctc.exe'

entry needs to be specified as :

c_ld = compiler_path / 'ctc' / 'bin' / 'cctc.exe'

I will proceed with compilation and porting and will report any other findings here as well.

Here is the stdout :

d:\work\buildsystem\meson_crossbuild>meson.exe setup --cross-file cross_build.txt --wipe builddir
The Meson build system
Version: 1.2.99
Source dir: D:\work\buildsystem\meson_crossbuild
Build dir: D:\work\buildsystem\meson_crossbuild\builddir
Build type: cross build
Project name: tc_hello
Project version: 1.0
WARNING: Failed to activate VS environment: Could not find C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe
C compiler for the host machine: d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\cctc.exe (cctc 6.3.1.19041558)
C linker for the host machine: d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\cctc.exe ltc 6.3.1.19041558
Compiler for language c for the build machine not found.
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: tricore
Host machine cpu: TC377
Target machine cpu family: tricore
Target machine cpu: TC377
Build targets in project: 1

tc_hello 1.0

  User defined options
    Cross files: cross_build.txt

Found ninja-1.11.1 at c:\ninja\ninja.EXE
WARNING: Cross file does not specify strip binary, result will not be stripped.
WARNING: Cross file does not specify strip binary, result will not be stripped.

I have also attached the build setup log (meson-log.txt file for reference.
meson-log.txt

Cross_build file :
cross_build.txt

Command ran :

meson.exe setup --cross-file cross_build.txt --wipe builddir

I notice in the meson-log.txt file that the archiver is used instead of the linker when detecting linker :

Detecting linker via: `d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\artc.exe --version` -> 0
stderr:
TASKING VX-toolset for TriCore: ELF archiver   v6.3r1 Build 19041558
Copyright 2002-2019 TASKING BV

How come ?

dcbaker

Sorry it's taken me so long to look at this. In general this all looks good. There's some thigns I think we can clean up here, but otherwise this looks fine from a code point of view.

mesonbuild/backend/ninjabackend.py

dcbaker · 2024-01-26T18:49:46Z

mesonbuild/backend/ninjabackend.py

@@ -402,7 +405,7 @@ def write(self, outfile):
        outfile.write(line)

        if use_rspfile:
-            if self.rule.rspfile_quote_style is RSPFileSyntax.MSVC:
+            if self.rule.rspfile_quote_style is RSPFileSyntax.MSVC or self.rule.rspfile_quote_style is RSPFileSyntax.TASKING:


Same here, use the in {...} syntax

dcbaker · 2024-01-26T18:51:52Z

mesonbuild/backend/ninjabackend.py

+                try:
+                    key = OptionKey('b_tasking_mil_link')
+                    if key in target.compilers['c'].base_options and target.get_option(key):
+                        final_obj_list = self.generate_mil_link(target, obj_list)
+                    else:
+                        final_obj_list = obj_list
+                except KeyError:
+                    final_obj_list = obj_list


You'll hit that exception when you don't have a C compiler, but no other cases it looks like. Can we handle that without a try/except, since that's not unexpected at all?

dcbaker · 2024-01-26T18:52:37Z

mesonbuild/backend/ninjabackend.py

+        try:
+            key = OptionKey('b_tasking_mil_link')
+            if key in target.compilers['c'].base_options and target.get_option(key) and src.endswith('.c'):
+                if obj_basename.endswith('.o'):
+                    obj_basename = obj_basename[:-1] + 'mil'
+                else:
+                    obj_basename = obj_basename[:-3] + 'mil'
+        except KeyError:
+            pass


This looks like the same case, where the missing c compiler is the issue.

The problem is that the target might not contain the built-in option, so it end ups throwing a KeyError. I've added a check if the target even contains it. Do you know any better solution? I've tried modifying the get_option call to fall back to the base_option var in the compilers.py file, but that had some CI failures.

But yes, the C compiler not being present is another problem, I've added a check for it.

Oh, main has the same CI failures, maybe the base_option fallback was not the culprit then.

mesonbuild/backend/ninjabackend.py

dcbaker · 2024-01-26T19:03:35Z

mesonbuild/compilers/detect.py

+            if 'PCP' in err:
+                return linkers.TaskingPCPStaticLinker(linker)
+            if 'MCS' in err:
+                return linkers.TaskingMCSStaticLinker(linker)


Do you actually want to fall through here and end up with the system linker, link.exe or ar?

mesonbuild/compilers/mixins/tasking.py

mesonbuild/linkers/linkers.py

mesonbuild/backend/ninjabackend.py

dcbaker · 2024-01-26T19:20:42Z

I notice in the meson-log.txt file that the archiver is used instead of the linker when detecting linker :

Detecting linker via: `d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\artc.exe --version` -> 0 stderr: TASKING VX-toolset for TriCore: ELF archiver v6.3r1 Build 19041558 Copyright 2002-2019 TASKING BV

How come ?

That looks like a Meson bug, we have the same message for both the archiver and dynamic linker... I'll send a patch for that.

edit: #12784

jpakkane · 2024-08-19T23:13:55Z

mesonbuild/compilers/c.py:833:9: error: "init" of "CCompiler" gets multiple values for keyword argument "linker"

This seems to be the same as the CodeQL error above.

jpakkane · 2024-08-25T23:07:33Z

We try really hard to avoid adding new options without a good reason (because otherwise you have 1000+ options in the blink of an eye). Since this is "sort of" a link time optimization, would it be possible to make the code use the b_lto option instead of its own?

dnicolodi · 2024-08-26T07:16:21Z

mesonbuild/compilers/mixins/tasking.py

+    # This is a bit clever, for mypy we pretend that these mixins descend from
+    # Compiler, so we get all of the methods and attributes defined for us, but
+    # for runtime we make them descend from object (which all classes normally
+    # do). This gives up DRYer type checking, with no runtime impact


I think there is a typo: gives up should be gives us.

Corrected it.

gerioldman · 2024-08-26T08:11:19Z

We try really hard to avoid adding new options without a good reason (because otherwise you have 1000+ options in the blink of an eye). Since this is "sort of" a link time optimization, would it be possible to make the code use the b_lto option instead of its own?

I think that makes sense, I'll try to do that. Do you thing that 'b_lto' fits for the static library part of the MIL linking? What I mean is that right now, tasking_mil_link is possible to set for static libraries. This has the effect of LTO inside the library, but not with other code parts. However, it is possible to create MIL libraries, which behave as static libs, but still benefit from LTO at the actual link stage.

Maybe a combination of prelink kward and b_lto could be used?

gerioldman · 2024-08-26T08:17:45Z

The MIL thing is a bit problematic as it is unique to this compiler and thus makes it a notable maintenance burden (as we don't have access to said compiler at all). All other compilers that I know of do this by outputting plain .o files with extra data in them (this is how link-time optimization works in e.g. Clang et al).

I've just learned this, but there is a free, non-commercial version of the compiler bundled inside the Aurix Development Studio by Infineon. The compiler cannot be used outside the IDE though, a Meson build would have to be setup inside Eclipse. I am open to create a debug project, so you can try around with the compiler if any issues arise.

mesonbuild/compilers/mixins/tasking.py

jpakkane · 2024-11-01T10:38:21Z

I think that makes sense, I'll try to do that. Do you thing that 'b_lto' fits for the static library part of the MIL linking? What I mean is that right now, tasking_mil_link is possible to set for static libraries. This has the effect of LTO inside the library, but not with other code parts. However, it is possible to create MIL libraries, which behave as static libs, but still benefit from LTO at the actual link stage.

Maybe a combination of prelink kward and b_lto could be used?

What happens if you use both at the same time?

Based on this description "LTO inside a static lib" is pretty much the same as prelinking whereas "LTO over mutliple libraries" is what Meson calls regular LTO. So hooking it up to those would make logical sense.

gerioldman · 2024-11-02T21:17:13Z

There should be three possible results:

regular compilation and linking
LTO over multiple libraries
LTO inside library

I think prelink should take priorioty, someone might set LTO for the whole project, but prelinking can only be set per target. Based on that:
No LTO and no prelink: regular compilation
LTO and no prelink: LTO over multiple libraries
No LTO or LTO and prelink: LTO inside static library

What do you think?

mesonbuild/backend/backends.py

@@ -25,6 +25,7 @@
 from .. import mesonlib
 from .. import mlog
 from ..compilers import LANGUAGES_USING_LDFLAGS, detect
+from ..utils.universal import get_compiler_for_source


mesonbuild/compilers/c.py

 from .mixins.emscripten import EmscriptenMixin
 from .mixins.metrowerks import MetrowerksCompiler
 from .mixins.metrowerks import mwccarm_instruction_set_args, mwcceppc_instruction_set_args
+from .mixins.tasking import TaskingCompiler


mesonbuild/compilers/mixins/apple.py

@@ -9,6 +9,7 @@
 from ...mesonlib import MesonException

 if T.TYPE_CHECKING:
+    from ...build import BuildTarget


mesonbuild/compilers/mixins/elbrus.py

 from .gnu import gnu_optimization_args
 from ...mesonlib import Popen_safe
 from ...options import OptionKey
+from ...build import BuildTarget


mesonbuild/compilers/mixins/gnu.py

@@ -17,6 +17,7 @@
 from ... import mesonlib
 from ... import mlog
 from ...options import OptionKey
+from ...build import BuildTarget


mesonbuild/compilers/mixins/tasking.py

+import typing as T
+
+from ...mesonlib import EnvironmentException, File
+from ...options import OptionKey


mesonbuild/compilers/mixins/tasking.py

+
+from ...mesonlib import EnvironmentException, File
+from ...options import OptionKey
+from ...build import BuildTarget, StaticLibrary


mesonbuild/compilers/mixins/tasking.py

+
+from ...mesonlib import EnvironmentException, File
+from ...options import OptionKey
+from ...build import BuildTarget, StaticLibrary


mesonbuild/compilers/mixins/tasking.py

+from ...compilers import lang_suffixes
+
+if T.TYPE_CHECKING:
+    from ...compilers.compilers import Compiler


gerioldman requested review from dcbaker and jpakkane as code owners October 8, 2023 01:30

github-advanced-security bot found potential problems Oct 8, 2023

View reviewed changes

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed

github-advanced-security bot found potential problems Oct 8, 2023

View reviewed changes

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed

gerioldman force-pushed the TaskingCCompiler branch from 57b5c26 to 242a2f5 Compare October 10, 2023 18:57

gerioldman force-pushed the TaskingCCompiler branch 2 times, most recently from 9838cdf to 2817c5f Compare October 12, 2023 13:14

gerioldman force-pushed the TaskingCCompiler branch 3 times, most recently from 885a87b to 7f3a06e Compare December 21, 2023 23:23

bruchar1 reviewed Dec 22, 2023

View reviewed changes

mesonbuild/backend/ninjabackend.py Outdated Show resolved Hide resolved

dcbaker requested changes Jan 26, 2024

View reviewed changes

gerioldman force-pushed the TaskingCCompiler branch 2 times, most recently from 2f9c728 to 8603a50 Compare August 24, 2024 23:59

dnicolodi reviewed Aug 26, 2024

View reviewed changes

gerioldman force-pushed the TaskingCCompiler branch from 8603a50 to 99340f8 Compare August 26, 2024 08:02

github-advanced-security bot found potential problems Aug 28, 2024

View reviewed changes

mesonbuild/compilers/mixins/tasking.py Fixed Show fixed Hide fixed

gerioldman force-pushed the TaskingCCompiler branch 5 times, most recently from cc15591 to 02d07a7 Compare August 28, 2024 21:36

gerioldman force-pushed the TaskingCCompiler branch 6 times, most recently from 6159668 to ec98f09 Compare September 10, 2024 21:22

jpakkane added this to the 1.7 milestone Oct 12, 2024

gerioldman force-pushed the TaskingCCompiler branch from ec98f09 to f5b9f4e Compare November 4, 2024 20:18

github-advanced-security bot found potential problems Nov 4, 2024

View reviewed changes

gerioldman added 2 commits November 4, 2024 21:25

Add TASKING to docs

169f8b5

Add TASKING compiler support

a4b964e

gerioldman force-pushed the TaskingCCompiler branch from f5b9f4e to e174630 Compare November 4, 2024 20:27

First draft version of Tasking MIL linking with b_lto and prelinking

e965caa

gerioldman force-pushed the TaskingCCompiler branch from e174630 to e965caa Compare November 10, 2024 22:17

		rules += [f"{rule}{ext}" for rule in [self.get_compiler_rule_name('tasking_mil_compile', compiler.for_machine)]
		for ext in ['', '_RSP']]

Add support for the TASKING compiler family, and its MIL linking feature #12342

Are you sure you want to change the base?

Add support for the TASKING compiler family, and its MIL linking feature #12342

Conversation

gerioldman commented Oct 8, 2023

tristan957 commented Oct 9, 2023

gerioldman commented Oct 9, 2023

gerioldman commented Oct 9, 2023

gerioldman commented Oct 10, 2023

tristan957 commented Oct 11, 2023

gerioldman commented Oct 12, 2023

bruchar1 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jpakkane commented Dec 30, 2023

gerioldman commented Dec 30, 2023

afahmy-ANGENG commented Jan 12, 2024

tsetsong commented Jan 23, 2024 • edited Loading

gerioldman commented Jan 23, 2024

tsetsong commented Jan 24, 2024 • edited Loading

afahmy-ANGENG commented Jan 24, 2024

tsetsong commented Jan 24, 2024 • edited Loading

tsetsong commented Jan 26, 2024 • edited Loading

tsetsong commented Jan 26, 2024 • edited Loading

dcbaker left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dcbaker commented Jan 26, 2024 • edited Loading

jpakkane commented Aug 19, 2024

jpakkane commented Aug 25, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gerioldman commented Aug 26, 2024

gerioldman commented Aug 26, 2024 • edited Loading

jpakkane commented Nov 1, 2024

gerioldman commented Nov 2, 2024

tsetsong commented Jan 23, 2024 •

edited

Loading

tsetsong commented Jan 24, 2024 •

edited

Loading

tsetsong commented Jan 24, 2024 •

edited

Loading

tsetsong commented Jan 26, 2024 •

edited

Loading

tsetsong commented Jan 26, 2024 •

edited

Loading

dcbaker commented Jan 26, 2024 •

edited

Loading

gerioldman commented Aug 26, 2024 •

edited

Loading