public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66590] switch statement: incorrect warning "reaches end of non-void function"
Date: Fri, 19 Jun 2015 07:47:00 -0000	[thread overview]
Message-ID: <bug-66590-4-LALLIsmV5n@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-66590-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66590

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-19
                 CC|                            |manu at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
The gimple we build is very strange:

            switch (xD.2336) <default: <D.2342>, case 1: <D.2340>>
            {
              <D.2340>:
              {
                struct AD.2324 tmpD.2341;

                try
                  {
                    try
                      {
                        D.2345 = 1;
                        return D.2345;
                      }
                    finally
                      {
                        # USE = anything
                        # CLB = anything
                        __comp_dtor D.2329 (&tmpD.2341);
                      }
                  }
                finally
                  {
                    tmpD.2341 = {CLOBBER};
                  }
              }
              goto <D.2343>;
              <D.2342>:
              D.2345 = 0;
              return D.2345;
            }
            <D.2343>:
          }
        }

That goto doesn't make much sense.
>From gcc-bugs-return-489374-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 19 07:47:32 2015
Return-Path: <gcc-bugs-return-489374-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 116808 invoked by alias); 19 Jun 2015 07:47:31 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 116753 invoked by uid 48); 19 Jun 2015 07:47:25 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66593] driver-i386.c: -mtune=native unavailable with non-bootstrapped build of libgccjit with gcc < 5
Date: Fri, 19 Jun 2015 07:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66593-4-2OQ2JiFFlw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66593-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66593-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01706.txt.bz2
Content-length: 2927

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66593

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to David Malcolm from comment #0)
> Currently libgccjit uses -mtune=generic; I'm working on enabling
> -mtune=native for libgccjit.
> 
> However, on i386/x86_64 with a non-bootstrap build using gcc < 5,
> host_detect_local_cpu does nothing.
> 
> This is due to:
> 
> commit b587c12551143c14f023860a1dbdf7316ae71f27
> Author: uros <uros@138bc75d-0d04-0410-961f-82ee72b054a4>
> Date:   Fri Oct 17 06:00:58 2014 +0000
> 
>         * config/i386/cpuid.h (__cpuid): Remove definitions that handle %ebx
>         register in a special way.
>         (__cpuid_count): Ditto.
>         * config/i386/driver-i386.h: Protect with
>         "#if defined(__GNUC__) && (__GNUC__ >= 5 || !defined(__PIC__))".
>         (host_detect_local_cpu): Mention that GCC with non-fixed %ebx
>         is required to compile the function.
>  
> Uros said (in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01516.html):
> > The only drawback would be that non-bootstrapped build with gcc < 5.0
> > will ignore -march=native, but I think this should be acceptable."
> 
> Jakub said (in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01520.html):
> > At least on Linux, driver-i386.c should not be built with PIC normally,
> > so at least changing
> > #if __GNUC__ >= 5
> > to
> > #if defined(__GNUC__) && (__GNUC__ >= 5 || !defined(__PIC__))
> > would limit the -march=native change for non-bootstrapped compilers to
> > Darwin only (or what other targets use PIC by default?).
> 
> The jit builds with PIC, and -mtune=native would be highly appropriate for
> jitted-code; so this is a somewhat bigger deal.
> 
> Currently the instructions for building libgccjit recommend
> --disable-bootstrap, so everyone following those on i386/x86_64 with gcc < 5
> as the system compiler is going to get a hobbled -mtune=native.
> 
> That said, the above code runs inside the driver, and libgccjit doesn't yet
> run that part of the driver, so some extra work will be needed by me on top
> of this before we can get it to do better than -mtune=generic.

The core of the problem lies in cpuid.h. The definitions of __cpuid and
__cpuid_count now use "b" register constraint which is not usable with GCC < 5
when -fPIC is used (these versions just declare %ebx as fixed, unallocable PIC
register).

We *really* don't want to litter cpuid.h with a compatibility stuff (there were
horrible bugs when 64bit code used %xchgl with 32bit registers), since cpuid.h
is intended to be used with the just built compiler.

To avoid the troubles, I'd suggest to just document that gcc-5 is needed for
x86 -mtune=native jit and cut away the past. Otherwise, we could introduce some
kind of local cpuid-compat.h to house all the compatibility stuff and hide the
file in some dark corner.
>From gcc-bugs-return-489376-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 19 08:02:09 2015
Return-Path: <gcc-bugs-return-489376-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27604 invoked by alias); 19 Jun 2015 08:02:09 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27559 invoked by uid 48); 19 Jun 2015 08:02:04 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/64130] vrp: handle non zero constant divided by range cannot be zero.
Date: Fri, 19 Jun 2015 08:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64130-4-UddanzZaae@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64130-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64130-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01708.txt.bz2
Content-length: 586

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd130

--- Comment #8 from Marc Glisse <glisse at gcc dot gnu.org> ---
(for cmp1 (eq ne)
     cmp2 (lt ge)
 (simplify
  (cmp1 (trunc_div @0 @1) integer_zerop)
  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
       || VECTOR_INTEGER_TYPE_P (TREE_TYPE (@0)))
   (cmp2 (abs @0) (abs @1)))))

(I assume that abs simplifies to the identity for unsigned)
But if we are going to use A/B anyway, computing two ABS may waste time, so
maybe restrict it to TYPE_UNSIGNED (TREE_TYPE (@0)) || single_use (@2) (where
@2 is the trunc_div) or something like that.


  parent reply	other threads:[~2015-06-19  7:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-18 18:29 [Bug c++/66590] New: " brutus at free dot fr
2015-06-19  0:24 ` [Bug c++/66590] " pinskia at gcc dot gnu.org
2015-06-19  7:47 ` manu at gcc dot gnu.org [this message]
2015-09-23 18:06 ` miyuki at gcc dot gnu.org
2021-08-10  0:53 ` pinskia at gcc dot gnu.org
2021-08-10  1:00 ` pinskia at gcc dot gnu.org
2021-08-10  1:04 ` pinskia at gcc dot gnu.org
2021-08-10  1:31 ` pinskia at gcc dot gnu.org
2021-08-25 21:28 ` cvs-commit at gcc dot gnu.org
2021-08-25 21:29 ` pinskia at gcc dot gnu.org

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=bug-66590-4-LALLIsmV5n@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).