> On Feb 24, 2022, at 4:10 AM, Richard Biener <rguent...@suse.de> wrote:
> 
> On Sat, 19 Feb 2022, Qing Zhao wrote:
> 
>> Hi,
>> 
>> Per our discussion in the bug report 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
>> 
>> We decided to go with the following solution:
>> 
>> 1. avoid emitting switch-unreachable warnings for -ftrivial-auto-var-init;
>> 2. adding a new option -Wtrivial-auto-var-init to emit warnings for the 
>> switch-unreadable cases to suggest the user modify the source code;
>> 3. update documentation of -ftrivial-auto-var-init for the limitation on 
>> switch-unreachable cases and introduce the new option -Wtrivial-auto-var-init
>> 
>> with the above 1, we can resolve the current immediate issue of spurious 
>> warnings of using -ftrivial-auto-var-init to make kernel build succeed;
>> with the above 2, we provide the user a way to know that 
>> -ftrivial-auto-var-init has limitation on the switch-unreachable cases, and 
>> user should modify the source code to avoid this problem;
>> with the above 3, we will provide the user a clear documentation of the 
>> -ftrivial-auto-var-init and also provide suggestions how to resolve this 
>> issue. 
>> 
>> There are two patches included for this bug.  This is the first one.
>> 
>> The patches has been bootstrapped and regression tested on both x86 and 
>> aarch64.
>> 
>> Okay for commit?
>> 
>> Thanks.
>> 
>> Qing.
>> 
>> ===========================
>> 
>> From 65bc9607ff35ad49e5501ec5c392293c5b6358d0 Mon Sep 17 00:00:00 2001
>> From: Qing Zhao <qing.z...@oracle.com>
>> Date: Fri, 18 Feb 2022 15:35:53 +0000
>> Subject: [PATCH 1/2] Don't emit switch-unreachable warnings for
>> -ftrivial-auto-var-init (PR102276)
>> 
>> for the following testing case:
>>  1 int g(int *);
>>  2 int f1()
>>  3 {
>>  4     switch (0) {
>>  5         int x;
>>  6         default:
>>  7         return g(&x);
>>  8     }
>>  9 }
>> compiling with -O -ftrivial-auto-var-init causes spurious warning:
>> warning: statement will never be executed [-Wswitch-unreachable]
>>    5 |         int x;
>>      |             ^
>> This is due to the compiler-generated initialization at the point of
>> the declaration.
>> 
>> We could avoid the warning by adjusting the routine
>> "maybe_warn_switch_unreachable" to exclude the following cases:
>> 
>> when
>> flag_auto_var_init > AUTO_INIT_UNINITIALIZED
>> And
>> call to .DEFERRED_INIT
>> 
>> 2022-02-18 Qing Zhao  <qing.z...@oracle.com>
>> gcc/ChangeLog:
>> 
>>      * gimplify.cc (maybe_warn_switch_unreachable): Don't warn for compiler
>>      -generated initializations for -ftrivial-auto-var-init.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>>      * gcc.dg/auto-init-pr102276-1.c: New test.
>>      * gcc.dg/auto-init-pr102276-2.c: New test.
>> ---
>> gcc/gimplify.cc                             |  8 ++++-
>> gcc/testsuite/gcc.dg/auto-init-pr102276-1.c | 38 +++++++++++++++++++++
>> gcc/testsuite/gcc.dg/auto-init-pr102276-2.c | 38 +++++++++++++++++++++
>> 3 files changed, 83 insertions(+), 1 deletion(-)
>> create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr102276-1.c
>> create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr102276-2.c
>> 
>> diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
>> index f570daa015a..4e3bbf5314d 100644
>> --- a/gcc/gimplify.cc
>> +++ b/gcc/gimplify.cc
>> @@ -2103,7 +2103,13 @@ maybe_warn_switch_unreachable (gimple_seq seq)
>>        && TREE_CODE (gimple_goto_dest (stmt)) == LABEL_DECL
>>        && DECL_ARTIFICIAL (gimple_goto_dest (stmt)))
>>      /* Don't warn for compiler-generated gotos.  These occur
>> -       in Duff's devices, for example.  */;
>> +       in Duff's devices, for example.  */
>> +    ;
>> +      else if ((flag_auto_var_init > AUTO_INIT_UNINITIALIZED)
>> +            && (gimple_call_internal_p (stmt, IFN_DEFERRED_INIT)))
>> +    /* Don't warn for compiler-generated initializations for
>> +      -ftrivial-auto-var-init.  */
>> +    ;
> 
> I think you want to instead skip these in warn_switch_unreachable_r
> since otherwise a .DEFERRED_INIT can silence the warning for a real
> stmt following it that is not reachable.

Oh, yeah, you are right.
Will fix this.

Thanks.

Qing

Reply via email to