https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91156
--- Comment #3 from emsr at gcc dot gnu.org ---
N.B. This 'bug' and the patches apply both to the 'regular' Laguerre polynomial
laguerre(n,x) and to the associated Laguerre polynomial assoc_laguerre(n,m,x).
Note that this gets rid of a throw or t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
--- Comment #7 from Cassio Neri ---
(In reply to Jakub Jelinek from comment #4)
Got it! Thank you, Mark and Jonathan. Please, feel free to close the ticket.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233
--- Comment #6 from Jerry DeLisle ---
Author: jvdelisle
Date: Sun Jul 14 22:52:58 2019
New Revision: 273484
URL: https://gcc.gnu.org/viewcvs?rev=273484&root=gcc&view=rev
Log:
2019-07-14 Jerry DeLisle
PR fortran/87233
* expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233
--- Comment #7 from Jerry DeLisle ---
Fixed on trunk. I am thinking backport this to enable gfortran 9 to not reject
valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90343
Arseny Solokha changed:
What|Removed |Added
Known to fail|10.0|
--- Comment #2 from Arseny Solokha --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91125
--- Comment #2 from Martin Liška ---
Author: marxin
Date: Mon Jul 15 04:11:43 2019
New Revision: 273489
URL: https://gcc.gnu.org/viewcvs?rev=273489&root=gcc&view=rev
Log:
Deprecate -frepo on gcc-9 branch (PR c++/91125).
2019-07-15 Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497
--- Comment #10 from Kewen Lin ---
Author: linkw
Date: Mon Jul 15 05:12:05 2019
New Revision: 273490
URL: https://gcc.gnu.org/viewcvs?rev=273490&root=gcc&view=rev
Log:
gcc/ChangeLog
2019-07-15 Kewen Lin
PR tree-optimization/88497
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161
Bug ID: 91161
Summary: [10 Regression] ICE in begin_move_insn, at
sched-ebb.c:175
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695
--- Comment #13 from OC ---
Hi,
This bug is open for almost 9 months. I loaded the latest GCC revision and it
is not solved. Can anyone be so kind to give an estimation of repair time or
any work around?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91162
Bug ID: 91162
Summary: [9/10 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
useless_type_conversion_p, at gimple-expr.c:86 (error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095
--- Comment #2 from Tom Honermann ---
I confirmed that Jeff's patch, applied to gcc 9.1.0, suffices to address both
Hana's test case and the code in the "Emulate C++17 u8 literals" section of
P1423R2
(http://www.open-std.org/jtc1/sc22/wg21/docs/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695
--- Comment #14 from Andreas Schwab ---
Since you know how to reproduce the issue, you can help by providing the
requested information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Sun Jul 14 08:24:38 2019
New Revision: 273475
URL: https://gcc.gnu.org/viewcvs?rev=273475&root=gcc&view=rev
Log:
rs6000: Shut up -Wformat-diag a little more
PR target/9114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #21 from Jakub Jelinek ---
Author: jakub
Date: Sun Jul 14 08:27:12 2019
New Revision: 273476
URL: https://gcc.gnu.org/viewcvs?rev=273476&root=gcc&view=rev
Log:
Backported from mainline
2019-07-04 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884
--- Comment #11 from Jakub Jelinek ---
Author: jakub
Date: Sun Jul 14 08:28:06 2019
New Revision: 273477
URL: https://gcc.gnu.org/viewcvs?rev=273477&root=gcc&view=rev
Log:
Backported from mainline
2019-07-04 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91149
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Sun Jul 14 08:29:38 2019
New Revision: 273478
URL: https://gcc.gnu.org/viewcvs?rev=273478&root=gcc&view=rev
Log:
Backported from mainline
2019-07-13 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #22 from Mike Hommey ---
For the record, this also affects ppc64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
--- Comment #19 from Allan Jensen ---
(In reply to felix from comment #18)
> So even if this feature is adopted as-is, it will necessitate some changes
> in the documentation. And while I can sympathise with claims that this
> behaviour is surpri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
Bug ID: 91163
Summary: ARM lto optimalization fail in big-endian case (error:
could not unlink output file)
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87981
--- Comment #2 from Arseny Solokha ---
Current trunk doesn't ICE on this particular testcase anymore. Maybe it
actually makes sense to close it as RESOLVED INVALID.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91164
Bug ID: 91164
Summary: [10 Regression] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 114 should be
112, not 16)
Product: gcc
Version: 10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
--- Comment #2 from jdobry at centrum dot cz ---
No, it isn't duplicate to PR90369.
1) I try to apply PR90369 patch without any difference.
2) This problem is independent to -save-temps parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
--- Comment #3 from jdobry at centrum dot cz ---
Here is update for big-endian multilib compilation
https://pastebin.com/mzm12Q8m
(fix typo in MULTILIB_MATCHES line)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91149
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
--- Comment #3 from Cassio Neri ---
Forget my use case and comments on dead code elimination. That was a
digression. (My bad.) In general, I don't expect `if` and `if constexpr` to
behave the same but I do in this particular case. (I might be wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165
Bug ID: 91165
Summary: error: location references block not in block tree
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
--- Comment #5 from Jakub Jelinek ---
Something that might clarify it:
constexpr int foo (int n)
{
if constexpr (n)
return 1;
else
return 0;
}
constexpr int x = foo (1);
constexpr int y = foo (0);
This is invalid and rejected not jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
--- Comment #6 from Marc Glisse ---
A related common misconception is trying to write
if constexpr (std::is_constant_evaluated())
except that this one is always true instead of always false.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91156
--- Comment #2 from emsr at gcc dot gnu.org ---
Created attachment 46598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46598&action=edit
Obvious patch...
2019-07-14 Edward Smith-Rowland <3dw...@verizon.net>
* libstdc++-v3/includ
33 matches
Mail list logo
