public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Carl Love <cel@linux.ibm.com>
To: GCC Patches <gcc-patches@gcc.gnu.org>,
	Peter Bergner <bergner@linux.ibm.com>,
	segher <segher@kernel.crashing.org>,
	David Edelsohn <dje.gcc@gmail.com>, cel <cel@linux.ibm.com>
Subject: Re: [PATCH] rs6000, fix test builtins-1-p10-runnable.c
Date: Thu, 17 Oct 2024 13:31:54 -0700	[thread overview]
Message-ID: <c6ef543c-2caf-43c3-80a7-c1e4e51899d1@linux.ibm.com> (raw)
In-Reply-To: <cae96b63-3975-4a69-8b1d-e7603d691d99@linux.ibm.com>

Ping 2


On 10/9/24 7:43 AM, Carl Love wrote:
> Ping, FYI this is a fairly simple fix to a testcase.
>
>
> On 10/3/24 8:11 AM, Carl Love wrote:
>> GCC maintainers:
>>
>> The builtins-1-10-runnable.c has the debugging inadvertently 
>> enabled.  The test uses #ifdef to enable/disable the debugging. 
>> Unfortunately, the #define DEBUG was set to 0 to disable debugging 
>> and enable the call to abort in case of error.  The #define should 
>> have been removed to disable debugging.
>> Additionally, a change in the expected output which was made for 
>> testing purposes was not removed.  Hence, the test is printing that 
>> there was an error not calling abort.  The result is the test does 
>> not get reported as failing.
>>
>> This patch removes the #define DEBUG to enable the call to abort and 
>> restores the expected output to the correct value.  The patch was 
>> tested on a Power 10 without the #define DEBUG to verify that the 
>> test does fail with the incorrect expected value.  The correct 
>> expected value was then restored.  The test reports 19 expected 
>> passes and no errors.
>>
>> Please let me know if this patch is acceptable for mainline. Thanks.
>>
>> Carl
>>
>>
>> --------------------------------------------------------------------------------------- 
>>
>>
>> rs6000, fix test builtins-1-p10-runnable.c
>>
>> The test has two issues:
>>
>> 1) The test should generate execute abort() if an error is found.
>> However, the test contains a #define 0 which actually enables the
>> error prints not exectuting void() because the debug code is protected
>> by an #ifdef not #if.  The #define DEBUG needs to be removed to so the
>> test will abort on an error.
>>
>> 2) The vec_i_expected output was tweeked to test that it would fail.
>> The test value was not removed.
>>
>> By removing the #define DEBUG, the test fails and reports 1 failure.
>> Removing the intentionally wrong expected value results in the test
>> passing with no errors as expected.
>>
>> gcc/testsuite/ChangeLog:
>>     * gcc.target/powerpc/builtins-1-p10-runnable.c: Remove #define
>>     DEBUG.    Replace vec_i_expected value with correct value.
>> ---
>>  gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c | 5 +----
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git 
>> a/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c 
>> b/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c
>> index 222c8b3a409..3e8a1c736e3 100644
>> --- a/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c
>> @@ -25,8 +25,6 @@
>>  #include <math.h>
>>  #include <altivec.h>
>>
>> -#define DEBUG 0
>> -
>>  #ifdef DEBUG
>>  #include <stdio.h>
>>  #endif
>> @@ -281,8 +279,7 @@ int main()
>>      /* Signed word multiply high */
>>      i_arg1 = (vector int){ 2147483648, 2147483648, 2147483648, 
>> 2147483648 };
>>      i_arg2 = (vector int){ 2, 3, 4, 5};
>> -    //    vec_i_expected = (vector int){-1, -2, -2, -3};
>> -    vec_i_expected = (vector int){1, -2, -2, -3};
>> +    vec_i_expected = (vector int){-1, -2, -2, -3};
>>
>>      vec_i_result = vec_mulh (i_arg1, i_arg2);
>>
>


  reply	other threads:[~2024-10-17 20:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-03 15:11 Carl Love
2024-10-09 14:43 ` Carl Love
2024-10-17 20:31   ` Carl Love [this message]
2024-10-28 23:28     ` Carl Love
2024-11-05 16:27       ` Carl Love
2024-11-14 21:36         ` Carl Love
2024-11-21 15:49           ` Carl Love
2024-11-23 21:39             ` Mike Stump
2024-11-24 13:42 ` Kewen Lin
2025-01-17 15:50   ` Carl Love
  -- strict thread matches above, loose matches on Subject: below --
2024-09-19 23:40 [PATCH] rs6000, Fix " Carl Love
2024-09-19 23:48 ` Carl Love

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6ef543c-2caf-43c3-80a7-c1e4e51899d1@linux.ibm.com \
    --to=cel@linux.ibm.com \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).