https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92894
--- Comment #4 from Patrick Palka ---
Created attachment 48428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48428=edit
avoid defining _IMove::operator() with a deduced return type
With this patch both of the above testcases successfully
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92894
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93811
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-05-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899
--- Comment #3 from Andrew Pinski ---
If I used (int)(0x8000) instead, I get the optimization which means GCC is
correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Piotr Kubaj changed:
What|Removed |Added
Version|9.3.0 |10.0
--- Comment #25 from Piotr Kubaj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899
--- Comment #1 from Andrew Pinski ---
The problem is only with INT_MIN.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
Alan Modra changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Alan Modra :
https://gcc.gnu.org/g:0c3519218fb11bdde5356aec9fcac133b4988698
commit r9-8556-g0c3519218fb11bdde5356aec9fcac133b4988698
Author: Alan Modra
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94073
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-05-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899
Bug ID: 94899
Summary: Failure to optimize out add before compare
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94898
Bug ID: 94898
Summary: Failure to optimize compare plus sub of same operands
into compare
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
On Wed, Apr 29, 2020 at 05:10:44PM -0400, Jason Merrill via Gcc-patches wrote:
> On 4/28/20 11:55 PM, Marek Polacek wrote:
> > Whew, this took a while. We fail to parse "p->template A::a()"
> > (where p is of type A *) because since r249752 we treat the RHS of the ->
> > as dependent and avoid a
On 4/30/20 2:02 PM, Richard Sandiford wrote:
> Jeff Law writes:
>> On Thu, 2020-04-30 at 08:54 +0100, Richard Sandiford wrote:
>>> I guess at this point it needs a review from someone else though.
>>> Jeff, WDYT? Attached again below, this time without the shonky mime type.
>> It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
--- Comment #10 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:ff1e6276dd71fde59fde679557b5db1efca9f19c
commit r11-6-gff1e6276dd71fde59fde679557b5db1efca9f19c
Author: Peter Bergner
Date: Thu
Hey all-apologies for the long delay. Haven't had time until recently to look
into this further.
>>> The zero extract now matching against other modes would generate a
>>> test + branch rather than the combined instruction which led to the
>>> code size regression. I've updated the patch so that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890
--- Comment #3 from Patrick Palka ---
Whoops, the above minimal testcase doesn't actually illustrate any bug, we just
correctly accept it in c++2a mode ever since r10-6519. Hmm...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890
--- Comment #2 from Patrick Palka ---
Minimal testcase:
template
void foo();
struct t { int a; };
void bar()
{
foo();
}
On Thu, 2020-04-30 at 23:38 +0200, Jakub Jelinek wrote:
> On Thu, Apr 30, 2020 at 05:31:22PM -0400, David Malcolm wrote:
> > On Thu, 2020-04-30 at 23:26 +0200, Jakub Jelinek wrote:
> > > On Thu, Apr 30, 2020 at 05:18:13PM -0400, David Malcolm wrote:
> > > > Thanks for working on this; sorry for
Snapshot gcc-8-20200430 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20200430/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94869
Leo Carreon changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #8 from Leo Carreon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890
Patrick Palka changed:
What|Removed |Added
Component|libstdc++ |c++
--- Comment #1 from Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94869
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94869
--- Comment #6 from Leo Carreon ---
Thanks for your comments. I have realized what the issue is. It is to do with
local_time and local_days being defined in namespace date and std::chrono.
On Thu, Apr 30, 2020 at 05:31:22PM -0400, David Malcolm wrote:
> On Thu, 2020-04-30 at 23:26 +0200, Jakub Jelinek wrote:
> > On Thu, Apr 30, 2020 at 05:18:13PM -0400, David Malcolm wrote:
> > > Thanks for working on this; sorry for getting these wrong.
> > >
> > > Is is possible to build gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93802
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Ever
On Thu, 2020-04-30 at 23:26 +0200, Jakub Jelinek wrote:
> On Thu, Apr 30, 2020 at 05:18:13PM -0400, David Malcolm wrote:
> > Thanks for working on this; sorry for getting these wrong.
> >
> > Is is possible to build gfortran without C and C++? If so, then if
> > I'm
>
> It is possible without
On Thu, Apr 30, 2020 at 05:18:13PM -0400, David Malcolm wrote:
> Thanks for working on this; sorry for getting these wrong.
>
> Is is possible to build gfortran without C and C++? If so, then if I'm
It is possible without C++, but not without C.
E.g. --enable-languages=fortran,go will actually
The first release candidate for GCC 10.1 is available from
https://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430/
ftp://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430
and shortly its mirrors. It has been generated from git revision
r10-8080-g591d857164c37cd0bb96da2a293148e01f280e0f.
I
On Thu, 2020-04-30 at 15:02 +0200, Jakub Jelinek wrote:
> Hi!
>
> (Sorry to David, apparently I've posted it only privately, not to
> gcc-patches, so reposting).
>
> While testing the --with-documentation-root-url= changes, I run into
> [Wreturn-type] URL pointing to gfortran documentation where
Hi!
As Will says, the subject is much too long. 50 chars max is the ideal.
"target supports" isn't clear; maybe
rs6000: Add effective targets powerpc_{pcrel,prefixed_addr}
or something like it (prefix, colon, capital, no dot).
On Mon, Apr 27, 2020 at 03:46:06PM -0400, Michael
On Thu, Apr 30, 2020 at 05:37:26PM -0300, Adhemerval Zanella via Gcc wrote:
> Hi all, I would like to check if someone could help me figure out
> an issue I am chasing on a libgomp patch intended to partially
> address the issue described at BZ#79784.
>
> I have identified that one of the
Nathan Sidwell wrote:
On 4/30/20 9:24 AM, Iain Sandoe wrote:
The testcase ICEs because the range-based for generates three
artificial variables that need to be allocated to the coroutine
frame but, when walking the BIND_EXR that contains these, the
DECL_INITIAL for one of them refers to an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94897
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94897
Bug ID: 94897
Summary: range-for produces a variable initialiser with use of
a forward decl.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91133
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93366
--- Comment #5 from anlauf at gcc dot gnu.org ---
Created attachment 48427
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48427=edit
Update and extension of Steve's patch
I've updated Steve's patch to reflect current master before creating
Hi all, I would like to check if someone could help me figure out
an issue I am chasing on a libgomp patch intended to partially
address the issue described at BZ#79784.
I have identified that one of the bottlenecks is the global barrier
used on both thread pool and team which causes a lof of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
This looks much nicer for me, because the font for the part is
much smaller than the other text.
Committed to wwwdocs.
commit 3f573b5fe7df858a27b0275edc5fd4386804ae83
Author: Jonathan Wakely
Date: Thu Apr 30 20:54:09 2020 +0100
Improve ugly formatting for std::atomic
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |10.0
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc-sun-solaris2.11
Between 20200429 (27594524d8a93cddb197ad8c9d4075c5870f1473) and 20200430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94889
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94842
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94842
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bf9155914f0c2dac62c6abf1e45abb52a5a56e5b
commit r11-5-gbf9155914f0c2dac62c6abf1e45abb52a5a56e5b
Author: Jakub Jelinek
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94892
--- Comment #2 from Gabriel Ravier ---
In that case, then, GCC is generating sub-optimal code for `(x >> 31) + 1`
alone since it optimises that to the same thing as LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:591d857164c37cd0bb96da2a293148e01f280e0f
commit r10-8080-g591d857164c37cd0bb96da2a293148e01f280e0f
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90749
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On Thu, 2020-04-30 at 20:02 +0100, Richard Sandiford wrote:
> Jeff Law writes:
> > On Thu, 2020-04-30 at 08:54 +0100, Richard Sandiford wrote:
> > > Peter Bergner writes:
> > > > On 4/29/20 4:15 PM, Peter Bergner wrote:
> > > > > On 4/29/20 3:28 PM, Richard Sandiford wrote:
> > > > > > (Sorry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94878
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94895
Bug ID: 94895
Summary: ICE in expand_block_tm, at trans-mem.c:2643
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, trans-mem
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94877
--- Comment #2 from Andrew Pinski ---
Related to PR 23666.
Jeff Law writes:
> On Thu, 2020-04-30 at 08:54 +0100, Richard Sandiford wrote:
>> Peter Bergner writes:
>> > On 4/29/20 4:15 PM, Peter Bergner wrote:
>> > > On 4/29/20 3:28 PM, Richard Sandiford wrote:
>> > > > (Sorry for going ahead and writing an alternative patch, since if we do
>> > > > go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:66ec22b0d3feb96049283abe5c6c9a05ecef8b86
commit r11-4-g66ec22b0d3feb96049283abe5c6c9a05ecef8b86
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91529
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On Thu, 2020-04-30 at 08:54 +0100, Richard Sandiford wrote:
> Peter Bergner writes:
> > On 4/29/20 4:15 PM, Peter Bergner wrote:
> > > On 4/29/20 3:28 PM, Richard Sandiford wrote:
> > > > (Sorry for going ahead and writing an alternative patch, since if we do
> > > > go for this, I guess the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94867
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94888
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94892
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #1 from Andrew
On Thu, 30 Apr 2020, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> If there are _Atomic side-effects in the parameter declarations
> of non-nested function, when they are parsed, current_function_decl is
> NULL, the create_artificial_label created labels during build_atomic* are
> then adjusted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94888
--- Comment #5 from Jonathan Wakely ---
Further reduced:
struct FunctionBridger
{
template
FunctionBridger(T& func_)
{
T t(func_);
}
};
struct Function : FunctionBridger
{
template
Function( Ty&& func) :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894
Bug ID: 94894
Summary: Premature instantiation of conversion function
template during overload resolution
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Richard Sandiford writes:
> Peter Bergner writes:
>> On 4/29/20 4:15 PM, Peter Bergner wrote:
>>> On 4/29/20 3:28 PM, Richard Sandiford wrote:
(Sorry for going ahead and writing an alternative patch, since if we do
go for this, I guess the earlier misdirections will have wasted two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94888
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #39 from Jürgen Reuter ---
I submitted a corrected 'final' reproducer, sorry about that. Was too tired
yesterday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #38 from Jürgen Reuter ---
Created attachment 48426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48426=edit
Correct 'final' final reproducer
Indeed,
rt_data_t should have an additional
component
type(rt_data_t), pointer ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94893
Bug ID: 94893
Summary: Sign function not getting optimized to simple compare
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94892
Bug ID: 94892
Summary: (x >> 31) + 1 not getting narrowed to compare
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94395
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-04-30
Ever confirmed|0
Status
==
The trunk has branched for the GCC 10 release and is now open
again for general development, stage 1. Please consider not
disrupting it too much during the RC phase of GCC 10 so it
is possible to test important fixes for 10.1 on it.
Quality Data
Priority #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94687
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-04-30
Status
==
We have reached zero P1 regressions today and releases/gcc-10 branch has
been created; GCC 10.1-rc1 will be built and announced later tonight
or tomorrow.
The branch is now frozen for blocking regressions and documentation
fixes only, all changes to the branch require a RM approval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #37 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #36)
> Hm, I hope I didn't change the flavor of the bug, but you can cross-check
> with the very first reproducer which contains our code more or less
> unchanged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #36 from Jürgen Reuter ---
Hm, I hope I didn't change the flavor of the bug, but you can cross-check with
the very first reproducer which contains our code more or less unchanged
(except for the build setup with autotools etc.).
On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel wrote:
>
> On 30.04.20 08:25, Richard Biener via Gcc-patches wrote:
> > On Wed, Apr 29, 2020 at 5:56 PM Jeff Law wrote:
> >>
> >> On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote:
> >>>
> >>> Btw, does s390 have different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #35 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #34)
> Created attachment 48411 [details]
> Final reproducer, less than 300 lines ;)
>
> This one should be sufficient. No further files or input is necessary, it
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94852
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891
Bug ID: 94891
Summary: aarch64: there is no way to strip PAC from a return
address in c code
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94856
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763
vvinayag at arm dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881
Martin Sebor changed:
What|Removed |Added
Blocks||88443
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655
Martin Sebor changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94869
--- Comment #5 from Jonathan Wakely ---
If I change your code to use date::local_time (as suggested by GCC 9) then it
compiles as expected with any recent version of GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 94881, which changed state.
Bug 94881 Summary: [10/11 Regression] incorrect Wstringop-overflow warning with
thread sanitizer since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94878
Gabriel Ravier changed:
What|Removed |Added
Target|x86_64-*-* i?86-*-* |
--- Comment #3 from Gabriel Ravier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94856
--- Comment #10 from CVS Commits ---
The releases/gcc-10 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:e72cfef362a98528bf3d199f127916c3dbef7727
commit r10-8079-ge72cfef362a98528bf3d199f127916c3dbef7727
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94869
--- Comment #4 from Jonathan Wakely ---
std::local_time is new for GCC 10, so I would not expect the code to compile
with odler versions. I would also not expect std::chrono::local_time to work
with date::parse because date::parse probably only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94869
Jonathan Wakely changed:
What|Removed |Added
Summary|[10/11 Regression] Template |[10 Regression] Template
Here we have (conceptually *) something like
struct B { };
struct D : B { };
D(0); // invalid
and in C++20 the ()-initialization has created a { 0 } constructor that
it tries to initialize an object of type D with. We should reject
initializing an object of type B from 0, but we wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94856
--- Comment #9 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:b31ede6e376302047830691fe6249be3ade0a2c0
commit r11-1-gb31ede6e376302047830691fe6249be3ade0a2c0
Author: Martin Jambor
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93822
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94448
--- Comment #2 from Diane Meirowitz ---
OK, I submitted this issue:
https://github.com/google/sanitizers/issues/1236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94888
--- Comment #3 from zhangzhanli ---
So this is output from latest version of g++ ?
With Apple Clang, there is no such problem (recursive and segmentation fault).
MacOS Output:
jaly@Jalys-MBP gcccompared %
On Thu, Apr 30, 2020 at 05:14:34PM +0200, Martin Liška wrote:
> On 4/30/20 3:45 PM, Jakub Jelinek wrote:
> > If this is what is really created, then for the new file, missing * space,
> > gcc/testsuite/ that shouldn't be there and missing PR c++/94546 line above
> > it.
>
> I've just fixed all
On 4/30/20 10:35 AM, Nathan Sidwell wrote:
On 4/30/20 10:18 AM, Jason Merrill wrote:
On 4/29/20 2:50 PM, Nathan Sidwell wrote:
Jason,
this is the patch you suggested, as I understood it. I kept
finish_nested_require's saving of the (converted)
current_template_parms, becase of the comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827
Nathan Sidwell changed:
What|Removed |Added
Summary|[10 Regression] crash on|crash on requires clause in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94885
--- Comment #3 from Marek Polacek ---
process_init_constructor_record:
1743 if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field))
1744 && !TREE_SIDE_EFFECTS (next))
1745 /* Don't add trivial initialization of an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89510
Jonathan Wakely changed:
What|Removed |Added
Summary|[9/10 Regression] |[9 Regression]
1 - 100 of 272 matches
Mail list logo