https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312
--- Comment #6 from Brooks Moses ---
(In reply to Eric Gallager from comment #5)
> Is that patch still relevant?
The relevant part of the libssp configure.ac hasn't changed much (if at all)
since I posted the patch, so I think it's still worth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #25 from Matthijs van Duin ---
I wasn't referring to the warnings though but incorrect code generation. Since
is exhibited by pretty trivial test cases (testsuite/g++.dg/cpp0x/initlist86.C
confirms that { i++, i++ } works but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792
--- Comment #8 from Matthijs van Duin ---
(In reply to Matthijs van Duin from comment #4)
> return std::pair{ ++i, ++i }.first;
My bad! This isn't an exhibit of the bug. I simply forgot that std::pair is not
really a struct, and this
On Jan 24, 2019, Jason Merrill wrote:
> The latter; you can't have a partial specialization in a function.
*nod* (though not entirely reflected in the patch below, I see)
>> Any suggestion of a good name for the inline function (or would you
>> prefer it to be a macro?) that tests whether a
It's also broken the build of the glibc testsuite, e.g.:
../time/time.h:88:15: error: mismatch in argument 1 type of built-in function
'strftime'; expected 'char *' [-Werror=builtin-declaration-mismatch]
88 | extern size_t strftime (char *__restrict __s, size_t __maxsize,
(presence or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066
--- Comment #4 from Matthew Wuensche ---
(In reply to Andrew Pinski from comment #2)
> >Built by MinGW-W64 project
>
> Can you make sure you downloaded all of the correct binaries.
Hi, um... I just uninstalled my online download... then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #11 from Antony Lewis ---
I posted remaining ICE in 9.0.0 20190119 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069
Bug ID: 89069
Summary: ICE in select type with function returning class array
pointer
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89063
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89068
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067
--- Comment #1 from Antony Lewis ---
The error message on this code
subroutine test
type x
end type
type, extends(x):: y
integer ii
end type
type(y) yy
yy%i=1
end subroutine
is
Error: 'i' at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89068
Bug ID: 89068
Summary: Nested inline anonymous namespaces are erroneously
reported as conflicting
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity:
On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote:
> On 1/25/19 12:09 PM, Marek Polacek wrote:
> > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
> > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
> > > >
> > > > On 1/24/19 2:16 PM, Marek Polacek wrote:
> > > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067
Bug ID: 89067
Summary: Inaccurate error message: 'i' at (1) is not a member
of the 'x' structure
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066
--- Comment #3 from Matthew Wuensche ---
I ran the online installer... and received this file mingw-w64-install.exe.
And I reran the file to make sure all of those files were added. I found cc1
and added that path before submitting my "bug"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066
--- Comment #2 from Andrew Pinski ---
>Built by MinGW-W64 project
Can you make sure you downloaded all of the correct binaries.
On Thu, Jan 24, 2019 at 11:17:45PM +, Steve Ellcey wrote:
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -9294,6 +9294,44 @@ aarch64_mask_and_shift_for_ubfiz_p (scalar_int_mode
> mode, rtx mask,
>& ((HOST_WIDE_INT_1U << INTVAL (shft_amnt)) - 1)) ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066
Andrew Pinski changed:
What|Removed |Added
Target|*-mingw* *-cygwin* |i686-w64-mingw32
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89056
--- Comment #6 from Darryl Okahata ---
(OK, at this point, I'm just whinging, so please feel free to ignore this.)
I just wish the C++ standard instead just allowed an undefined value to be
returned, instead of generating bad optimized code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066
Bug ID: 89066
Summary: After creating valid paths, the \ in source directory
are / which creates "No such file or directory"
Product: gcc
Version: 8.1.0
Status:
Snapshot gcc-8-20190125 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190125/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846
--- Comment #6 from Vladimir Makarov ---
Sorry, I wrote wrong PR number in the ChangeLog entry (I already fix the
number). Here is the info about the patch I've committed
Author: vmakarov
Date: Fri Jan 25 22:13:43 2019
New Revision: 268280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
Committed as rev. 268280
Index: ChangeLog
===
--- ChangeLog (revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065
--- Comment #2 from baltic <1000hz.radiowave at gmail dot com> ---
Ok, i see 26.2.6.6 section of the standard:
iterator of an associative container is of the bidirectional iterator category.
For associative containers where the value type is
On Fri, 2019-01-25 at 10:32 +, Richard Earnshaw (lists) wrote:
>
> Do we need another variant pattern to handle the case where the
> insertion is into the top of the destination? In that case the
> immediate mask on the shifted operand is technically redundant as the
> bottom bits are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065
--- Comment #1 from Marc Glisse ---
iterator and const_iterator are the same type for std::set, the elements are
always immutable...
On Sat, 26 Jan 2019, Tejas Joshi wrote:
> function with byte-byte comparison which also include mpfr. (Correct
> me if I am wrong.) What is the significance of mpfr related to these
> internal representations?
real.c provides a fixed-size representation of floating-point numbers that
allows for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810
--- Comment #8 from kargl at gcc dot gnu.org ---
Created attachment 45533
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45533=edit
patch
The attached patch re-arranges the code to hopefully clarify the logic.
2019-01-26 Steven G. Kargl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065
Bug ID: 89065
Summary: set::find always returns const iterator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Fri, Jan 25, 2019 at 10:05:00AM -0500, Jason Merrill wrote:
> On 1/24/19 7:17 PM, Marek Polacek wrote:
> > On Wed, Jan 23, 2019 at 03:34:04PM -0500, Jason Merrill wrote:
> > > On Wed, Jan 23, 2019 at 12:57 PM Marek Polacek wrote:
> > > >
> > > > On Wed, Jan 23, 2019 at 09:00:36AM -0500, Jason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34871
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89044
--- Comment #5 from Jonathan Wakely ---
OK thanks, I'll try to take a look into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89064
Bug ID: 89064
Summary: [9 regression] libgomp.graphite/force-parallel-5.c
fails starting with r268257
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336
--- Comment #8 from Paul Thomas ---
Author: pault
Date: Fri Jan 25 20:08:58 2019
New Revision: 268279
URL: https://gcc.gnu.org/viewcvs?rev=268279=gcc=rev
Log:
2019-01-25 Paul Thomas
PR fortran/87336
* trans-array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88961
David Binderman changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89063
Bug ID: 89063
Summary: [x86] lack of support for BEXTR from BMI extension
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
It took some time to get know using GDB, but upto some end I got it to
work. The enum real_value_class is used to classify the number into
zero, normal, infinity and NaN.
This class is represented by r->cl in real_value and values in struct
real_value are used as flags or representations while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
--- Comment #6 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Fri Jan 25 19:50:55 2019
New Revision: 268278
URL: https://gcc.gnu.org/viewcvs?rev=268278=gcc=rev
Log:
/cp
2019-01-25 Paolo Carlini
PR c++/88969
* call.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #3)
>
> Code compiles if I delete the suspicious code.
>
Unfortunately, there is a regression in the testsuite,
and even more unfortunate, the regression comes in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67946
--- Comment #4 from Stupachenko Evgeny ---
fixed starting from gcc 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66835
--- Comment #5 from Stupachenko Evgeny ---
Yes, It is fixed starting from 5.3.
On Fri, 2019-01-25 at 08:59 -0800, Nathan Sidwell wrote:
> On 1/25/19 8:48 AM, David Malcolm wrote:
> > PR c++/89036 reports an ICE due to this assertion failing
> >
> > 1136 /* A class should never have more than one
> > destructor. */
> > 1137 gcc_assert (!current_fns ||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 85603, which changed state.
Bug 85603 Summary: ICE with character array substring assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
--- Comment #7 from Steve Kargl ---
On Fri, Jan 25, 2019 at 06:40:14PM +, jvdelisle at gcc dot gnu.org wrote:
>
> --- Comment #6 from Jerry DeLisle ---
> (In reply to Steve Kargl from comment #5)
> --- snip ---
> >
> > Of course, I could
> Hi.
>
> The patch puts back ::get_create for a node that can be seen first time.
> It's due to -O0 optimize attribute. It was unable to write properly
> LTO test-case for it.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 87151, which changed state.
Bug 87151 Summary: allocating array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336
--- Comment #7 from Paul Thomas ---
(In reply to Harald Anlauf from comment #6)
> The patch in comment #3 seems to apply to gcc-8, but I haven't regtested it.
> Paul, do you intend to backport it?
It is regtesting on 8-branch as I write.
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
> Hi.
>
> This is one very similar patch.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
> From adf577edd5a1d2b6ed78c1cc18feaff23fbfdd1c Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Thu, 24 Jan 2019 16:07:29 +0100
>
Dne 2019-01-25 19:10, Martin Jambor napsal:
Hi,
the following patch fixes a verification ICE because of mismatching BB
and cgraph_edge counts arising as a consequence of cleaning-up CFG
after
IPA-CP transformation, which is currently done as if it was a normal
tree pass, and which IPA passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062
--- Comment #2 from Barry Revzin ---
This may or may not be the same bug as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709, I do not know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062
Marek Polacek changed:
What|Removed |Added
Keywords||rejects-valid
On Freitag, 25. Januar 2019 07:22:36 CET Nikhil Benesch wrote:
> Does anyone have advice to offer? Has anyone tried convincing the build
> system to compile some of the other target libraries (like libstdc++ or
> libgfortran) with -flto?
>
Make sure the static versions of the libraries are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062
Bug ID: 89062
Summary: class template argument deduction failure with
parentheses
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88933
--- Comment #17 from Martin Jambor ---
OK, I did that too and proposed a patch in
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01525.html
Hi,
the following patch fixes a verification ICE because of mismatching BB
and cgraph_edge counts arising as a consequence of cleaning-up CFG after
IPA-CP transformation, which is currently done as if it was a normal
tree pass, and which IPA passes should not attempt exaclty because of
this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85780
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
--- Comment #1 from joseph at codesourcery dot com ---
Guessing this might be another issue from pushdecl being called for
compound literals (r259641).
(Technically of course it's true that the jump misses the initialization
of the anonymous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85780
--- Comment #10 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jan 25 17:55:25 2019
New Revision: 268277
URL: https://gcc.gnu.org/viewcvs?rev=268277=gcc=rev
Log:
2019-01-25 Steven G. Kargl
PR fortran/85780
* decl.c
Richard, regarding your first mail, I'm afraid I'm not sure what you
mean. Isn't this exactly the section of configure.ac that handles
CC_FOR_TARGET? The Makefile is dumb and just passes the
autoconf-substituted value for CC_FOR_TARGET directly through.
(I agree the patch will need some tweaks to
Hi!
On Wed, Jan 23, 2019 at 03:57:28AM -0600, luo...@linux.vnet.ibm.com wrote:
> The 5 new builtins vec_sbox_be, vec_cipher_be, vec_cipherlast_be,
> vec_ncipher_be
> and vec_ncipherlast_be only support vector unsigned char type parameters.
> Add new instruction crypto_vsbox_ and crypto__ to
On January 25, 2019 6:17:54 PM GMT+01:00, Joseph Myers
wrote:
>On Fri, 25 Jan 2019, Nikhil Benesch wrote:
>
>> I am attempting to convince GCC to build target libraries with
>link-time
>> optimizations enabled. I am primarily interested in libgo, but this
>discussion
>
>Note that as far as I
This adds me to the Write After Approval list in MAINTAINERS.
Committed to trunk in r268276.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 268275)
+++ MAINTAINERS (working copy)
@@ -634,6 +634,7 @@ Canqun Yang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024
Marek Polacek changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
--- Comment #11 from Tamar Christina ---
Hi Vladimir,
I've tested the patch and checked the testcases.
The code is now better in most cases so no issue there. The testcases will need
to be updated but I can do that after the patch is
On Fri, Jan 25, 2019 at 12:15:28PM -0500, Nathan Sidwell wrote:
> On 1/25/19 5:28 AM, Tom de Vries wrote:
> >
> > This patch fixes it by passing "" instead of NULL, in the call to
> > elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
> > line 3044 (for .gnu_debuglink)
On Fri, 25 Jan 2019, Nikhil Benesch wrote:
> I am attempting to convince GCC to build target libraries with link-time
> optimizations enabled. I am primarily interested in libgo, but this discussion
Note that as far as I know issues with host-dependencies of LTO bytecode
(bug 41526) may still
On 1/25/19 5:28 AM, Tom de Vries wrote:
This patch fixes it by passing "" instead of NULL, in the call to
elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
line 3044 (for .gnu_debuglink) mentioned above.
Nathan, does this fix the problem for you? If not, can you provide
On 1/25/19 12:09 PM, Marek Polacek wrote:
On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
On 1/24/19 2:16 PM, Marek Polacek wrote:
This test ICEs since r159006 which added
type = ENUM_UNDERLYING_TYPE (type);
to
This is pretty unlikely in real code, but similar to Arm, the AArch64
ABI has a bug with the handling of 128-bit bit-fields, where if the
bit-field dominates the overall alignment the back-end code may end up
passing the argument correctly. This is a regression that started in
gcc-6 when the ABI
On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
> On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
> >
> > On 1/24/19 2:16 PM, Marek Polacek wrote:
> > > This test ICEs since r159006 which added
> > >
> > > type = ENUM_UNDERLYING_TYPE (type);
> > >
> > > to type_promotes_to. In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #11 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Jan 25 17:09:33 2019
New Revision: 268273
URL: https://gcc.gnu.org/viewcvs?rev=268273=gcc=rev
Log:
This is pretty unlikely in real code, but similar to Arm, the AArch64
ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89055
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
On 1/25/19 8:48 AM, David Malcolm wrote:
PR c++/89036 reports an ICE due to this assertion failing
1136 /* A class should never have more than one destructor. */
1137 gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
on this template with a pair of dtors, with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89037
--- Comment #4 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Fri Jan 25 16:57:32 2019
New Revision: 268272
URL: https://gcc.gnu.org/viewcvs?rev=268272=gcc=rev
Log:
Fix output_constructor_bitfield handling of wide bitfields
On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
>
> On 1/24/19 2:16 PM, Marek Polacek wrote:
> > This test ICEs since r159006 which added
> >
> > type = ENUM_UNDERLYING_TYPE (type);
> >
> > to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we
> > haven't yet parsed
On 25 January 2019 12:44:30 CET, Sebastian Huber
wrote:
>libgfortran/
>
> * io/async.c (init_adv_cond): Use
> __GTHREAD_COND_INIT_FUNCTION().
LGTM.
Please CC the FORTRAN list for FORTRAN patches.
thanks,
>---
> libgfortran/io/async.c | 2 +-
> 1 file changed, 1 insertion(+), 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024
Marek Polacek changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #5 from
On January 25, 2019 7:22:36 AM GMT+01:00, Nikhil Benesch
wrote:
>I am attempting to convince GCC to build target libraries with
>link-time
>optimizations enabled. I am primarily interested in libgo, but this
>discussion
>seems like it would be applicable to libstdc++, libgfortran, etc. The
On January 25, 2019 1:12:07 PM GMT+01:00, Richard Sandiford
wrote:
>The testcase was failing because we were trying to access
>TREE_INT_CST_ELT (x, 1) of a 128-bit integer that was small enough
>to need only a single element.
>
>Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89036
--- Comment #3 from David Malcolm ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01513.html
PR c++/89036 reports an ICE due to this assertion failing
1136 /* A class should never have more than one destructor. */
1137 gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
on this template with a pair of dtors, with
mutually exclusive "requires" clauses:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813
Jakub Jelinek changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77938
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87639
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060
Jakub Jelinek changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
---
Here we warn because i::dispatch has internal linkage (because l
does) and is never instantiated (because the vtable is never emitted).
The regression happened because devirtualization started adding it to
cgraph as a possible target. I think the way to fix this is to avoid
adding an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
1 - 100 of 190 matches
Mail list logo
