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
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].
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
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
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
Domani Hannes changed:
What|Removed |Added
CC||ssbssa at yahoo dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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
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
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
22 matches
Mail list logo
