GCC Release 14 Testsuite Status: Commit 172fec15

Hey everyone,

Here's the testsuite status for the Release 14 branch, specifically for commit 172fec15312cc79b5a48fe6a672a02c3f825697d. This report dives into the performance and stability of the compiler across various configurations. We'll be looking at new failures, resolved issues, and those pesky unresolved failures that still need our attention. Let's break it down!

Discussion category : patrick-rivos, gcc-postcommit-ci

Additional information:

Summary

Let's get straight to the summary. Below is a breakdown of the testsuite results for gcc, g++, and gfortran. We'll see the number of failures, categorized into new, resolved, and unresolved. Each category also includes a link to the previous hash for comparison. This helps us track progress and identify potential regressions.

Diving Deep into Unresolved Failures

In this Release 14 Branch Testsuite Status report, let's specifically address the unresolved failures identified in the testsuite for commit 172fec15312cc79b5a48fe6a672a02c3f825697d. Unresolved failures are the issues that persist from previous builds, and they require careful examination to ensure the stability and reliability of our gcc compiler. We will go through the different test configurations where failures are still occurring, providing a clear picture of the challenges we face. By understanding these issues, we can better prioritize our efforts to resolve them, ensuring the gcc compiler remains robust across various platforms and architectures. The data presented here offers insights into specific configurations and test scenarios where the compiler is not performing as expected. Addressing these unresolved failures is a critical step in maintaining the high standards of quality that we aim for in the gcc compiler development process. Let's dive into the details of each unresolved failure category, examining the implications and the steps needed to tackle these persistent issues.

Linux Platform Failures

RVA23U64 Profile (lp64d medlow multilib)

For the Linux platform, specifically in the RVA23U64 profile with lp64d medlow multilib settings, we are seeing a significant number of unresolved failures. The gcc compiler shows 59 failures, with 37 of those being unique, while g++ has 12 failures (3 unique), and gfortran reports 12 failures (2 unique). These numbers indicate potential stability issues in this configuration, especially for gcc. When analyzing these failures, it's important to consider the lp64d setting, which refers to the 64-bit data model, and the medlow setting, which likely relates to memory usage or optimization levels. The multilib aspect suggests that multiple libraries are being tested, which could point to ABI (Application Binary Interface) compatibility issues or problems with specific library interactions. The high number of failures in gcc compared to g++ and gfortran might indicate problems with the C language-specific features or optimizations in this environment. To effectively address these failures, it's essential to delve into the details of the failed test cases. Examining the error messages, logs, and the specific source code involved can provide valuable clues. Furthermore, comparing the current failures with the previous hash (717141d592f9f01617ac0962907f37e91e7cae52) can highlight whether the issues are new or persistent. This context is crucial for determining the appropriate course of action, which may involve code fixes, configuration adjustments, or further investigation into the toolchain and build environment.

rv32 Bitmanip, rv32gc, rv32gcv (ilp32d medlow)

Moving on, the rv32 Bitmanip, rv32gc, and rv32gcv configurations, all using ilp32d medlow settings, also exhibit a notable number of unresolved failures. In these configurations, gcc shows 27 failures (14 unique) for both rv32 Bitmanip and rv32gc, and 53 failures (35 unique) for rv32gcv. g++ reports 8 failures (2 unique) for all three configurations, while gfortran consistently has 12 failures (2 unique). The ilp32d setting here implies a 32-bit integer, long, and pointer data model, and medlow suggests a medium-low level of optimization or resource usage. The rv32 Bitmanip configuration likely involves tests related to bit manipulation extensions, rv32gc includes general-purpose and compressed instructions, and rv32gcv incorporates vector extensions. The higher failure count in rv32gcv for gcc might be attributed to issues in the vector instruction implementations or interactions between vector and scalar code. The consistency in g++ and gfortran failures across these configurations may indicate underlying problems in the platform or toolchain rather than language-specific issues. To address these failures effectively, it's essential to examine the specific test cases failing in each configuration. Detailed analysis of the error messages, compiler outputs, and generated assembly code can provide insights into the root causes. Furthermore, comparing the results with the previous hash (717141d592f9f01617ac0962907f37e91e7cae52) is crucial to determine whether the failures are newly introduced or have been persisting. Understanding the nature and history of these failures will guide targeted debugging and resolution efforts.

rv64 Bitmanip, rv64 Vector Crypto, rv64gc, rv64gcv (lp64d medlow)

Similarly, the rv64 Bitmanip, rv64 Vector Crypto, rv64gc, and rv64gcv configurations, all using lp64d medlow settings, show several unresolved failures. For rv64 Bitmanip and rv64gc, gcc reports 25 failures (13 unique), g++ has 8 failures (2 unique), and gfortran shows 12 failures (2 unique). The rv64 Vector Crypto configuration has 49 gcc failures (33 unique), 12 g++ failures (3 unique), and 12 gfortran failures (2 unique). Lastly, rv64gcv exhibits 49 gcc failures (33 unique), 12 g++ failures (3 unique), and 12 gfortran failures (2 unique). In this context, lp64d refers to the 64-bit data model, and medlow likely indicates a medium-low optimization level. The rv64 Bitmanip configuration focuses on bit manipulation instructions, rv64 Vector Crypto includes tests for vector cryptography extensions, rv64gc covers general-purpose and compressed instructions, and rv64gcv incorporates vector extensions. The higher number of failures in configurations involving vector and crypto extensions suggests potential issues with the implementation or integration of these features. The consistent pattern of g++ and gfortran failures across configurations, while lower than gcc, may point to broader toolchain or platform-related issues rather than specific language problems. Addressing these failures requires a detailed examination of the failing test cases in each configuration. Analyzing error messages, compiler outputs, and generated assembly can provide clues to the root causes. Additionally, comparing the current results with the previous hash (717141d592f9f01617ac0962907f37e91e7cae52) is essential to determine whether the failures are new or persistent. This historical context is invaluable for prioritizing debugging and resolution efforts.

Newlib Platform Failures

RVA23U64 Profile (lp64d medlow multilib)

Switching gears to the Newlib platform, let’s look at the unresolved failures. The RVA23U64 profile, with lp64d medlow multilib settings, shows a significant number of failures. gcc has 75 failures (36 unique), g++ reports 15 failures (4 unique), while gfortran shows no failures (0/0). This high number of failures in gcc, especially compared to g++, suggests potential issues specific to the C language implementation or library interactions in this environment. The lp64d setting refers to the 64-bit data model, and medlow likely signifies medium-low optimization or resource usage settings. The multilib aspect indicates that the test suite is exercised with multiple library versions, which can expose ABI (Application Binary Interface) issues or library compatibility problems. To effectively address these failures, it’s critical to analyze the failing test cases in detail. Examining the error messages, compiler outputs, and the specific parts of the code being tested can provide valuable insights. Comparing these results with the previous hash (717141d592f9f01617ac0962907f37e91e7cae52) is also crucial to determine if these failures are new or have been ongoing. This historical context helps in prioritizing debugging and resolution efforts.

rv32 Bitmanip, rv32gc, rv32gcv, rv32imac, rv32imc (ilp32d/ilp32 medlow multilib)

For the Newlib platform, several rv32 configurations exhibit a high number of unresolved failures. The rv32 Bitmanip and rv32gc configurations, both using ilp32d medlow settings, show 66 gcc failures (22 unique) and 59 gcc failures (21 unique), respectively. g++ reports 35 failures (5 unique) for both. The rv32gcv configuration, also with ilp32d medlow multilib, has 85 gcc failures (38 unique) and 39 g++ failures (6 unique). The rv32imac and rv32imc configurations, using ilp32 medlow multilib, each show 67 gcc failures (23 unique) and 35 g++ failures (5 unique). In all these configurations, gfortran reports no failures (0/0). The ilp32 and ilp32d settings indicate 32-bit integer, long, and pointer data models, and medlow signifies medium-low optimization or resource usage. The rv32 Bitmanip configuration tests bit manipulation extensions, rv32gc covers general-purpose and compressed instructions, rv32gcv incorporates vector extensions, and rv32imac/rv32imc include integer multiplication and atomics (imac) or only integer multiplication (imc). The higher gcc failure counts, particularly in rv32gcv, may point to issues with vector instruction implementations or interactions between vector and scalar code. The consistent lack of gfortran failures suggests the problems may be specific to C and C++ language features or library interactions. To address these failures effectively, detailed analysis of failing test cases in each configuration is necessary. Examining error messages, compiler outputs, and generated assembly can reveal root causes. Additionally, comparing results with the previous hash (717141d592f9f01617ac0962907f37e91e7cae52) is essential to determine if failures are new or persistent, guiding debugging efforts.

rv32imac_zba_zbb_zbc_zbs, rv32imc_zba_zbb_zbc_zbs, rv32imc_zba_zbb_zbc_zbs_zicsr_zifencei, rv32imc_zicsr_zifencei (ilp32 medlow multilib)

Continuing with the Newlib platform, several other rv32 configurations are showing significant unresolved failures. Specifically, rv32imac_zba_zbb_zbc_zbs, rv32imc_zba_zbb_zbc_zbs, rv32imc_zba_zbb_zbc_zbs_zicsr_zifencei, and rv32imc_zicsr_zifencei, all using ilp32 medlow multilib settings, exhibit similar failure patterns. Each of these configurations reports 67 gcc failures (23 unique), 35 g++ failures (5 unique), and 0 gfortran failures (0/0). These configurations include various extensions related to bit manipulation (zba, zbb, zbc, zbs), control and status register access (zicsr), and instruction-fetch fence (zifencei). The consistent number of failures across these configurations suggests a common underlying issue, possibly related to how these extensions are implemented or interact with each other in the Newlib environment. The fact that gfortran shows no failures continues to suggest the problems are more aligned with C and C++ language-specific features or library interactions. Analyzing the failing test cases in detail is essential to identify the root cause. This involves examining error messages, compiler outputs, and generated assembly code to understand how these extensions are being handled. Comparing the current results with the previous hash (717141d592f9f01617ac0962907f37e91e7cae52) is crucial to determine if the failures are new or persistent, helping to focus debugging efforts effectively.

rv64 Bitmanip, rv64 Vector Crypto, rv64gc, rv64gcv, rv64imac, rv64imc (lp64d/lp64 medlow multilib)

Finally, in the Newlib platform, the rv64 configurations also present several unresolved failures. The rv64 Bitmanip and rv64gc configurations, both with lp64d medlow settings, show 48 gcc failures (17 unique), 11 g++ failures (3 unique), and 0 gfortran failures (0/0). The rv64 Vector Crypto and rv64gcv configurations, with lp64d medlow multilib settings, report 65 gcc failures (32 unique), 15 g++ failures (4 unique), and 0 gfortran failures (0/0). The rv64imac and rv64imc configurations, using lp64 medlow multilib, each show 49 gcc failures (18 unique), 11 g++ failures (3 unique), and 0 gfortran failures (0/0). These rv64 configurations cover bit manipulation (Bitmanip), vector cryptography (Vector Crypto), general-purpose and compressed instructions (gc), vector extensions (gcv), integer multiplication and atomics (imac), and integer multiplication only (imc). The persistent pattern of higher gcc failures, especially in configurations involving vector and cryptographic extensions, suggests potential issues in these specific areas. The lack of gfortran failures across these configurations reinforces the likelihood that the issues are related to C and C++ language features or library interactions. To tackle these failures, detailed analysis of failing test cases is essential. This includes examining error messages, compiler outputs, and generated assembly code to identify the root causes. Comparing the current results with the previous hash (717141d592f9f01617ac0962907f37e91e7cae52) is also critical to determine if the failures are new or have persisted, guiding debugging and resolution efforts effectively.

rv64imac_zba_zbb_zbc_zbs, rv64imc_zba_zbb_zbc_zbs, rv64imc_zba_zbb_zbc_zbs_zicsr_zifencei, rv64imc_zicsr_zifencei (lp64 medlow multilib)

Lastly, still in the Newlib platform, the rv64imac_zba_zbb_zbc_zbs, rv64imc_zba_zbb_zbc_zbs, rv64imc_zba_zbb_zbc_zbs_zicsr_zifencei, and rv64imc_zicsr_zifencei configurations, all with lp64 medlow multilib settings, consistently show unresolved failures. Each of these configurations reports 49 gcc failures (18 unique), 11 g++ failures (3 unique), and 0 gfortran failures (0/0). These configurations test various extensions, including bit manipulation (zba, zbb, zbc, zbs), control and status register access (zicsr), and instruction-fetch fence (zifencei). The consistent number of failures across these configurations suggests a common underlying issue, likely related to how these extensions are implemented or interact within the Newlib environment. The absence of gfortran failures further supports the idea that the problems are specific to C and C++ language features or library interactions. To pinpoint the root cause, detailed analysis of failing test cases is essential. This involves examining error messages, compiler outputs, and generated assembly code to understand how these extensions are being processed. Comparing the current results with the previous hash (717141d592f9f01617ac0962907f37e91e7cae52) is crucial to determine if the failures are new or persistent, which will help in focusing debugging efforts effectively.

Summary of Findings and Next Steps

Okay, guys, we've dug deep into the unresolved failures in the Release 14 Branch Testsuite Status for commit 172fec15312cc79b5a48fe6a672a02c3f825697d. We've seen patterns emerge, particularly in the Linux and Newlib platforms, and across different configurations involving vector and cryptographic extensions. The consistent failures in gcc compared to g++ and gfortran suggest that many of these issues might be C-specific or related to how C interacts with certain libraries and extensions. The next step is to roll up our sleeves and get into the details of these failing test cases. We need to analyze those error messages, compiler outputs, and generated assembly code to really understand what's going on. Plus, comparing these results with the previous hash is super important to see if we're dealing with new issues or long-standing problems. This will help us prioritize our debugging efforts. So, let's keep the ball rolling, dive into the specifics, and work together to squash these bugs and make this release rock solid! Stay tuned for more updates, and let's keep the communication flowing as we tackle these challenges.

Associated run is: https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/16844080884