Agent-based reasoning test intention function-level compiler fault positioning method and system

Abstract

The application discloses a function-level compiler fault positioning method and system based on agent reasoning test intention, and realizes fine positioning from a file level to a function level. The method comprises the following steps: collecting multi-source context information, including a failed test case, a compilation intermediate product under an error compilation configuration, execution output differences under different configurations, and function-level execution track information; performing differential compilation and analysis based on the information, using a root cause analysis agent to analyze behavior difference data, identifying and generating a compiler fault root cause; using a fault positioning agent to evaluate the correlation degree of a candidate function and the fault root cause in combination with multi-dimensional context information, and performing suspicious degree sorting, and finally extracting a target function set to output a positioning result. The application significantly improves positioning accuracy and debugging efficiency.

Description

Technical Field

[0001] This invention belongs to the fields of software engineering, compiler testing and program analysis, and specifically relates to a function-level compiler fault location method that combines a Large Language Model Agent (LLM Agent) with program analysis technology. Background Technology

[0002] Compilers play a fundamental supporting role in the software development, building, and deployment process, and their correctness and reliability directly affect the behavior of downstream applications. Defects within the compiler can lead to erroneous executable programs during code translation, resulting in serious consequences such as system crashes, abnormal program behavior, and even security vulnerabilities. Adding to the complexity, when applications exhibit abnormal behavior, developers often struggle to quickly determine whether the problem originates from the application itself or from a compiler error, further increasing the difficulty of debugging and maintaining downstream programs. Therefore, efficiently identifying and locating compiler faults is crucial for ensuring the reliability and integrity of software systems.

[0003] To discover potential compiler faults, existing research has proposed various compiler testing methods, including random testing, fuzzing, and deep learning-based test case generation methods. These methods can help discover hidden faults in mainstream compilers such as GCC and LLVM by generating diverse and comprehensive test programs. However, discovering a test failure does not mean the fault has been resolved. In actual debugging, developers still need to further analyze the failed test program, compilation configuration, error output, and compiler source code to pinpoint the specific source file or code location causing the fault. Due to the large size of the compiler, numerous modules, and complex dependencies between files, a failed test program often involves a large number of interrelated source files during compilation, making root cause isolation extremely difficult and usually requiring developers to invest significant manual analysis resources.

[0004] Existing compiler fault localization methods primarily rely on test coverage information to narrow down the scope of suspected faults. One type of method (such as ODFL and LocSeq) mutates compiler optimization options or adjusts the optimization order to produce different execution coverages for the same failed test program under different compilation configurations, thereby inferring possible faulty files. This type of method can locate faults by utilizing the impact of optimization configurations on the compilation process, but its granularity is usually coarse because a single optimization option often affects multiple compiler source files or multiple compilation stages, making it difficult to accurately distinguish the true fault location. Another type of method (such as DiWi, RecBi, and LLM4CBI) mutates failed test programs to generate passing test programs with similar execution paths to the failed tests, and then uses the coverage differences between the failed and passing tests to locate faults. This type of method improves coverage difference analysis capabilities to some extent, but due to the complexity of compiler program execution paths and numerous constraints, generating test programs that can both compile successfully and effectively distinguish faulty files is very difficult. Therefore, although existing methods can assist compiler fault localization to some extent, their localization effectiveness is still limited by the quality of the test programs and the coverage information itself.

[0005] It is worth noting that most existing compiler fault location techniques use source files as the target, and their output typically includes several suspected files. A mature and effective function-level compiler fault location technique has not yet been developed. Even after developers obtain file-level location results, they still need to further analyze numerous functions, data structures, and call relationships within the object files to pinpoint the actual function causing the fault. For large compiler projects like GCC and LLVM, a single source file often contains multiple complex and interrelated functions, resulting in a significant gap between file-level location results and actual repair requirements. Therefore, the lack of automated techniques capable of locating faults at the function level has become a major factor limiting the efficiency and practicality of compiler fault location.

[0006] Furthermore, existing compiler fault location methods often fail to fully utilize the semantic information that developers rely on during manual debugging. In real-world debugging scenarios, developers not only focus on test coverage but also comprehensively analyze the code characteristics of failed test programs, compilation error messages, execution results under different optimization options, and the functional semantics of related compiler source files. For example, developers might infer from the loop structures, control flow characteristics, optimization triggering conditions, and error outputs in the test program that the fault may be related to compiler modules such as control flow optimization, value range propagation, loop transformation, or intermediate representation updates. Compared to simply relying on coverage statistics, this comprehensive reasoning approach, which combines test intent and source code functional semantics, better aligns with the actual process developers use to locate compiler faults and is more helpful in narrowing the fault search space. However, traditional fault location methods typically lack the ability to understand and integrate the aforementioned multi-source semantic information, limiting the accuracy and interpretability of the location results.

[0007] In recent years, large language models have made significant progress in logical reasoning and software engineering tasks, and have been applied to tasks such as code search, code generation, fault detection, code summarization, and general program fault location. Large language models possess strong code semantic understanding and contextual reasoning capabilities, providing new technical approaches for compiler fault location. Some general fault location methods have attempted to utilize large language models to analyze code or error information to improve fault location effectiveness. However, most existing fault location methods based on large language models are designed for ordinary software projects (such as FuseFL, AutoFL, SoapFL, and FlexFL), typically requiring traversal of the entire codebase or manual pre-narrowing of the location scope. Due to the large scale of compiler systems, the large number of source files, and the complex module dependencies, directly applying such methods to compiler fault location is easily affected by the input length limitations of large language models and the excessively large search space, making it difficult to obtain stable and effective location results. Furthermore, existing related methods have not yet established an effective mechanism for function-level fault location in compiler fault location scenarios.

[0008] Therefore, how to deeply integrate program analysis information with the reasoning capabilities of large language models to solve the problem of fine-grained fault localization in compiler fault location scenarios is a technical problem that this invention urgently needs to solve. Summary of the Invention

[0009] To address the issues of coarse-grained fault location, reliance on coverage information, and inability to utilize compiler semantics in existing compilers, this invention aims to propose a function-level compiler fault location method and system based on agent-based inference of test intent. By analyzing the semantic conflicts between failed test cases and dump files using an agent, the root cause is inferred, achieving function-level fault location and improving accuracy and efficiency.

[0010] To achieve the above objectives, the present invention employs the following technical solution: In a first aspect, the present invention implements a function-level compiler fault localization method based on agent reasoning test intent, comprising: Step 1: Collect multi-source context information related to the compiler fault to be located; wherein, the multi-source context information includes at least: the failed test case that triggered the fault, the intermediate compilation artifacts generated under the incorrect compilation configuration, the differences in the execution output of the failed test case under different compilation configurations, and the execution trajectory information of the failed test case at the function-level code unit; Step 2: Perform differential compilation and analysis based on the multi-source context information to obtain behavioral difference data between normal compilation state and error compilation state; use the root cause analysis agent to analyze the behavioral difference data, identify the root cause of the error compilation, and generate compiler fault root causes; Step 3: Based on the multi-source context information and the compiler fault root cause, use the fault location agent to perform function-level fault location on the candidate functions in the fault source file and output the function-level fault location result.

[0011] In some implementations, in step 2, when the root cause analysis agent performs root cause analysis, it is also used to: determine key difference intervals based on the behavioral difference data; analyze whether there are semantic or logical conflicts between the content within the key difference intervals and the semantics of the source program, so as to generate the compiler fault root cause.

[0012] In some implementations, step 3, in which the fault location agent performs function-level fault location, includes: Obtain multidimensional context information related to the compiler failure, the multidimensional context information including at least the failed test cases, the execution output differences, the abnormal behavior of the compilation intermediate products, and the root cause of the compiler failure; Based on the multidimensional context information, the correlation between each candidate function and the compiler fault root cause is evaluated, and the candidate functions are ranked according to the degree of suspicion based on the correlation. Based on preset filtering conditions, a set of target candidate functions is extracted from the sorting results, and a function-level fault location result containing the specific function location is generated.

[0013] In some implementations, in step 3, the fault location agent, during the process of inferring the correlation degree, is further configured to: obtain the functional semantic description of a specified candidate function; and, based on the functional semantic description, assist in determining the correlation between the candidate function and the compiler fault root cause.

[0014] In some implementations, in step 2, the root cause analysis agent follows compiler semantic preservation principles when analyzing the behavioral difference data. These principles include: compiler transformations must preserve the source language semantics; integer operations must adhere to sign and bit-width constraints; type conversions must preserve the extended behavior defined by the language; algebraic equivalence does not necessarily imply semantic equivalence; and the optimization process must maintain semantic correctness under all valid inputs.

[0015] In some implementations, both the root cause analysis agent and the fault location agent are decoupled from external program analysis capabilities through a unified API interface encapsulation method. Each agent is allowed to make a limited number of API calls when performing its own tasks in order to autonomously obtain the required program analysis evidence.

[0016] In some implementations, the API call includes: obtaining a list of fault-related fine-grained optimization options, obtaining information on differences in intermediate compilation artifacts, obtaining a source code fragment of a specified function, obtaining a functional summary of a specified function, prematurely ending the API call, and obtaining information on compilation stages where an anomaly exists.

[0017] Secondly, this invention implements a function-level compiler fault location system based on agent reasoning test intent, comprising: The information collection module is used to collect multi-source context information related to the compiler fault to be located; wherein, the multi-source context information includes at least: the failed test case that triggered the fault, the intermediate compilation artifacts generated under the faulty compilation configuration, the differences in the execution output of the failed test case under different compilation configurations, and the execution trajectory information of the failed test case at the function-level code unit; The root cause analysis module includes a root cause analysis agent, which is used to perform differential compilation and analysis based on the multi-source context information to obtain behavioral difference data between normal compilation state and error compilation state; and to use the root cause analysis agent to parse the behavioral difference data to identify the root cause of the error compilation and generate compiler fault root causes. The fault location module includes a fault location agent, which is used to perform function-level fault location on candidate functions in the fault source file based on the multi-source context information and the compiler fault root cause, and output the function-level fault location result.

[0018] Thirdly, the present invention also proposes an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements any of the described function-level compiler fault location methods based on agent reasoning test intent.

[0019] Fourthly, the present invention also proposes a non-transitory computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements any of the function-level compiler fault location methods based on agent reasoning test intent as described in the present invention.

[0020] This invention deeply integrates large language model agents with program analysis techniques, achieving refined compiler fault localization from the file level to the function level. Compared with existing dependency coverage statistics or file-level fault localization methods, this invention has the following advantages: By using a root cause analysis agent to perform semantic conflict analysis between failed test cases and intermediate compilation representations, the root cause of compilation errors can be accurately inferred, breaking through the limitation of traditional methods that rely solely on coverage information. The function-level fault location agent ranks candidate functions by suspicion based on multi-source information and root cause results, and refines the location granularity from the source file to the function level, which significantly narrows the scope of investigation for developers. The fusion and utilization of multi-source information (failed test cases, assemblers, optimization option outputs, dump differences, and function coverage) significantly improves the accuracy and interpretability of troubleshooting. Experiments show that the Top-1 troubleshooting success rate of this invention is 400% higher than that of the traditional SBFL method, with an average ranking improvement of 47.49%, effectively reducing the manpower and time costs of compiler fault debugging. Attached Figure Description

[0021] Figure 1 This is an overall flowchart of the function-level compiler fault location method based on agent reasoning test intent in Embodiment 1 of the present invention.

[0022] Figure 2 This is the overall technical roadmap for the function-level compiler fault localization method based on agent reasoning test intent as described in this invention.

[0023] Figure 3 This is a block diagram of a function-level compiler fault location system based on agent reasoning test intent, according to Embodiment 2 of the present invention.

[0024] Figure 4 A diagram summarizing the intelligent agent's prompts for the function's functionality.

[0025] Figure 5 Example diagram of key difference dump file interval prompts.

[0026] Figure 6 This is an example diagram for analyzing semantic conflict warning words in a dump file.

[0027] Figure 7 Example diagram for generating compiler error root cause warning words.

[0028] Figure 8 Example diagram of API call prompts for function-level fault location agents.

[0029] Figure 9 Example diagram of fault location prompts for a function-level fault location agent. Detailed Implementation

[0030] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of the present invention and should not be construed as limiting the scope of protection of the present invention.

[0031] Example 1: As Figure 1 As shown, this method proposes a function-level compiler fault localization technique based on a large language model agent combined with test intent. It uses known faulty GCC compiler source files as the localization scope, comprehensively utilizing failed test cases, assemblers generated by erroneous compilation configurations, program output results under different optimization options, differences in intermediate compilation dump files, and function coverage information of failed test cases. Combined with test intent analysis, it analyzes the causes of faulty compilation errors, and then the function-level fault localization agent automatically locates the faulty function. During the localization process, the fault localization agent can call function function summarization agents as needed to obtain semantic descriptions of candidate functions, achieving a ranking of the suspiciousness of functions within the faulty source file. This is further combined with... Figure 2 The technical route shown in the invention, and the specific steps included in the method of the present invention are as follows: Step 1: Collect multi-source context information related to the compiler fault to be located; First, it is determined that the faulty source file is a compiler source file known to have defects; the multi-source information includes at least: the failed test case that triggered the fault, the assembler generated under the faulty compilation configuration, the output results of the failed test case under different compilation optimization options, and the function coverage information of the failed test case in the faulty source file.

[0032] Secondly, for a given compiler fault, specific input information collection is performed. This technique first collects multi-source information required for fault analysis and function-level localization. In addition to the aforementioned failed test cases and assemblers, it further supplements the data with dump files and their differences under correct and incorrect compilation configurations, as well as a list of functions covered by the failed test cases in the faulty source file.

[0033] Finally, the core functions of each dimension of information are explained: failed test cases are used to represent the original semantics of the program, test intent, and fault triggering conditions; the output results under different optimization options are used to reflect the differences between correct and incorrect compilation behavior; the assembler is used to analyze the inconsistency between the final generated code and the source program semantics under incorrect compilation configuration; the differences in dump files are used to reflect the possible compilation stages and intermediate representation changes where errors may occur; and function coverage information is used to limit the candidate range for subsequent function-level fault location.

[0034] By using the above information in combination, the system can simultaneously observe compilation errors from the source code layer, intermediate presentation layer, and target code layer, providing sufficient evidence for subsequent analysis.

[0035] Step 2: Compile the failed test cases under both correct and incorrect compilation configurations, collect dump files from the two compilation processes, and compare the differences between the generated dump files. Based on the multi-source information and the dump file differences, use a root cause analysis agent to analyze the semantic conflicts between the failed test cases and the intermediate compilation representation, infer the root cause of the compilation error, and generate the compiler fault root cause. This step achieves fault root cause localization based on multi-configuration compilation and dump difference analysis. Furthermore, to precisely narrow down the investigation scope, this technology, combined with the testing intent, first performs a deep root cause analysis of the compilation errors to clarify "why the compilation errors occurred." The system compares two sets of dump files to obtain a list of differing dump files, symmetric difference patterns, and specific differences. To avoid indiscriminate analysis of a large number of dump files, the system further conducts dump difference boundary analysis, combining failed test cases, output results under different optimization options, assemblers under incorrect configurations, and the dump file difference list to determine which dump file the compilation errors originated from.

[0036] During this process, the root cause analysis agent has a maximum of 10 API call opportunities. It can call `getdumpmisslist()` to retrieve missing dump file information, `getdumpdiff(dumpfilename)` to retrieve detailed differences for a specified dump file, or call `exit()` to prematurely end information retrieval. The root cause analysis agent is the core reasoning unit responsible for root cause analysis. It is configured to proactively collect difference data (such as dump file differences) during the compilation process via API interfaces in the initial stage of compiler fault localization, and perform semantic conflict analysis based on this multi-source information to ultimately infer the root cause of the compilation error (i.e., the compiler fault root cause).

[0037] After identifying the key difference dump file, the system further analyzes whether the dump file content conflicts semantically or logically with the source code of the failed test cases. If a conflict exists, the identified differences and possible causes of the conflict are extracted; if no obvious conflict exists, "NO" is output. Subsequently, the root cause analysis agent integrates the failed test cases, the output results under different optimization options, the assembler under incorrect configurations, the dump semantic conflict analysis results, the first dump file with a difference and its detailed difference content, to determine whether the intermediate representation under the incorrect compilation configuration is semantically equivalent to the intermediate representation under the correct compilation configuration, and identifies the semantic constraints that are violated.

[0038] The root cause analysis process described above strictly adheres to compiler semantic preservation principles, including but not limited to: compiler transformations must preserve the source language semantics; integer operations must adhere to sign and bit-width constraints; type conversions must preserve the extended behavior defined by the language; algebraic equivalence does not necessarily imply semantic equivalence; and the optimization process must maintain semantic correctness under all valid inputs. To supplement the analytical evidence, the API call mechanism is designed as follows: the root cause analysis agent has a maximum of 10 API call opportunities, which can call `getfnooption()` to obtain a list of fine-grained optimization options related to the fault, `getdumpmisslist()` to obtain information on missing dump files, `getdumpdifflist()` to obtain a list of dump file differences, `getdumpdiff(dumpfilename)` to obtain detailed differences for a specified dump file, or `exit()` to prematurely terminate the API call.

[0039] Finally, after the API call ends, the root cause analysis agent outputs a formatted result indicating the root cause of the defect, namely the [reason-start] reason for the compiler failure and the [reason-end] reason. This result serves as an important basis for subsequent function-level fault localization.

[0040] Step 3: Based on the multi-source information and the compiler fault root cause, use the fault location agent to perform function-level fault location on the candidate functions determined by the function coverage information in the fault source file, and output the function-level fault location result; First, after obtaining the fault cause analysis results, the system invokes a function-level fault location agent to automatically sort and locate the candidate function set determined by the function coverage information. This agent takes failed test cases, output results under different compilation optimization options, assemblers generated under incorrect compilation configurations, defect root cause analysis results, faulty source file names, and the function coverage list as input. It comprehensively analyzes the code characteristics, output differences, assembly exceptions, test intent, fault causes, and candidate function coverage of the failed test cases, ultimately determining which functions in the coverage function list are more likely to cause the incorrect compilation.

[0041] Furthermore, to accurately assess the suspiciousness of candidate functions, the fault localization agent follows this reasoning process: First, it understands the testing intent of the failed test cases, such as whether the test involves loop structures, conditional statements, integer boundary behaviors, type conversions, control flow changes, pointer operations, bitwise operations, or specific optimization triggering patterns. Based on this, it determines which optimization configurations or processes are related to the fault by combining the output differences under different optimization options. Then, it analyzes the inconsistencies between the final generated code and the source code semantics by combining the assembly program generated under incorrect configurations. Finally, it closely combines the root cause analysis results and the function coverage list to infer the degree of correlation between each candidate function and the cause of the fault.

[0042] Note: During the automatic location process, the fault location agent has up to 10 API call permissions to obtain underlying code details or terminate the analysis in advance.

[0043] Specifically, the fault location agent of this invention can autonomously select the interface to call based on the current inference needs. For example, when it is necessary to determine whether a certain function is responsible for a specific optimization logic, getmethod(methodname) can be called to obtain the function's source code snippet; when it is necessary to quickly understand the responsibilities of multiple candidate functions, getmethodsummary(methodname) can be called to obtain a summary of the function's functions; when it is necessary to determine whether a candidate function is related to the optimization process that triggered the error compilation, getfnooptionlist() can be called to obtain the fault-related fine-grained optimization options.

[0044] Furthermore, when the fault location agent calls the `getmethodsummary(methodname)` interface, the system will trigger the function summary agent. This function summary agent takes the function source code in the specified compiler source file as input and outputs a functional description of the function using natural language generation technology, thereby assisting the fault location agent in completing reasoning more efficiently.

[0045] In step 3, the fault location agent performs function-level fault location by: inferring the correlation between each candidate function and the compiler fault root cause based on the code characteristics of the failed test cases, the output differences under different compilation optimization options, the abnormal behavior of the assembler, and the compiler fault root cause; ranking the candidate functions by suspicion based on the correlation degree, and outputting the function-level fault location result.

[0046] In a preferred embodiment of the present invention, the specific process of the function-level fault location agent performing function-level fault location includes: First, the function-level fault location agent acquires multi-dimensional contextual information related to compiler faults, including at least: code characteristics of failed test cases (such as loop structures, control flow characteristics, optimization triggering conditions, etc.), output differences under different compilation optimization options, abnormal behavior of the assembly program generated under misconfiguration, and the root cause of compiler faults.

[0047] Secondly, based on the aforementioned multi-dimensional contextual information, the function-level fault localization agent infers the correlation between each candidate function and the root cause of the compiler fault. Specifically, the agent can perform a comprehensive evaluation through the following dimensions: ① Code feature matching degree: Analyze whether the candidate function involves a specific code structure (such as loop, conditional branch, type conversion, etc.) triggered by the test program; ② Optimization process correlation: Combine fine-grained optimization option information to determine whether candidate functions participate in the optimization process that triggers error compilation; ③ Semantic conflict fit: Compare the functional semantics of the candidate functions with the semantic conflict types identified in the root cause analysis; ④ Coverage and anomaly correlation: Combine the function coverage and assembly anomaly behavior for comprehensive reasoning.

[0048] Finally, the function-level fault location agent sorts the candidate functions by their degree of suspicion based on their relevance, and generates function-level fault location results that include the specific function location.

[0049] The above process can be summarized as follows: based on the code characteristics of the failed test cases, the output differences under different compilation optimization options, the abnormal behavior of the assembler, and the root cause of the compiler failure, infer the degree of correlation between each candidate function and the root cause of the compiler failure; based on the degree of correlation, rank the candidate functions by suspicion; finally, combine the failed test cases and function coverage information to generate function-level fault location results containing the specific function location.

[0050] The system outputs a ranking of functions based on their suspected nature. Once the function-level fault location agent completes an API call or reaches its maximum call limit, the system requires it to output the final function-level fault location result. The higher the function's ranking in the output, the more suspicious it is of containing a compiler defect. This mechanism allows developers to directly obtain the ranking of suspected functions within the faulty source file, significantly reducing the cost of manually checking a vast number of functions throughout the entire source file.

[0051] Example 2: Figure 3 As shown, this invention provides a function-level compiler fault location system based on agent reasoning testing intent, comprising an information collection module 100 and a root cause analysis module 200 connected in sequence. The information collection module 100 is used to collect multi-source information related to the compiler fault to be located; wherein, the fault source file is a compiler source file known to have defects; the multi-source information includes at least: the failed test case that triggered the fault, the assembler generated under the faulty compilation configuration, the output results of the failed test case under different compilation optimization options, and the function coverage information of the failed test case in the fault source file; The root cause analysis module 200 includes a root cause analysis agent, which is used to compile the failed test cases under correct compilation configuration and incorrect compilation configuration respectively, collect dump files of the two compilation processes and compare the difference information of the generated dump files; based on the multi-source information and the difference information of the dump files, the root cause analysis agent is used to analyze the semantic conflict between the failed test cases and the intermediate compilation representation, infer the root cause of the incorrect compilation, and generate the compiler failure root cause; The fault location module 300 includes a fault location agent, which is used to perform function-level fault location on candidate functions determined by the function coverage information in the fault source file based on the multi-source information and the compiler fault root cause, and output the function-level fault location result.

[0052] The specific process of the present invention is further described below through specific embodiments.

[0053] 1. Input information collection, detailed description as follows: For the GCC compiler fault to be located, the system first collects multi-source information related to the fault, including: the failed test cases that triggered the fault; the assembler generated under the incorrect compilation configuration; the output results under different compilation optimization options; and the function coverage information of the failed test cases in the fault source file.

[0054] Among them, failed test cases are used to reflect the original semantics and test intent of the program; the output results under different optimization options are used to show the difference between correct and incorrect behavior; the assembler generated under incorrect configuration is used to observe the abnormal behavior at the final machine code level; and the function coverage information is used to narrow down the candidate set for subsequent function-level localization.

[0055] By using the above information in combination, the system can simultaneously observe compilation errors from the source code layer, intermediate presentation layer, and target code layer, providing sufficient evidence for subsequent analysis.

[0056] 2. Generate dump file difference information, as detailed below: The system compiles failed test cases under both correct and incorrect compilation configurations, and collects all dump files generated during the two compilation processes.

[0057] Dump files record intermediate representations generated by the compiler at different optimization stages, serving as crucial evidence for analyzing compiler behavior. Since incorrect compilation often stems from erroneous semantic transformations of the program during a particular optimization stage, comparing dump files with those from correct and incorrect configurations can help pinpoint the location of the problem.

[0058] Subsequently, the system compares the dump files from the two compilation processes stage by stage, obtaining: a list of dump files with differences; a list of symmetric differences between the dump files; and the specific differences for each dump file.

[0059] The difference list is used to identify the compilation stages that have changed; the symmetric difference list is used to find out whether certain optimization stages have been skipped or added; and the specific difference content is used to analyze what changes have occurred in the intermediate representation.

[0060] The above information can help the root cause analysis agent determine at which compilation stage the error first occurred, and which optimization processes are involved in the error propagation process.

[0061] 3. Summary of the functions of the intelligent agent, as detailed below: The functional summary agent is used to generate functional semantic descriptions of compiler functions, providing semantic information support at the function level for subsequent fault localization. The agent is constructed using a large language model.

[0062] Because industrial-grade compilers like GCC contain a large number of complex functions with massive source code, deep logical layers, and abstract variable naming, it is often difficult to quickly understand their true responsibilities based solely on function names or source code snippets. Therefore, this invention designs a function summary agent to automatically perform semantic analysis on functions in GCC source files and generate structured function summary information.

[0063] For each function in the GCC source file, the system can automatically extract its source code and call the function summary agent to generate a corresponding function description. When the subsequent location agent calls the `getmethodsummary(methodname)` interface, the system further calls the agent to perform in-depth analysis of the specified function's source code and returns the corresponding semantic summary result, such as... Figure 4 The image shows an example of a function that summarizes the agent's prompts.

[0064] By using a function summary mechanism, complex and lengthy function source code can be converted into natural language descriptions that are more suitable for reasoning in large language models. Compared to directly providing the model with a large amount of source code, this approach can significantly reduce the context length, improve the model's efficiency in understanding function responsibilities, and enhance the interpretability of the fault localization process, enabling the model to understand the relationship between functions and defects at the semantic level.

[0065] 4. Root cause analysis agent, described in detail below: The root cause analysis agent is used to analyze semantic conflicts between failed test programs and intermediate compilation representations and assemblers, and generate compiler fault root causes, thereby solving the problem of "why the compilation error occurred".

[0066] Unlike traditional fault location methods that only focus on the erroneous results, this invention further analyzes the internal mechanism of error generation. By studying the changes in intermediate representations during compilation, it identifies key optimization transformations that lead to semantic corruption, providing a high-quality reasoning basis for subsequent function-level fault location.

[0067] (a) Identify the key difference dump file ranges, as described below: Since large compilers can generate a large number of dump files, performing in-depth analysis on all the difference files would significantly increase the analysis cost. Therefore, this invention first identifies the most valuable difference intervals.

[0068] System calls are used to perform dump difference boundary analysis on large language model agents, such as Figure 5 The image shows instances of prompt words to identify key difference dump file ranges. The following information is used as input: failed test cases; output results under different compiler optimization options; assemblers generated under incorrect configurations; and a list of dump files showing differences.

[0069] Based on the behavior of the test program, the abnormal characteristics of the output, and the changes in the dump file, the agent analyzes which compilation stage the error is most likely to start from and determines which compilation stage the error will eventually propagate to.

[0070] To enhance analytical capabilities, the agent is allowed to make a maximum of 10 API calls. The APIs that can be called include: getdumpmisslist(): get the symmetric difference set of the dump file; getdumpdiff(dumpfilename): get the specific differences of the specified dump file; exit(): terminate the API call early.

[0071] During the analysis, the agent can gradually examine the differences in key dump files and narrow down the scope of analysis based on the propagation of these differences.

[0072] After the API call is completed, the agent outputs only two dump file names, representing the start and end of the difference dump file, thus forming the key areas for subsequent in-depth analysis.

[0073] (b) Analyze semantic conflicts in the dump file After identifying the key difference intervals, the system performs semantic conflict analysis on the dump files following the first key difference, such as... Figure 6 The image shows semantic conflict warning words in the dump file. The system provides failed test cases, output results under different compilation optimization options, and the specific contents of the dump file to the large language model for inference analysis.

[0074] During the analysis, the model focuses on determining whether the transformations in the intermediate representation still maintain the semantics of the source program. The analysis results include: if a semantic conflict is found, the model outputs the identified semantic differences, logical differences, and possible causes; if no obvious conflict is found, the model outputs NO.

[0075] This step allows the system to filter out key evidence that is truly related to the compilation error from a large number of dump differences, rather than just focusing on surface structural changes.

[0076] (c) Generate compiler fault root causes The system calls the root cause analysis agent, such as Figure 7 As shown, to generate compiler fault root cause warning word instances, the following information is taken as input: failed test cases; output results under different compiler optimization options; assembler generated under faulty configuration; dump semantic conflict information; the first dump file with discrepancies and its detailed discrepancies.

[0077] The root cause analysis agent conducts in-depth analysis of the error compilation problem, focusing on determining whether the intermediate representation under the incorrect configuration is semantically equivalent to the intermediate representation under the correct configuration, and identifying the semantic constraints that are violated.

[0078] During the analysis, the agent not only needs to explain why the current test case failed, but also needs to further explain why the optimization transformation is incorrect under normal circumstances, that is, to analyze the essence of the defect from the perspective of compiler design principles.

[0079] The following compiler semantic constraints must be followed during the analysis process: compilation transformations must preserve the semantics of the source language; integer operations must adhere to sign and bit-width constraints; type conversions must preserve the extended behavior defined by the language; algebraic equivalence does not necessarily imply semantic equivalence; and the optimization process must maintain semantic correctness under all valid inputs.

[0080] To further supplement the analytical evidence, the root cause analysis agent is allowed to make a maximum of 10 API calls. The APIs that can be called include: getfnooptionlist(): retrieves a list of fine-grained optimization options related to the fault; getdumpmisslist(): retrieves the symmetric difference set of the dump files; getdumpdifflist(): retrieves a list of dump files with differences; getdumpdiff(dumpfilename): retrieves detailed differences of the specified dump file; and exit(): terminates the API call early.

[0081] The agent can dynamically acquire more evidence as needed for analysis and continuously revise its reasoning process. After the API call is completed, the root cause analysis agent integrates all known information and outputs the compiler fault root cause analysis results, in the following format: "[reason-start] The reason for the compiler failure [reason-end]" This result not only describes the direct cause of the error, but also reveals the optimization logic flaws that lead to the compilation error, providing a clear direction for subsequent function-level localization.

[0082] 5. Function-level fault location agent Function-level fault location agents, such as Figure 8 The example shown is an API call prompt word instance for a function-level fault location intelligent agent. It is used to sort candidate functions by suspicion within the function coverage of a known fault source file, combining test intent, root cause analysis results, assembly code, and function semantic information, thereby solving the problem of "which function the defect is located in".

[0083] Compared to traditional file-level location methods, this invention can further narrow down the location range and refine the results to the function granularity, thereby significantly reducing the troubleshooting costs for developers.

[0084] (a) Execute function-level fault location The system call function-level fault location agent takes the following information as input: failed test cases; output results under different compilation optimization options; assembler generated under incorrect configuration; the cause of the defect generated by the root cause analysis agent; function coverage information in the fault source file; and the name of the known fault source file.

[0085] The agent's task is to identify the functions most likely to contain defects from the list of functions actually covered by failed test cases in the fault source file, and then sort them according to their degree of suspicion.

[0086] (b) Information acquisition mechanism during the positioning process To improve positioning accuracy, the function-level fault location agent is allowed to make a maximum of 10 API calls.

[0087] The callable APIs include: getfnooptionlist(): retrieves a list of fine-grained optimization options related to the fault; getmethod(methodname): retrieves a source code snippet of a specified function; getmethodsummary(methodname): retrieves a summary of the functionality of a specified GCC function; and exit(): terminates the API call prematurely.

[0088] The `getmethodsummary(methodname)` function automatically calls the function summary agent to generate or retrieve the function description of the corresponding function.

[0089] During the localization process, the agent can flexibly choose to obtain source code or functional summaries based on the inference needs. For example, when it is necessary to verify the specific business logic of a function, the source code can be viewed directly; when it is necessary to quickly understand the responsibilities of multiple candidate functions, the functional summaries can be obtained first.

[0090] In addition, the agent can combine fine-grained optimization option information to determine whether a candidate function participates in the optimization process that triggers erroneous compilation, thereby further improving the sorting accuracy.

[0091] (c) Output function-level fault location results Once the function-level fault location agent completes an API call or reaches its maximum call limit, the system requires it to output the final sorting result within the covered function list, such as... Figure 7 As shown, these are the fault location prompts for the function-level fault location agent.

[0092] Furthermore, the agent API call mechanism in this invention adopts a unified interface encapsulation approach, decoupling the large language model from external program analysis capabilities. Agents do not need to directly access underlying analysis tools; instead, they obtain the necessary information through a restricted API. Each agent is allowed a maximum of 10 API calls. This effectively controls call costs and inference complexity, while also guiding the model to prioritize obtaining the most critical and valuable program analysis evidence, thereby improving overall inference efficiency and localization quality.

[0093] Furthermore, the root cause analysis agent and the function-level fault location agent form a seamless connection. The root cause analysis agent is responsible for inferring the semantic causes of defects from differences in test programs, output results, assemblers, and dumps; the function-level fault location agent, based on this, combines function coverage information, function function summaries, and optimization process knowledge to rank and locate candidate functions. This phased, layer-by-layer reasoning approach effectively reduces the difficulty of the model completing all tasks at once, and improves the accuracy, stability, and interpretability of function-level fault location results.

[0094] Through the collaborative work of the three components mentioned above, this invention achieves a complete automated process, from failed test cases, compilation output results and assemblers, to test intent, defect root cause analysis, and then to the ranking of suspicious functions within the faulty source file. Compared with existing compiler fault location methods that mainly rely on test coverage information, static rule analysis, or can only output file-level results, this invention can fully utilize the code semantic understanding ability, autonomous information acquisition ability, and cross-stage reasoning ability of large language model agents. Combined with multi-source evidence such as dump differences, fine-grained optimization options, function coverage information, and function function summaries, it achieves more fine-grained, more interpretable, and more in line with actual development and debugging needs for compiler fault location, providing efficient and reliable technical support for large-scale compiler fault analysis and repair.

[0095] To verify the effectiveness of the proposed function-level compiler fault localization technique based on agent-based reasoning testing intent, ChatGPT-4o was selected as the default large language model, with both temperature and top-p set to the default value of 1.0. Experiments were conducted on two GCC compiler fault datasets, including 60 classic datasets and 20 newly collected datasets. The faults in the 20 newly collected GCC datasets were all later than the knowledge cutoff time of ChatGPT-4o-2024-08-06, thus mitigating the possibility that the large language model had already encountered the relevant fault information during training and effectively reducing the impact of data leakage on the experimental results.

[0096] In terms of experimental comparison, since there is currently a lack of publicly available methods for locating compiler fault functions at the function level, this invention selects the spectrum-based fault localization method SBFL (Spectrum-Based Fault Localization) as the baseline method. SBFL, by default, uses the Ochiai formula to calculate the suspicion score of candidate functions. ,in, Candidate functions f Suspicion score, Indicates the candidate function for coverage f Number of failed test cases Indicates the candidate function for coverage f The number of test cases that passed; This indicates the total number of failed test cases. The larger the value, the more likely it is to be a candidate function. f The higher the probability of a fault, the better. This invention uses commonly used metrics in fault localization, such as Top-N, MFR, and MAR, for evaluation. Top-N indicates whether the true faulty function appears in the top N positions of the suspicious function ranking list. This paper uses four metrics: Top-1, Top-5, Top-10, and Top-20. A higher Top-N value indicates that developers can more easily find the true fault location among fewer candidate functions. MFR represents the average rank of the first appearance of the true faulty function, and MAR represents the average rank of the true faulty function. For MFR and MAR, lower values ​​indicate better localization results because developers need to check fewer candidate functions. Figure 1 The figures show the experimental results of this invention. The "↑" column indicates the relative improvement of the method of this invention compared to the baseline.

[0097]

[0098] Table 1 presents the experimental results of the method of this invention on 60 classic GCC compiler fault datasets. As can be seen from the table, the method of this invention significantly outperforms the SBFL method in all metrics. Specifically, in the Top-1 metric, the method of this invention successfully located 15 faulty functions at the top, while SBFL only located 3, representing a relative improvement of 400.00%. In the Top-5 metric, the method of this invention successfully located 27 faulty functions, while SBFL only located 14, representing a relative improvement of 92.86%. In the Top-10 and Top-20 metrics, the method of this invention located 38 and 44 faulty functions respectively, compared to SBFL's 23 and 33, representing improvements of 65.22% and 33.33% respectively. These results demonstrate that the method of this invention can more effectively prioritize faulty functions in the candidate list, thereby significantly reducing the number of functions that developers need to manually inspect.

[0099] Meanwhile, on 60 classic GCC fault datasets, the MFR of the method proposed in this invention is 9.31, while the MFR of SBFL is 17.73, representing a relative improvement of 47.49%; the MAR of the method proposed in this invention is 11.62, while the MAR of SBFL is 19.12, representing a relative improvement of 39.23%. This indicates that the method proposed in this invention can not only increase the number of Top-N hits, but also reduce the position of the true fault function in the ranking list, making the fault function appear more prominently to developers, thereby improving actual debugging efficiency. Table 2 shows the experimental results of this invention on the latest dataset.

[0100]

[0101] Table 2 presents the experimental results of the method of this invention on a newly collected dataset of 20 GCC compiler faults. This dataset contains recently collected real GCC faults to verify the generalization ability of the method under new fault scenarios. As can be seen from the table, the method of this invention still achieves better localization performance than SBFL. In the Top-1 metric, the method of this invention successfully located 3 faults, while SBFL failed to locate any faults at the top. In the Top-5 metric, the method of this invention successfully located 6 faults, while SBFL only located 2, representing a relative improvement of 200.00%. In the Top-10 metric, the method of this invention successfully located 14 faults, while SBFL only located 6, representing a relative improvement of 133.33%. In the Top-20 metric, the method of this invention successfully located 17 faults, while SBFL only located 13, representing a relative improvement of 30.77%.

[0102] On the newly collected dataset of 20 GCC faults, the method of this invention achieves an MFR of 13.90, a 21.60% improvement compared to SBFL's 17.73; the method of this invention achieves an MAR of 19.33, a 32.41% improvement compared to SBFL's 28.60. This indicates that even when faced with recently collected real compiler faults, the method of this invention can still maintain good localization performance and has a certain degree of generalization ability and stability.

[0103] In summary, the experimental results demonstrate that the proposed function-level compiler fault localization technique based on agent-based reasoning of test intent effectively improves compiler fault localization. Compared to the traditional SBFL method, this invention introduces a large language model agent to comprehensively reason from multiple sources, including failed test case characteristics, test intent, assembler code, output results under different optimization options, dump differences, root causes of faults, and function function summaries, thereby more accurately determining the location of the true faulty function. This method not only improves hit metrics such as Top-1, Top-5, Top-10, and Top-20, but also significantly reduces MFR and MAR, indicating that it can reduce the scope of developer investigation and improve the efficiency of compiler defect debugging and maintenance. Therefore, this invention's method has good effectiveness, practicality, and promotional value in function-level compiler fault localization tasks.

[0104] This invention proposes a function-level compiler fault localization method based on agent-based inference of test intent. By deeply integrating a large language model agent with program analysis techniques, the method guides the agent to autonomously acquire and comprehensively analyze multi-source information such as differences in intermediate compilation representations, fault-related optimization options, and source code semantics. This allows for a deep understanding of test intent and accurate inference of the root cause of compilation errors, ultimately refining the fault localization results from the file level to the function level. This significantly improves the accuracy, granularity, and interpretability of fault localization, providing strong support for the testing and maintenance of large-scale compiler software. This method should be able to further combine multi-source information such as failed test programs, compilation configurations and their output results, differences in intermediate compilation states, and functional summaries of source code, based on test coverage analysis, to guide the large language model to understand test intent, infer potential fault root causes, and refine the fault localization results to the function level. In this way, the analysis process of developers debugging compiler faults can be more fully simulated, improving the accuracy, granularity, and interpretability of fault localization. This overcomes the shortcomings of existing technologies in lacking function-level compiler fault localization capabilities, thus providing more effective technical support for the testing, debugging, and maintenance of large-scale compiler software.

[0105] The above description is merely an embodiment of the present invention and is not intended to limit the methods proposed in this invention. The scope of protection of this invention is defined by the claims. Any obvious modifications or variations in form and detail made by those skilled in the art without departing from the spirit and scope of this invention should fall within the scope of protection of this invention.

Claims

1. A method for locating function-level compiler faults based on agent-based reasoning and testing intent, characterized in that, include: Step 1: Collect multi-source context information related to the compiler fault to be located; wherein, the multi-source context information includes at least: the failed test case that triggered the fault, the intermediate compilation artifacts generated under the incorrect compilation configuration, the differences in the execution output of the failed test case under different compilation configurations, and the execution trajectory information of the failed test case at the function-level code unit; Step 2: Perform differential compilation and analysis based on the multi-source context information to obtain behavioral difference data between normal compilation state and error compilation state; use the root cause analysis agent to analyze the behavioral difference data, identify the root cause of the error compilation, and generate compiler fault root causes; Step 3: Based on the multi-source context information and the compiler fault root cause, use the fault location agent to perform function-level fault location on the candidate functions in the fault source file and output the function-level fault location result.

2. The function-level compiler fault localization method based on agent reasoning test intent according to claim 1, characterized in that, In step 2, when the root cause analysis agent performs root cause analysis, it is also used to: determine key difference intervals based on the behavioral difference data; analyze whether there are semantic or logical conflicts between the content within the key difference intervals and the semantics of the source program, so as to generate the compiler fault root cause.

3. The function-level compiler fault localization method based on agent reasoning test intent according to claim 1, characterized in that, In step 3, the fault location agent performs function-level fault location, including: Obtain multidimensional context information related to the compiler failure, the multidimensional context information including at least the failed test cases, the execution output differences, the abnormal behavior of the compilation intermediate products, and the root cause of the compiler failure; Based on the multidimensional context information, the correlation between each candidate function and the compiler fault root cause is evaluated, and the candidate functions are ranked according to the degree of suspicion based on the correlation. Based on preset filtering conditions, a set of target candidate functions is extracted from the sorting results, and a function-level fault location result containing the specific function location is generated.

4. The function-level compiler fault localization method based on agent reasoning test intent according to claim 1, characterized in that, In step 3, the fault location agent, in the process of inferring the correlation degree, is also used to: obtain the functional semantic description of the specified candidate function; and based on the functional semantic description, assist in judging the correlation between the candidate function and the compiler fault root cause.

5. The method according to claim 1, characterized in that, In step 2, the root cause analysis agent follows the compiler semantic preservation principle when analyzing the behavioral difference data. The principle includes: compilation transformations must preserve the source language semantics, integer operations must follow sign and bit width constraints, type conversions must preserve the extended behavior defined by the language, algebraic equivalence does not necessarily mean semantic equivalence, and the optimization process must maintain semantic correctness under all legal inputs.

6. The function-level compiler fault localization method based on agent reasoning test intent according to claim 1, characterized in that, Both the root cause analysis agent and the fault location agent are decoupled from external program analysis capabilities through a unified API interface encapsulation method. Each agent is allowed to make a limited number of API calls when performing its own tasks in order to autonomously obtain the required program analysis evidence.

7. The function-level compiler fault localization method based on agent reasoning test intent according to claim 6, characterized in that, The API calls include: obtaining a list of fault-related fine-grained optimization options, obtaining information on differences in intermediate compilation products, obtaining source code snippets of specified functions, obtaining a functional summary of specified functions, prematurely ending API calls, and obtaining information on compilation stages where exceptions exist.

8. A function-level compiler fault localization system based on agent reasoning and testing intent, characterized in that, include: The information collection module is used to collect multi-source context information related to the compiler fault to be located; wherein, the multi-source context information includes at least: the failed test case that triggered the fault, the intermediate compilation artifacts generated under the faulty compilation configuration, the differences in the execution output of the failed test case under different compilation configurations, and the execution trajectory information of the failed test case at the function-level code unit; The root cause analysis module includes a root cause analysis agent, which is used to perform differential compilation and analysis based on the multi-source context information to obtain behavioral difference data between normal compilation state and error compilation state; and to use the root cause analysis agent to parse the behavioral difference data to identify the root cause of the error compilation and generate compiler fault root causes. The fault location module includes a fault location agent, which is used to perform function-level fault location on candidate functions in the fault source file based on the multi-source context information and the compiler fault root cause, and output the function-level fault location result.

9. An electronic device, characterized in that, The invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, when the processor executes the program, it implements the function-level compiler fault location method based on the agent reasoning test intent as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the function-level compiler fault location method based on the agent reasoning test intent as described in any one of claims 1 to 7.

Images