* [Bug c++/63431] implicit conversion changes value but no warning ?
2014-10-01 14:46 [Bug c++/63431] New: implicit conversion changes value but no warning ? dcb314 at hotmail dot com
2014-10-01 15:01 ` [Bug c++/63431] " redi at gcc dot gnu.org
2014-10-01 15:09 ` manu at gcc dot gnu.org
@ 2014-10-01 16:08 ` dcb314 at hotmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: dcb314 at hotmail dot com @ 2014-10-01 16:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63431
--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> -Wconversion
Thanks for that. I tried it out and I got far more
warnings than I could triage.
While all the new warnings that I checked seemed technically
accurate, very few seem useful. E.g. for source code
float end = 9434.20 + 42994.82;
I got
aug4a.cc:7:23: warning: conversion to ‘float’ alters ‘double’ constant value
[-Wfloat-conversion]
float end = 9434.20 + 42994.82;
^
Floats and doubles are only ever approximate, so I used -Wno-float-conversion.
That didn't help much.
I'd be happier with a much smaller warning that only
ever warned for floats and double literals being put into
integral types, as per clang.
>From gcc-bugs-return-463044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 01 16:19:59 2014
Return-Path: <gcc-bugs-return-463044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9648 invoked by alias); 1 Oct 2014 16:19:59 -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 9622 invoked by uid 48); 1 Oct 2014 16:19:56 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63431] implicit conversion changes value but no warning ?
Date: Wed, 01 Oct 2014 16:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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-63431-4-Ok6hIJTD7K@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63431-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63431-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-10/txt/msg00065.txt.bz2
Content-length: 516
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63431
--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to David Binderman from comment #3)
> I'd be happier with a much smaller warning that only
> ever warned for floats and double literals being put into
> integral types, as per clang.
See the patch attached in PR55077. As always, someone has to spend their time
to submit it and get it reviewed. We need (many) more contributors to gcc,
specially the front-ends.
>From gcc-bugs-return-463043-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 01 16:19:38 2014
Return-Path: <gcc-bugs-return-463043-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8962 invoked by alias); 1 Oct 2014 16:19:37 -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 8944 invoked by uid 48); 1 Oct 2014 16:19:33 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63432] New: [5 Regression] profiledbootstrap failure with bootstrap-lto
Date: Wed, 01 Oct 2014 16:19: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools 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-63432-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-10/txt/msg00064.txt.bz2
Content-length: 2773
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
Bug ID: 63432
Summary: [5 Regression] profiledbootstrap failure with
bootstrap-lto
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
On Linux/x86-64, r215740 failed to profiledbootstrap when
configured with --with-build-config=bootstrap-lto:
/export/project/git/gcc-regression/gcc/gcc/genhooks.c: In function
‘emit_documentation’:
/export/project/git/gcc-regression/gcc/gcc/genhooks.c:117:1: internal compiler
error: in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
emit_documentation (const char *in_fname)
^
0x107902e freqs_to_counts_path
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:981
0x107902e ssa_fix_duplicate_block_edges(redirection_data*, ssa_local_info_t*)
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:1061
0x10791ea ssa_create_duplicates(redirection_data**, ssa_local_info_t*)
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:1275
0x1080149 void hash_table<redirection_data, xcallocator,
false>::traverse_noresize<ssa_local_info_t*,
&(ssa_create_duplicates(redirection_data**,
ssa_local_info_t*))>(ssa_local_info_t*)
/export/project/git/gcc-regression/gcc/gcc/hash-table.h:942
0x1080149 void hash_table<redirection_data, xcallocator,
false>::traverse<ssa_local_info_t*, &(ssa_create_duplicates(redirection_data**,
ssa_local_info_t*))>(ssa_local_info_t*)
/export/project/git/gcc-regression/gcc/gcc/hash-table.h:964
0x10794b3 thread_block_1
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:1515
0x107d556 thread_block
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:1559
0x107d556 thread_through_all_blocks(bool)
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:2279
0x114eecb finalize_jump_threads
/export/project/git/gcc-regression/gcc/gcc/tree-vrp.c:9856
0x114eecb execute_vrp
/export/project/git/gcc-regression/gcc/gcc/tree-vrp.c:10010
0x114eecb execute
/export/project/git/gcc-regression/gcc/gcc/tree-vrp.c:10073
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [/tmp/ccyuxuEg.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/bin/ld: lto-wrapper failed
r215738 is OK. r215739 may be the cause.
>From gcc-bugs-return-463045-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 01 16:22:07 2014
Return-Path: <gcc-bugs-return-463045-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14123 invoked by alias); 1 Oct 2014 16:22:07 -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 13626 invoked by uid 48); 1 Oct 2014 16:22:02 -0000
From: "tejohnson at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/63422] [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
Date: Wed, 01 Oct 2014 16:22: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tejohnson at google dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63422-4-kIKD4qugwo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63422-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63422-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-10/txt/msg00066.txt.bz2
Content-length: 1322
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc422
--- Comment #6 from Teresa Johnson <tejohnson at google dot com> ---
My new code is exposing an upstream profile count insanity that is being
introduced by the copyrename2 phase.
The new freqs_to_counts_path routine is invoked only when we don't have profile
info, and in this case main() is in mozilla-xremote-client.ii which does not
have a gcda file. So the profile status for the fn != PROFILE_READ.
Before copyrename2, all the counts in main() are 0, and everything looks fine.
But coming out of copyrename2, some of the blocks and edges have a count == 1.
So my assert in freqs_to_counts_path that expects the edges to all have 0
weight is firing.
The two approaches I could take are to either skip freqs_to_counts if there are
actually non-zero counts or simply remove the assert with a comment about
upstream insanities. I am probably going to do the latter, because the former
will result in really insane frequencies coming out of jump threading (the
updates are based on counts, which in this case are bogus coming in).
It would be good to figure out why copyrename2 is introducing non-zero counts,
but presumably there is some kind of profile update that has an off-by-one
error? I don't see any count manipulation within tree-ssa-copyrename.c itself.
^ permalink raw reply [flat|nested] 4+ messages in thread