https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97722
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97718
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97717
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723
Bug ID: 97723
Summary: type bound ASSIGNMENT(=) within select rank block
wrongly rejected
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97237
Toni Neubert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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: c+
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
Prio
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=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 just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97685
--- Comment #1 from Hongtao.liu ---
HRESET wouldn't be supported on SPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97373
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> r11-4269 and r11-4270 made a bit difference on trunk.
s/bit/big/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #10 from Jonathan Wakely ---
r11-4269 and r11-4270 made a bit difference on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97719
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97719
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:8f565d255a3157828e45f8b9844b3d156193c182
commit r11-4729-g8f565d255a3157828e45f8b9844b3d156193c182
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97719
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97719
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-11-04
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96720
Abrahm Scully changed:
What|Removed |Added
CC||abrahm.scully at gmail dot com
--- Comme
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=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=97668
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=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=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=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 #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 (!fixed_regs[
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=97567
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #23 from Segher B
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=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=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 t
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=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 i
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=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=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 th
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=97717
Rahul Kranti Kiran changed:
What|Removed |Added
CC||kranti.rkiran at gmail dot com
---
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
Prio
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
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534
Otto Kekäläinen changed:
What|Removed |Added
CC||otto at kekalainen dot net
--- Comment
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=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 the
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=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 +5871,
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
> +++ gcc/funct
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 FI
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 #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?
>
> Th
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 || TARGET_FLOAT_RETURNS_IN_
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: 'voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618
Jonathan Wakely changed:
What|Removed |Added
CC||haining.cpp at gmail dot com
--- Comme
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=96184
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Key
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
> > > mod
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=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, b
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=96657
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=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=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
Date:
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, zero_all_st_
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
--- Comment
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 **compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702
Jonathan Wakely changed:
What|Removed |Added
CC||tobias.bruell at gmail dot com
--- Com
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 recogniz
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|Removed
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=66360
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
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=77285
Jonathan Wakely changed:
What|Removed |Added
CC||saarraz2 at gmail dot com
--- Comment
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=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=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;
t
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 re
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 recon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97706
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Richard Bi
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=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=97715
Martin Liška changed:
What|Removed |Added
Known to fail||11.0
Last reconfirmed|
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=97709
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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 on.
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=97593
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97673
--- Comment #2 from Jan Hubicka ---
This should be dup of PR97578
1 - 100 of 155 matches
Mail list logo
