Qing Zhao writes:
> (gdb) where
> #0 0x00ddbcb3 in df_chain_create (src=0x631006480f08,
> dst=0x63100f306288) at ../../gcc-8.2.1-20180905/gcc/df-problems.c:2267
> #1 0x001a in df_chain_create_bb_process_use (
> local_rd=0x7ffc109bfaf0, use=0x63100f306288,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93112
Bug ID: 93112
Summary: Incorrect rounding for float to uint64 on x86 (32bit)
with -fexcess-precision=standard
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93109
--- Comment #2 from Andrew Pinski ---
(In reply to Eric Gallager from comment #1)
> I understand why it happens though; to get from #undefine to #define only
> requires 2 letters to be removed, but to get from #undefine to #undef, 3
> letters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93098
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Wed Jan 1 00:20:39 2020
New Revision: 279809
URL: https://gcc.gnu.org/viewcvs?rev=279809=gcc=rev
Log:
PR tree-optimization/93098
* match.pd (popcount): For shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #17 from Jonathan Wakely ---
Done:
https://gitlab.com/esr/gcc-conversion/merge_requests/47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #16 from Jonathan Wakely ---
It had nothing to do with Git. It's just a python script that says commit
r279763 is related to PR x not PR y.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93111
Bug ID: 93111
Summary: FAIL: gfortran.fortran-torture/compile/pr32663.f, -O3
-g (internal compiler error)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
On Tue, Dec 31, 2019 at 05:47:54PM +0100, Richard Biener wrote:
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Ok.
Thanks.
> >One thing I haven't done anything about yet is that there is
> >FAIL: gcc.dg/tree-ssa/popcount4ll.c scan-tree-dump-times optimized
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93109
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
six
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191231 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93035
--- Comment #1 from Simon Hardy-Francis ---
Also, for names which do demangle then there are wide spread differences [1] if
the same name is demangled using llvm-cxxfilt. I tried out demangling over 100k
mangled names with both tools here [1].
On Tue, Dec 31, 2019 at 01:42:55PM +, Joseph Myers wrote:
> As the remaining changes being made to the reposurgeon conversion are of
> the form "tidy things up where reposurgeon is already making a reasonable
> conservative choice but minor improvements are still possible", I think
> it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
--- Comment #5 from joseph at codesourcery dot com ---
On Tue, 31 Dec 2019, ssbssa at yahoo dot de wrote:
> Is there also a scenario where it would make sense to have multiple format
> attributes for the same format string?
That seems less
On December 31, 2019 12:00:56 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>This patch fixes various issues in the popcount{64,32}c matcher.
>
>The first issue is that it blindly uses tree_to_uhwi on all the
>INTEGER_CST
>operands. That is fine for those where we know their type, after the
>prec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093
--- Comment #3 from JeanHeyd Meneide ---
I guess we just throw out a handful of those test cases, then. It's not like
the Standard is really impactful here, since most of Source Location's
specification is "should...", which is encouragement and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93087
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093
--- Comment #2 from Jakub Jelinek ---
What this boils down to is e.g. whether
consteval int foo (int i) { if (i) throw 1; return 0; }
void bar (int x = foo (0));
void baz (int x = foo (1));
void qux () { bar (0); bar (); baz (0); }
needs to be
This code:
/* Make sure we don't accidentally use the old condition. */
cond_expr = NULL_TREE;
was misplaced, since it triggered even when we needed to force the
original unmodified cond_expr into a mask temporary and then invert it.
Tested on aarch64-linux-gnu and applied as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
--- Comment #4 from Domani Hannes ---
(In reply to jos...@codesourcery.com from comment #3)
> On Tue, 31 Dec 2019, ssbssa at yahoo dot de wrote:
>
> > But does it make sense to do a format check multiple times for one function?
>
> Yes. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 31 Dec 2019, ssbssa at yahoo dot de wrote:
> But does it make sense to do a format check multiple times for one function?
Yes. You could have a function with one format string for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
On 31/12/2019 13:42, Joseph Myers wrote:
> On Mon, 16 Dec 2019, Jeff Law wrote:
>
>>> Joseph Myers has made his choice. He has said repeatedly that he
>>> wants to follow through with the reposurgeon conversion, and he's
>>> putting his effort behind that by writing tests and even contributing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
Domani Hannes changed:
What|Removed |Added
CC||ssbssa at yahoo dot de
--- Comment #2
On Mon, 16 Dec 2019, Jeff Law wrote:
> > Joseph Myers has made his choice. He has said repeatedly that he
> > wants to follow through with the reposurgeon conversion, and he's
> > putting his effort behind that by writing tests and even contributing
> > code to reposurgeon.
> >
> > We'll get
On Mon, Dec 30, 2019 at 06:23:16PM -0600, Segher Boessenkool wrote:
> > To me, that indicates that using a conversion tool that is conservative in
> > its heuristics, and then selectively applying improvements to the extent
> > they can be done safely with manual review in a reasonable time, is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
Hi!
My PR90677 fix actually made building older GCCs with newer ones worse.
The problem is that identifier_global_value used earlier returned either the
type decl on success or NULL_TREE on failure and the caller in that case
just defers handling it until later, and that is also what the C
Hi!
This patch fixes various issues in the popcount{64,32}c matcher.
The first issue is that it blindly uses tree_to_uhwi on all the INTEGER_CST
operands. That is fine for those where we know their type, after the
prec <= 64 && TYPE_UNSIGNED (type)
verification, but shift counts can have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93065
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 31 10:34:34 2019
New Revision: 279803
URL: https://gcc.gnu.org/viewcvs?rev=279803=gcc=rev
Log:
PR libgomp/93065
* oacc-init.c (goacc_runtime_deinitialize): New
[BUG: 93065] libgomp: destructor missing to delete goacc_cleanup_key
libgomp constructor creates goacc_cleanup_key on dlopen but doesn't
delete key on dlclose.
dlopen and dlclose of libgomp.so exhausts pthread keys, which results in
pthread_key_create failure.
pthread_key_delete needs to be
Hi Jerry,
OK for trunk?
Looks good. I also think that your approach that DEC stuff should
be checked later is good. If it passes the testsuite, that's good
enough for a commit.
Thanks for the patch!
Regards
Thomas
On Mon, Dec 30, 2019 at 07:24:08PM +0530, Ayush Mittal wrote:
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2019-12-30 Ayush Mittal
> +
> + * libgomp: Add destructor to delete runtime env keys
This line should have been instead something like:
* oacc-init.c
The first level is ordinary clone, corresponding to a non-self caller,
and the param_ipa_cp_max_recursive_depth-1 is for recursive cloning.
Then it's ok that the least value is 1, with which disabling does happen.
Feng
From: luoxhu
Sent: Tuesday,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93109
Bug ID: 93109
Summary: #undefine suggests #define but not #undef
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
34 matches
Mail list logo
