https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97706
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
Martin Liška changed:
What|Removed |Added
Known to fail||11.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97706
--- Comment #7 from Richard Biener ---
OK, so for the stores in the loop we end up with a bool pattern for the store
we don't support (eh):
t.i:24:14: note: Starting SLP discovery for
t.i:24:14: note: VIEW_CONVERT_EXPR(arr[0]) = patt_88;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:9c1125c121423a9948fa39e71ef89ba4059a2fad
commit r11-4723-g9c1125c121423a9948fa39e71ef89ba4059a2fad
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #7 from Uroš Bizjak ---
(In reply to qinzhao from comment #5)
> (In reply to H.J. Lu from comment #2)
> > (In reply to qinzhao from comment #1)
> > > for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #11 from Jakub Jelinek ---
I think you should do:
--- gcc/function.c 2020-10-31 17:41:19.756740009 +0100
+++ gcc/function.c 2020-11-04 17:02:51.199298173 +0100
@@ -5871,6 +5871,8 @@ gen_call_used_regs_seq (rtx_insn *ret, u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #17 from Qing Zhao ---
> On Nov 4, 2020, at 10:08 AM, ubizjak at gmail dot com
> wrote:
>>
>> I used the following in middle end to exclude fixed registers from being
>> zeroed:
>> if (fixed_regs[regno])
>>continue;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #20 from Jakub Jelinek ---
But the user didn't do anything wrong, perhaps just had bad expectations.
The user asked put the value of this variable into a general purpose register
or memory. So the compiler did that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97515
--- Comment #5 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:e86fd6a17cdb26710d1f13c9a47a3878c76028f9
commit r11-4724-ge86fd6a17cdb26710d1f13c9a47a3878c76028f9
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97712
--- Comment #2 from Marek Polacek ---
Looks like we don't track attributes properly for OBJ_TYPE_REFs in
maybe_warn_nodiscard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #19 from Jakub Jelinek ---
And, actually the function.c change is probably unnecessary, because the
if (!crtl->abi->clobbers_full_reg_p (regno))
continue;
if (!fixed_regs[i])
continue;
should already rule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97712
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97719
Bug ID: 97719
Summary: "Implement C++20 features for " changed
behavior of istreambuf_iterator
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #19 from Segher Boessenkool ---
Documenting that GCC behaves differently is just documenting a bug :-(
It should not be hard to detect this and give an error somewhere?
Saying "the user did something wrong" is true of course, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #18 from Jakub Jelinek ---
--- gcc/function.c.jj 2020-10-31 17:41:19.756740009 +0100
+++ gcc/function.c 2020-11-04 17:56:53.790403571 +0100
@@ -5871,6 +5871,8 @@ gen_call_used_regs_seq (rtx_insn *ret, u
continue;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #21 from Qing Zhao ---
> --- Comment #19 from Jakub Jelinek ---
> And, actually the function.c change is probably unnecessary, because the
> if (!crtl->abi->clobbers_full_reg_p (regno))
>continue;
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #22 from qinzhao at gcc dot gnu.org ---
proposed patch:
This change fixes a bug in the i386 backend when adding
-fzero-call-used-regs=all on a target that has no x87
registers.
When there is no x87 registers available, we should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96720
Abrahm Scully changed:
What|Removed |Added
CC||abrahm.scully at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97515
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97668
--- Comment #2 from Arseny Solokha ---
Finally, a C testcase:
void
wb (_Complex double jh)
{
_Complex double af = 0.0;
do
{
af += jh;
}
while (af != 0.0);
}
_Complex double
o6 (void)
{
_Complex double ba = 0.0;
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97718
Bug ID: 97718
Summary: [11 regression] Excessive GDB memory usage after GCC
"Save some memory at debug stream-in time"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #21 from Segher Boessenkool ---
register float foo asm ("xmm0") = 0.99f;
asm volatile("movl %0, %%r8d\n\t"
"vmcall\n\t"
:: "g" (foo));
The user said operands[0] should go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #23 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #20 from Qing Zhao ---
> On Nov 4, 2020, at 11:48 AM, jakub at gcc dot gnu.org
> wrote:
>
> --- Comment #18 from Jakub Jelinek ---
> --- gcc/function.c.jj 2020-10-31 17:41:19.756740009 +0100
> +++ gcc/function.c 2020-11-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97668
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720
Bug ID: 97720
Summary: Sometimes std::current_exception does not work
properly in the terminate handler
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
Bug ID: 97715
Summary: [11 Regression] ICE in insn_default_length, at
config/i386/i386.md:15325 since
r11-4578-gd10f3e900b0377b4
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97706
--- Comment #6 from Richard Biener ---
I guess we're missing what usually is done by bool patterns here, namely
adding a conversion from the mask vector type produced by the comparison
to the value vector type.
A simple workaround would be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #1 from qinzhao at gcc dot gnu.org ---
for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit
mode, However, command line option force no 80387 mode, the following insn
generated to zero st registers is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #8 from Jakub Jelinek ---
It is not fixed, but it is removed from accessible_reg_set.
The same way how e.g. MMX regs are removed from it if !TARGET_MMX or SSE
registers if !TARGET_SSE.
You shouldn't try to zero unaccessible registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88725
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618
Jonathan Wakely changed:
What|Removed |Added
CC||haining.cpp at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618
--- Comment #7 from Jonathan Wakely ---
>From Bug 88725
gcc fails to deduce that the friend declaration refers to ::func in the
below
```
template
void func(T);
class Cls {
friend void ::func(int);
};
```
Rejecting with
```
error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #13 from Qing Zhao ---
> On Nov 4, 2020, at 10:04 AM, jakub at gcc dot gnu.org
> wrote:
> --- Comment #11 from Jakub Jelinek ---
> I think you should do:
> --- gcc/function.c 2020-10-31 17:41:19.756740009 +0100
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #12 from Uroš Bizjak ---
(In reply to Qing Zhao from comment #10)
> > On Nov 4, 2020, at 9:45 AM, ubizjak at gmail dot com
> > wrote:
> >> fixed registers should already be excluded from zeroing.
> >> are ST registers considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #15 from Jakub Jelinek ---
They aren't live. But that loop checks that only if only_used is true, when
one uses =all, it marks all regs that aren't fixed, aren't live at the end of
the function and a few other checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918
Federico Kircheis changed:
What|Removed |Added
CC||federico.kircheis at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97713
--- Comment #2 from Tom de Vries ---
Filed corresponding binutils PR: "objcopy --extract-dwo silently drops
relocation" at https://sourceware.org/bugzilla/show_bug.cgi?id=26841 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97549
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97706
--- Comment #8 from Richard Biener ---
OK, so we'd indeed need to handle PHIs in vect_recog_bool_pattern which might
turn out a bit complicated. I'm not a fan of pattern detection for SLP
vectorization anyway so I'll see what to do here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96746
--- Comment #2 from Masamitsu MURASE ---
Thank you very much for your reply, Marek Polacek.
I'm sorry, but I cannot understand your comment clearly.
As you said, I also think that my example should be treated as ill-formed
program.
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88292
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
H.J. Lu changed:
What|Removed |Added
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702
Jonathan Wakely changed:
What|Removed |Added
CC||tobias.bruell at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #3 from Jakub Jelinek ---
;; Floating-point register constraints.
(define_register_constraint "f"
"TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387 ? FLOAT_REGS : NO_REGS"
"Any 80387 floating-point (stack) register.")
So,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96184
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94971
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:e0af865ab9d9d5b6b3ac7fdde26cf9bbf635b6b4
commit r11-4722-ge0af865ab9d9d5b6b3ac7fdde26cf9bbf635b6b4
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97300
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> ;; Floating-point register constraints.
> (define_register_constraint "f"
> "TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387 ? FLOAT_REGS : NO_REGS"
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #10 from Qing Zhao ---
> On Nov 4, 2020, at 9:45 AM, ubizjak at gmail dot com
> wrote:
>> fixed registers should already be excluded from zeroing.
>> are ST registers considered FIXED registers when -mno-80387 is specified?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> They aren't live. But that loop checks that only if only_used is true, when
> one uses =all, it marks all regs that aren't fixed, aren't live at the end
> of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97717
Rahul Kranti Kiran changed:
What|Removed |Added
CC||kranti.rkiran at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97705
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Component|other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97666
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:8d887367a7a3bc2cf1ca926899567aeeba915e44
commit r11-4708-g8d887367a7a3bc2cf1ca926899567aeeba915e44
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97691
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97709
Richard Biener changed:
What|Removed |Added
Target|powerpc |powerpc64le
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97692
--- Comment #7 from Andreas Schwab ---
https://gcc.gnu.org/install/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #5 from Jonathan Wakely ---
Yep, that fixes the testcases above, thanks. Retrying the libstdc++ tests ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710
--- Comment #6 from Mick P. ---
Desired scenario: https://godbolt.org/z/zKnh1s
template struct T{};
struct A{};
struct B:A{ int x; };
struct C:A{ T y; };
Changing x to char yields the other diagnostic. PtoM types are fungible, I
don't know why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #16 from Boris ---
(In reply to Jakub Jelinek from comment #14)
> No, why? You ask it to go into a general register, so it goes there. The
> local register variable has no priority at all.
And where in the documentation does it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97699
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
--- Comment #6 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #1)
> To clarify a bit: is installed by the VC++ toolchain or WDK, not by
> Windows SDK. Nevertheless, it is a system header both MS's CRT and Win32
> headers rely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97706
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #2)
> (In reply to qinzhao from comment #1)
> > for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit
> > mode, However, command line option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95977
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96746
--- Comment #4 from Jakub Jelinek ---
What Marek explained is that your testcase is buggy, but it may or may not be
diagnosed, unless the template is instantiated. If you instantiate such
template, it has to be rejected by all implementations,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534
Otto Kekäläinen changed:
What|Removed |Added
CC||otto at kekalainen dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97709
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67135
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97712
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66360
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #9 from Uroš Bizjak ---
(In reply to qinzhao from comment #6)
> (In reply to Jakub Jelinek from comment #3)
> > ;; Floating-point register constraints.
> > (define_register_constraint "f"
> > "TARGET_80387 ||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #14 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #11)
> I think you should do:
> --- gcc/function.c2020-10-31 17:41:19.756740009 +0100
> +++ gcc/function.c2020-11-04 17:02:51.199298173 +0100
> @@ -5871,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97716
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97717
Bug ID: 97717
Summary: compilation with -O(1/2/3) flag failed while -O0
succeeds
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 96789, which changed state.
Bug 96789 Summary: x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
Bug ID: 97721
Summary: [11 Regression] ICE in verify_range, at
value-range.cc:361
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94971
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97673
--- Comment #2 from Jan Hubicka ---
This should be dup of PR97578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97698
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97714
Martin Liška changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994
Bug 59994 depends on bug 69775, which changed state.
Bug 69775 Summary: thread_local extern variable causes linkage error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69775
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69775
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77285
Jonathan Wakely changed:
What|Removed |Added
CC||saarraz2 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994
Bug 59994 depends on bug 58366, which changed state.
Bug 58366 Summary: invocation of thread_local class containing bound function
leads to : "Illegal instruction: 4"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #21 from Jonathan Wakely ---
The abi_check failures are of course expected if you configure with an option
that alters the library ABI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96746
--- Comment #3 from Jonathan Wakely ---
The standard says "no diagnostic required". It's not a bug if a compiler
accepts the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97716
Bug ID: 97716
Summary: Class's `operator delete`should be implicitly
`noexcept`
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97705
--- Comment #4 from Kewen Lin ---
I think my commit just exposed one bug in ira. The newly introduced function
remove_scratches can bump the max_regno, then the data structures
regstat_n_sets_and_refs and reg_info_p which are allocated according
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97722
Bug ID: 97722
Summary: undefined symbol: __gcov_indirect_call_callee
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720
--- Comment #2 from m101010a at gmail dot com ---
> when the compiler can see there is no matching handler for the exception,
> it doesn't perform stack unwinding
This is fine, it's implementation-defined whether the stack is unwound.
> it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
1 - 100 of 155 matches
Mail list logo
