public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/60342] New: -Wsign-conversion ignores explicit conversion
@ 2014-02-26 8:54 woodroof at gmail dot com
0 siblings, 0 replies; only message in thread
From: woodroof at gmail dot com @ 2014-02-26 8:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60342
Bug ID: 60342
Summary: -Wsign-conversion ignores explicit conversion
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: woodroof at gmail dot com
Simple example:
#include <cstddef>
#include <limits>
int main()
{
int int_value;
if (std::numeric_limits<size_t>::max() -
static_cast<size_t>(int_value))
{
}
}
Result:
1.cpp: In function ‘int main()’:
1.cpp:7:72: warning: conversion to ‘long unsigned int’ from ‘int’ may change
the sign of the result [-Wsign-conversion]
if (std::numeric_limits<size_t>::max() - static_cast<size_t>(int_value))
^
If I change numeric_limits::max to any size_t variable, warning will not be
generated. There is no warning also if I used usigned instead of size_t.
Possible the same problem as in bug 49626, but there is no conversion to a
wider type.
>From gcc-bugs-return-444832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 26 09:18:43 2014
Return-Path: <gcc-bugs-return-444832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17092 invoked by alias); 26 Feb 2014 09:18:42 -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 17074 invoked by uid 48); 26 Feb 2014 09:18:38 -0000
From: "izamyatin at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/60343] New: r208155 breaks bootstrap
Date: Wed, 26 Feb 2014 09:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: izamyatin at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-60343-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: 2014-02/txt/msg02589.txt.bz2
Content-length: 874
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60343
Bug ID: 60343
Summary: r208155 breaks bootstrap
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: izamyatin at gmail dot com
Message:
../../gcc/lra-assigns.c: In function ‘int spill_for(int, bitmap)’:
../../gcc/lra-assigns.c:901:4: error: comparison between signed and unsigned
integer expressions [-Werror=sign-compare]
<= LRA_MAX_CONSIDERED_RELOAD_PSEUDOS)
Could be seen on x86_64, say, for
../configure --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto,objc
>From gcc-bugs-return-444833-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 26 09:33:05 2014
Return-Path: <gcc-bugs-return-444833-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24837 invoked by alias); 26 Feb 2014 09:33:04 -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 24709 invoked by uid 48); 26 Feb 2014 09:32:59 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
Date: Wed, 26 Feb 2014 09:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.3.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-36043-4-kJ7tD6i413@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-36043-4@http.gcc.gnu.org/bugzilla/>
References: <bug-36043-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: 2014-02/txt/msg02590.txt.bz2
Content-length: 3163
http://gcc.gnu.org/bugzilla/show_bug.cgi?id6043
--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #8)
> FWIW, I think the error is in the caller of move_block_to_reg.
> move_block_to_reg can make use of a load_multiple instruction, which really
> loads full regs. I.e. it would be unreasonable to require changes in
> move_block_to_reg to handle non-power-of-2 sizes. Hence the caller
> (load_register_parameters) needs to handle this. I'm not sure if the
> n_aligned_regs thingy could be misused for this, or if one simply should
> opencode the special case of the last register being partial.
That would be sth like
Index: gcc/calls.c
==================================================================--- gcc/calls.c (revision 208124)
+++ gcc/calls.c (working copy)
@@ -1984,7 +1984,26 @@ load_register_parameters (struct arg_dat
emit_move_insn (ri, x);
}
else
- move_block_to_reg (REGNO (reg), mem, nregs, args[i].mode);
+ {
+ if (size % UNITS_PER_WORD == 0
+ || MEM_ALIGN (mem) % BITS_PER_WORD == 0)
+ move_block_to_reg (REGNO (reg), mem, nregs, args[i].mode);
+ else
+ {
+ if (nregs > 1)
+ move_block_to_reg (REGNO (reg), mem,
+ nregs - 1, args[i].mode);
+ rtx dest = gen_rtx_REG (word_mode,
+ REGNO (reg) + nregs - 1);
+ rtx src = operand_subword_force (mem,
+ nregs - 1,
args[i].mode);
+ rtx tem = extract_bit_field (src, size * BITS_PER_UNIT,
+ 0, 1, dest, word_mode,
+ word_mode);
+ if (tem != dest)
+ convert_move (dest, tem, 1);
+ }
+ }
}
/* When a parameter is a block, and perhaps in other cases, it is
it's similar to what store_unaligned_arguments_into_pseudos would end up
doing but only for the last register (so it's probably easier to dispatch
to that and handle !STRICT_ALIGNMENT targets there).
Anyway, the generated code is of course "horrible".
foo:
.LFB0:
.cfi_startproc
movq %rdi, %rcx
movzwl (%rdi), %edx
movzwl 2(%rdi), %edi
salq $16, %rdi
movq %rdi, %rax
movzwl 4(%rcx), %edi
orq %rdx, %rax
salq $32, %rdi
orq %rax, %rdi
jmp print_colour
for some reason extract_bit_field doesn't consider using a 4-byte load
for the first part. With AVX one could also use a masked load (and thus
implement the extv/insv pattern family? not sure if it is valid to
reject non-byte boundary variants). But if we end up using
extract_bit_field more and more it's worth optimizing it further to
avoid the above mess... (we end up using extract_split_bit_field).
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2014-02-26 8:54 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-26 8:54 [Bug c++/60342] New: -Wsign-conversion ignores explicit conversion woodroof at gmail dot com
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).