< (SIR). This article introduces SIR, and shows how to construct queries of it.
Last Update: May 2024
# Introduce SIR
Please visit [SIR](https://sir.ext.ti.com) and click on **Support FAQ** near the top of the page. A list of FAQ entries is displayed. Please understand the term *filter* is equivalent to *query*. Please read these FAQ entries.
* What is SIR?
* Do I need to login to use SIR?
* What is a filter and how can I create one?
* How can I save my filters?
* How can I export my filters?
The rest of this article presumes:
* You understand those FAQ entries
* You are logged into SIR
# Understand Compiler Version Numbers
Constructing a query requires a good understanding of compiler version numbers, and how they relate to one another. This is described in detail in the article [Compiler Version Numbers and What They Mean](https://software-dl.ti.com/ccs/esd/documents/sdto_cgt_compiler_version_numbers_and_what_they_mean.html). Focus on understanding the following:
* A version has three numbers separated by periods
* The last number is the patch
* A group of related versions, that differ only in the patch, is called a release stream
* A release stream may be active or inactive
### How a Compiler Version Number Appears in an Entry
A version number in an entry combines the name of the compiler with the version number. For example: **C7000_3.1.0.LTS**. That is because one entry can be found in multiple compilers. If an asterisk is at the end, like **ARMCLANG_3.2.2.LTS***, it means this version has not been released.
# Define Fields in an Entry
Constructing a query requires good knowledge of the names of the fields in a SIR entry, and the definition of what appears in those fields. It is not practical to define all the possible fields. This section defines the fields most relevant to entries regarding the compiler toolchains.
### Found In Release
For each active stream, the earliest version with the issue. Note it is not a complete list of every version that has the issue.
### Fix In Release
For each active stream, the earliest version with the fix. Note it is not a complete list of every version that has the fix.
### Type
SIR displays this field name as **Type** or **issuetype**. Valid values for this field are:
* **Bug** Behavior observed is incorrect, and needs to be fixed
* **Enhancement** A request for an improvement, change, new feature, etc. Complaints about slow execution or using too much memory are considered enhancements.
* **FAQ** Never used by compiler toolchain entries.
### Resolution
Valid values for this field are:
* **Unresolved** The entry has not been addressed
* **Fixed** The entry is fixed
* **Won't Fix** The entry has been investigated, and will not be fixed
* **Duplicate** The entry is very similar to another existing entry
* **Cannot Reproduce** The problem behavior cannot be reproduced, and so cannot be investigated
SIR supports a few more values for this field that never appear in entries related to the compiler toolchains.
### Priority
SIR supports 7 values for this field. Entries related to compiler toolchains use these 5. Listed in high-to-low order, they are:
* **Urgent**
* **High**
* **Medium**
* **Low**
* **Not Prioritized**
For the support policy regarding these priorities, please search [Compiler Version Numbers and What They Mean](https://software-dl.ti.com/ccs/esd/documents/sdto_cgt_compiler_version_numbers_and_what_they_mean.html) for the section titled *Support Model*.
# WARNING: Implied Version Numbers
An entry that is fixed only records two version numbers for each compiler toolchain:
1. The first version with an issue
2. The first version with a fix
If your version falls between these two, it is implied to be affected by the issue, even though the version number is not explicitly shown.
# Consider Existing Queries
Before writing a custom query, consider one of these existing queries. Regardless of whether a custom query is finally written, viewing these queries is likely to be helpful.
## In Compiler Release Notes
In recent versions of the compiler, the release notes are in an HTML file named **README.html**. It is available on the download page, and in the root directory of the compiler installation. View it with a web browser. Near the end, there is often a part titled *Known Defects*. In recent versions, this part contains a link that is a query of SIR. It is described as *dynamically generated*. Click this link to see the results returned by the query.
## On SIR
1. Go to the [SIR home page](https://sir.ext.ti.com)
2. Click on **Issues** → **Manage Filters**
3. On the left, click on **Search**
4. In the text box titled **Search**, enter **Compiler**
5. Click on the button titled **Search**
A table is displayed. The title of the first column is **Name**. Each entry in this column is a link to a query of SIR. Try them out to see what is returned.
# Two Search Modes: Basic and Advanced
Please view [this existing query](https://sir.ext.ti.com/jira/issues/?filter=10400). If it looks similar to this ...
the query is in Basic search mode. To change to Advanced search mode, click on **Advanced**.
If it looks similar to this ...
the query is in Advanced search mode. To change to Basic search mode, click on **Basic**.
# Explore an Existing Query
Please view [the same query](https://sir.ext.ti.com/jira/issues/?filter=10400) from the previous section. Be sure it is in Basic search mode. Explore how you can modify the search by clicking on field names like **Project** or **Bug**. Click on **More** to see how to add a search criterion. Click on a search criterion like **Found In Release** to see how to change it. Hover the mouse over the circled **x** to see a pop up about removing that criterion from the search.
On the far right, click on this button ...
Explore the differences between **Detail View** and **List View**.
Click on **Advanced** to see the query representation change to a text box that contains ...
```text
Product ~ "Code Generation Tools" AND status = Fixed AND issuetype in (Bug) AND "Found In Release" ~ "ARM*" AND resolutiondate >= 2016-03-01 ORDER BY resolutiondate DESC
```
If you made any changes to this query, you'll see something different.
# Construct a New Query using Basic Search Mode
The query constructed here is also used in the next section about an advanced query.
1. Go to the [SIR home page](https://sir.ext.ti.com)
2. Click on **Issues** → **Search for issues**
3. If you are in Advanced search mode, click on **Basic** to change to Basic search mode.
4. Click on **Type**, then check the box for **Bug**
5. Click on **Update**. Only **Bug** entries get returned.
6. Click on **More**. In the search box, type **Found In Release**, then check the box for it. This adds the criterion **Found In Release:All**.
7. Click on the new criterion **Found In Release:All**
8. In the text box which pops up type **ARMCLANG***
9. Click on **Update**. This changes the criterion to **Found In Release:ARMCLANG***.
10. Click on **More**. In the search box, type **Resolution**, then check the box for it. This adds the criterion **Resolution:All**.
11. Click on the new criterion **Resolution:All**
12. Check the box next to **Unresolved**
13. Click on **Search**. This changes the criterion to **Resolution:Unresolved**.
This query returns all the bugs on any version of the TI Arm Clang compiler which are not resolved.
# Modify a Query using Advanced Search Mode
This query builds on the one described in the previous section.
## Motivation
If you use the latest version of the TI Arm Clang compiler, the query from the previous section might be sufficient. But suppose you use an older version. Then you have to consider this possible sequence of events:
1. You obtain your version of the compiler
2. A bug is reported which is present in your version
3. The bug is fixed
For such an entry, the **Resolution** field is **Fixed**, and not **Unresolved**. Thus the previous query does not show it.
## Details
Suppose you use TI Arm Clang compiler version 2.1.2.LTS. Start with the query from the previous section. Here is one way to change it to account for bugs fixed after version 2.1.2.LTS.
* Click on **Advanced** to reveal a text box with these contents ...
```text
issuetype = Bug AND resolution = Unresolved AND "Found In Release" ~ "ARMCLANG*"
```
* Change the text box to ...
```text
issuetype = Bug AND (resolution = Unresolved AND "Found In Release" ~ "ARMCLANG*" OR resolution != Unresolved AND "Found In Release" ~ "ARMCLANG_2.1.*.LTS")
```
* Click on **Search**
## Explanation
Here is the query again, but reformatted and with // comments added.
```
issuetype = Bug // TERM1
AND ( resolution = Unresolved AND "Found In Release" ~ "ARMCLANG*" // TERM2
OR resolution != Unresolved AND "Found In Release" ~ "ARMCLANG_2.1.*.LTS") // TERM3
```
TERM1 and TERM2 are copied from the query in the previous section, and return the same results.
TERM3 is OR'd with TERM2, which means additional results are returned. This term is for the bugs fixed after version 2.1.2.LTS.
The first part of TERM3 is *not* written `resolution = FIXED`, because `resolution != Unresolved` captures that, and more. For instance, it captures **Won't Fix**.
The second part of TERM3 is *not* written `"Found In Release" ~ "ARMCLANG_2.1.2.LTS"`, because an entry only records the first version in a release stream found to have a bug. Thus **Found In Release** might contain **ARMCLANG_2.1.0.LTS** or **ARMCLANG_2.1.1.LTS**. If **Fix In Release** contains **ARMCLANG_2.1.3.LTS** or later, then version 2.1.2.LTS is affected, even though its version number does not appear. Using the wildcard asterisk character is not perfect, because it captures too much. Consider a bug reported in version 2.1.0.LTS and fixed in version 2.1.1.LTS. Version 2.1.2.LTS is not affected. But this query returns it.
## Explore the Advanced Query
1. On the far right, click on this icon and choose **List View**. The entries are displayed in a table, one per line.
2. Click on **Columns**
3. Clear the check boxes next to **Assignee**, **Reporter**, and **Status**
4. Click **Done**. These columns are removed from the table.
5. Click on **Columns**
6. In the **Search** box enter **Release**
7. Check the boxes for **Fix In Release** and **Found In Release**
8. Click **Done**. Those columns are added to the table.
9. Click on the column title **Found In Release** and drag it to the left of the column **Fix In Release**. An entry is found before it is fixed, so it is more intuitive to see the found column before the fixed column.
This next screenshot is representative of how the table looks.
Here are some optional steps to consider.
* To sort the table on a column, click on the column name.
* To save a query, click on **Save as**. Give the query a name. It appears on the left under **Favorite Filters**.
* To export the table as a spreadsheet, click on **Export** → **CSV (Current fields)**. Follow the remaining prompts. The resulting .csv file can be loaded into a spreadsheet application such as Microsoft Excel, Google Sheets, Apple Numbers, etc.
<!-- End of markdown source -->
<div id="footer"></div>
]]>