https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98827
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829
--- Comment #4 from Richard Biener ---
The issue is likely GCC canonicalizing the NaN somewhere and your is_value
doing a 1:1 bit comparison. In particular we optimize MyNAN::value to
MyNAN::value ()
{
[local count: 1073741824]:
return Na
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
Bug ID: 98833
Summary: [11 Regression] ICE in extract_insn, at recog.c:2769
since r11-6849-gee78c20e74d30284
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
Martin Liška changed:
What|Removed |Added
Known to work||10.2.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98815
Martin Liška changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
Thomas Koenig changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98828
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-01-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813
--- Comment #6 from Richard Biener ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Jiu Fu Guo from comment #0)
> > For the below code:
> > ---t.c
> > void
> > foo (const double* __restrict__ A, const double* __restrict__ B, dou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
--- Comment #6 from Thomas Koenig ---
This actually segfaults at runtime.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834
Bug ID: 98834
Summary: Code path incorrectly determined to be unreachable
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
--- Comment #13 from rguenther at suse dot de ---
On Mon, 25 Jan 2021, jason at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
>
> --- Comment #12 from Jason Merrill ---
> Yeah, adding restrict there is just wrong;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98807
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:eb77a934eec8fe52e4c5612f5264127290bc517d
commit r11-6905-geb77a934eec8fe52e4c5612f5264127290bc517d
Author: Jakub Jelinek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
--- Comment #7 from martin ---
With a recent gfortran version I get (how did you compile that you can run the
code):
fun_select.f90:37:15:
37 | f => selector()
| 1
internal compiler error: Segmentation fault
0xc1f3af cras
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
Thomas Koenig changed:
What|Removed |Added
Summary|[OOP] segfault with |[OOP] ICE with procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
--- Comment #1 from Hongtao.liu ---
hmm, why TARGET_SSE2 && !TARGET_XOP?
(define_insn "*sse2_eq3"
[(set (match_operand:VI124_128 0 "register_operand" "=x,x")
(eq:VI124_128
(match_operand:VI124_128 1 "vector_operand" "%0,x")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-01-26
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
--- Comment #2 from Hongtao.liu ---
Oh, becuase xop has it's own integer compare
(define_insn "xop_maskcmp3"
[(set (match_operand:VI_128 0 "register_operand" "=x")
(match_operator:VI_128 1 "ix86_comparison_int_operator"
[(matc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834
--- Comment #2 from Matthias Kretz (Vir) ---
This is reduced from a larger (4MB) testcase which doesn't have any unused
arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
--- Comment #4 from Richard Biener ---
Eventually XOP has some "better" compares (vpcom).
Btw, why do we have a define_expand for "sse2_eq3"? Do we use this
as building block internally? Then we should remove the !TARGET_XOP from
that? That i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
--- Comment #5 from Richard Biener ---
Or rather keep the define_expand but remove the !TARGET_XOP from the
define_insn?
Will we be confused when we have two define_insns matching?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
--- Comment #6 from Jakub Jelinek ---
I think the expander is there to perform ix86_fixup_binary_operands_no_copy
(there is a lot of other expanders that have the sole purpose of doing that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834
--- Comment #3 from Matthias Kretz (Vir) ---
Created attachment 50055
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50055&action=edit
unreduced test case
This is the test case I gave to C-Vise. It's already reduced from a more
confusing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98835
Bug ID: 98835
Summary: False positive -Wclass-memaccess with class with
ref-qualified copy-assignment operator
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98833
--- Comment #7 from Jakub Jelinek ---
If two insns with the same RTL match, then the first one wins.
But the vpcom instructions have different RTL, so I see no reason for the
!TARGET_XOP.
grepping for sse2_eq I see only:
i386-builtin.def:BDESC (O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834
--- Comment #4 from Jakub Jelinek ---
Started with r10-3106-g46dfa8ad6c18feb45d35734eae38798edb7c38cd
Anyway, I wonder if this isn't similar to the cases where the inliner
optimistically assumed that __builtin_constant_p will fold to true but did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834
--- Comment #5 from rguenther at suse dot de ---
On Tue, 26 Jan 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834
>
> --- Comment #4 from Jakub Jelinek ---
> Started with r10-3106-g46dfa8ad6c18feb45d357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829
--- Comment #5 from Nemanja Boric ---
Yes, it seems that if the constants are `constexpr` or `static inline const`
the custom payload is gone.
I guess this is aligned to
https://en.cppreference.com/w/cpp/types/numeric_limits/quiet_NaN
"A NaN n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94408
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Resol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701
Jakub Jelinek changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67539
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:d40b21eebc9d41c3cb9ccbdf6338968436550621
commit r11-6910-gd40b21eebc9d41c3cb9ccbdf6338968436550621
Author: Martin Liska
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98830
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2021-01-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:7b7ae189d3ef385b29fa4d5aafa6e01e6111a336
commit r10-9302-g7b7ae189d3ef385b29fa4d5aafa6e01e6111a336
Author: Martin Liska
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
Martin Liška changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98836
Bug ID: 98836
Summary: tie with spaceship requires operator==
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98815
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98837
Bug ID: 98837
Summary: SLP discovery does not consider all lane permutes
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98563
--- Comment #6 from Richard Biener ---
(In reply to Jakub Jelinek from comment #5)
> That change included an important bugfix for the simd handling of
> addressable locals, when they escape they would be then mishandled during
> vectorization.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
Martin Liška changed:
What|Removed |Added
CC||jwakely at redhat dot com
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98828
--- Comment #2 from Martin Liška ---
I can confirm that even on x86_64-linux-gnu.
Thanks for the report!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #3 from Richard Biener ---
Created attachment 50056
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50056&action=edit
patch to make dumping not ICE
The attached avoids ICEing during dumping (it seems there's no reason to export
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
--- Comment #3 from Jonathan Wakely ---
(In reply to Martin Liška from comment #2)
> I think it's a bug in libstdc++ and one can see it with valgrind:
But there's no error when compiled with clang and libstdc++, so that suggests
the problem is g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98838
Bug ID: 98838
Summary: Spam sent to dedicated Bugzilla e-mail address
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98838
Christoph Conrads changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
--- Comment #4 from Jonathan Wakely ---
#include
using std::size_t;
struct alignas(32) Foo
{
char x;
void * operator new[ ] (size_t s, std::align_val_t a)
{
void* p = aligned_alloc(static_cast(a), s);
__builtin_pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #4 from Richard Biener ---
So looks like induction vectorization is the culprit here but I also guess
that's actually supported?
-fdisable-tree-fre4 -fdisable-tree-fre5 -fdisable-tree-dom3
makes the testcase compile since we only re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
--- Comment #9 from Paul Thomas ---
Created attachment 50057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50057&action=edit
Patch that "fixes" all versions of the problem
The attached patch has a fragment of my finalize on assignment pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819
--- Comment #5 from Jonny Grant ---
(In reply to David Malcolm from comment #4)
> In comment #0, the bottom-most "%u" is a fix-it hint, giving the nonsensical
> suggestion to the user that they replace the "%u" with itself. Clearly we
> shouldn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
--- Comment #5 from Jonathan Wakely ---
I wonder if https://itanium-cxx-abi.github.io/cxx-abi/abi.html#array-cookies
needs to be updated for aligned new[] expressions, or if G++ is just not
accounring for them correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98563
--- Comment #7 from Jakub Jelinek ---
I'm afraid no.
The vectorization can handle addresses into the simd arrays, but right now only
if it accesses the whole element, i.e. when we can turn the simd array into a
vector register (or set thereof) th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
--- Comment #6 from Jonathan Wakely ---
Yes, I think the ABI needs fixing. In this example Foo has a trivial destructor
and Foo::operator delete[](void*, size_t, align_val_t) does not have two
parameters. According to the ABI, no cookie is needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
--- Comment #7 from Jonathan Wakely ---
Also, the note in that section of the ABI is wrong:
> (Note: if the usual array deallocation function takes two arguments,
> then it is a member function whose second argument is of type size_t.
That was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819
--- Comment #6 from Jonny Grant ---
Godbolt %u example
https://godbolt.org/z/sc7K6T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
--- Comment #8 from Jonathan Wakely ---
I've reported this as https://github.com/itanium-cxx-abi/cxx-abi/issues/119 but
I haven't tried to fix the spec, or fix G++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98828
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:2e81b16c24367d7cc92f6d369606dca5575f6b5f
commit r11-6911-g2e81b16c24367d7cc92f6d369606dca5575f6b5f
Author: Martin Liska
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98828
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
--- Comment #19 from Marius Hillenbrand ---
Eric, I have bootstrapped and successfully reg-tested your proposed fix on
s390x and x86-64. fwict, it works as intended.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98563
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> I'm afraid no.
> The vectorization can handle addresses into the simd arrays, but right now
> only if it accesses the whole element, i.e. when we can turn the si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98838
--- Comment #2 from Jonathan Wakely ---
Indeed: https://gcc.gnu.org/pipermail/gcc-bugs/2021-January/727161.html
It was discussed when we moved to the new list software and it was suggested
that simply replacing "@" with " at " and ".com" with "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4b59dbb5d6759e43bfa23161a8d3feb9ae969e1a
commit r11-6912-g4b59dbb5d6759e43bfa23161a8d3feb9ae969e1a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #6 from Richard Biener ---
RTL expansion ICE remains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98563
--- Comment #9 from Jakub Jelinek ---
(In reply to Richard Biener from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > I'm afraid no.
> > The vectorization can handle addresses into the simd arrays, but right now
> > only if it acce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
--- Comment #31 from Richard Biener ---
-fno-tree-ter improves things quite a bit. With -DNAILED_REGS gimple doesn't
do much because we treat registers as memory here.
For trunk
-O2 has 52 spills
-O2 -fno-tree-ter has 35 spills
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:17ad8cdebe65b47d257d85849747b806af0a85fd
commit r11-6914-g17ad8cdebe65b47d257d85849747b806af0a85fd
Author: Jakub Jelinek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression]
|a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #11 from david.welch at netronome dot com ---
I wish I had know this when I filed this ticket, there is an ARM Errata for
this issue that was issued before or in 2009.
720247: Speculative Instruction fetches can be made anywhere in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #12 from david.welch at netronome dot com ---
I my case this was found with a hang, but the problem exists as a read, which
means it can cause a read to a read sensitive peripheral causing adverse
affects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98827
--- Comment #2 from seurer at gcc dot gnu.org ---
On power 8 I used:
configure --enable-languages=c,fortran,c++ --with-cpu=power8
--disable-bootstrap --disable-multilib
On power 7 it was the same but --with-cpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
--- Comment #10 from Paul Thomas ---
(In reply to Paul Thomas from comment #9)
> Created attachment 50057 [details]
> Patch that "fixes" all versions of the problem
>
> The attached patch has a fragment of my finalize on assignment patch in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98839
Bug ID: 98839
Summary: [11 regression] compilation failure for dwarf2asm.c
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98839
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98839
--- Comment #2 from Jakub Jelinek ---
That is because most targets define POINTER_SIZE as (condition ? 64 : 32) or
constant while rs6000 as a variable holding it, therefore whether it chooses
unsigned or signed type for it then matters in these c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98840
Bug ID: 98840
Summary: Why does baz call the delete operator for moved
unique_ptr
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98814
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #20 from Bill Long ---
Original customer is asking about the status of this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
--- Comment #6 from Ulrich Drepper ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 50058 [details]
> gcc11-pr98737.patch
>
> Untested fix.
This only handles sub?
The same applies to add, or, and, xor. Maybe nand? Can thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98839
--- Comment #3 from seurer at gcc dot gnu.org ---
I tried that and it now compiles ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
--- Comment #6 from Bill Long ---
Is there a released version with the fix noted in this bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
--- Comment #7 from Jakub Jelinek ---
The sub fix won't be the same as would add, perhaps xor/or/and can be handled
by the same peephole2, but even for that I'm not sure. Though e.g. trying
__atomic_or_fetch (&a, b, ...) == 0 doesn't seem to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98839
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6e44c09b2df7282e0b519f241cf54438ab183b5e
commit r11-6915-g6e44c09b2df7282e0b519f241cf54438ab183b5e
Author: Jakub Jelinek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80460
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
Bug ID: 98841
Summary: wrong ‘operator=’ should return a reference to ‘*this’
[-Weffc++]
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
--- Comment #1 from Olaf Mandel ---
Created attachment 50060
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50060&action=edit
Preprocessed source file of version 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
--- Comment #2 from Olaf Mandel ---
Created attachment 50061
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50061&action=edit
Console output of version 10.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
--- Comment #3 from Olaf Mandel ---
Created attachment 50062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50062&action=edit
Preprocessed source file of version 10.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-01-26
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98840
--- Comment #1 from Jonathan Wakely ---
The ABI requires it. The caller is responsible for constructing and destroying
the argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98840
--- Comment #2 from Jonathan Wakely ---
https://www.youtube.com/watch?v=rHIkrotSwcc discusses exactly this problem.
See also https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/
This is not a GCC bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
--- Comment #20 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:9c41bcc59c237aaa629e271f88c20a90cb8e0af5
commit r11-6916-g9c41bcc59c237aaa629e271f88c20a90cb8e0af5
Author: Eric Botcazou
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
--- Comment #21 from CVS Commits ---
The releases/gcc-10 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:f3e3fc277502626677c59e2a7f3dcefa9f9123b5
commit r10-9303-gf3e3fc277502626677c59e2a7f3dcefa9f9123b5
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
--- Comment #22 from CVS Commits ---
The releases/gcc-9 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:29f721366b718b60d4c72d82e42e1e3d0a6405c2
commit r9-9205-g29f721366b718b60d4c72d82e42e1e3d0a6405c2
Author: Eric Botcazou
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842
Bug ID: 98842
Summary: optional's spaceship operations generates wrong code
when operator== is not present
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98840
--- Comment #3 from Dmitriy Ovdienko ---
> This is not a GCC bug.
No it is not. But can we improve that?
That approach increases the binary size. In case if `baz` is called from many
places, that is going to increase the binary size.
1 - 100 of 138 matches
Mail list logo
