https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114785
--- Comment #2 from Andrew Pinski ---
I think the code code in maybe_push_res_to_seq for COMPARISON_CLASS_P can be
removed too ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114785
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114785
Bug ID: 114785
Summary: special handling of COND_EXPR in gimple_extract can be
removed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112893
--- Comment #8 from Gaius Mulley ---
Created attachment 57992
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57992=edit
Proposed fix v3
This patch creates a proctype for every procedure and then uses this associated
proctype during type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780
--- Comment #3 from Jakub Jelinek ---
Fixed for 14.1 so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c23db3ebb65ba357155be85ef56d037403eaee36
commit r14-10047-gc23db3ebb65ba357155be85ef56d037403eaee36
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2afdecccbaf5c5b1c7a235509b37092540906c02
commit r14-10046-g2afdecccbaf5c5b1c7a235509b37092540906c02
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #34 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a39983bf58d3097c472252f6989d19b60909dd9a
commit r14-10045-ga39983bf58d3097c472252f6989d19b60909dd9a
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a39983bf58d3097c472252f6989d19b60909dd9a
commit r14-10045-ga39983bf58d3097c472252f6989d19b60909dd9a
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766
--- Comment #1 from Vladimir Makarov ---
(In reply to Tamar Christina from comment #0)
> The documentation for ^ states:
>
> "This constraint is analogous to ‘?’ but it disparages slightly the
> alternative only if the operand with the ‘^’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
--- Comment #5 from Daniel Bertalan ---
I tried Jakub's patch (thank you for the super quick response!), it crashes if
the constructor has non-type template parameters:
template struct SpanImpl {
template SpanImpl();
};
template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
--- Comment #4 from Jakub Jelinek ---
Guess DECL_UNINLINABLE, maybe DECL_PRESERVE_P, TREE_USED, maybe
DECL_USER_ALIGN/DECL_ALIGN, maybe DECL_WEAK, maybe
DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT, DECL_NO_LIMIT_STACK.
TREE_READONLY, DECL_PURE_P,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #3 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
--- Comment #1 from Daniel Bertalan ---
Forgot to actually post the error message itself:
In constructor 'ErrorOr::ErrorOr(int)',
inlined from 'ErrorOr run()' at :29:10,
inlined from 'int serenity_main()' at :32:8:
:13:39: error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114770
--- Comment #1 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:eed7fb1b2fe72150cd6af10dd3b8f7fc4f0a4da1
commit r14-10043-geed7fb1b2fe72150cd6af10dd3b8f7fc4f0a4da1
Author: Jonathan Wakely
y_main() {
run();
}
---
gcc -v output:
GNU C++20
(Compiler-Explorer-Build-gcc-85c187b2127b937e211dfe46b4120d320ff661df-binutils-2.40)
version 14.0.1 20240419 (experimental) (x86_64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114781
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2024-04-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114782
--- Comment #2 from Andrew Pinski ---
I should note I tested aarch64 (where lea 3 operand instructions are still
cheap) and powerpc (where lea like instructions don't exist) and they produce
what I expect, aarch64 produces an lea like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90088
Andrew Pinski changed:
What|Removed |Added
CC||652023330028 at smail dot
nju.edu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114782
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
--- Comment #3 from Jakub Jelinek ---
Created attachment 57991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57991=edit
gcc14-pr114783.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
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=114783
--- Comment #2 from Jakub Jelinek ---
@@ -16831,7 +16882,7 @@ (define_insn "*avx2_eq3"
[(set (match_operand:VI_256 0 "register_operand" "=x")
(eq:VI_256
(match_operand:VI_256 1 "nonimmediate_operand" "%x")
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #3 from Joseph S. Myers ---
The actual effect of -fexcess-precision=fast is more like "outside the back
end, pretend excess precision doesn't exist, but the back end might use it
anyway" (complicated a bit by having genuine excess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
Bug ID: 114783
Summary: [14 Regression] Equality compares of vector builtins
spill one operand to the stack
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114730
--- Comment #3 from Joseph S. Myers ---
When implementing C23 enums with fixed underlying types I tried to ensure that
enums with underlying type bool were handled consistently with bool (cf. bug
96496 where they're not always handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:33bf8e5385099c2963f278bff38e4f917eddf1d8
commit r14-10041-g33bf8e5385099c2963f278bff38e4f917eddf1d8
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
--- Comment #6 from Marek Polacek ---
The former: I'd have to introduce checking that tracks all the declarations and
checks that their noexcept-specs match after delayed parsing has taken place.
It's not impossible but I didn't (and still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739
--- Comment #9 from Paul Thomas ---
> The incorrect errors will have to be fixed on 13-branch at very least.
> Unfortunately, this is not a question of using a backport but I will get
> onto it right away.
>
I have applied the backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114782
Bug ID: 114782
Summary: [Regression] Missed optimization of Induction Variable
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:5c3238b0d55ec13a2430aa606e2bfed9432e97ac
commit r13-8620-g5c3238b0d55ec13a2430aa606e2bfed9432e97ac
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:8a3784adf5cd873ca295a5a011d8623338ff3976
commit r13-8619-g8a3784adf5cd873ca295a5a011d8623338ff3976
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769
--- Comment #4 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:1216460e7023cd8ec49933866107417c70e933c9
commit r14-10040-g1216460e7023cd8ec49933866107417c70e933c9
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769
--- Comment #3 from Feng Xue ---
When half_type is null, and call chain would be:
vect_supportable_direct_optab_p (vinfo, sum_type, SAD_EXPR, NULL, ...)
-> get_vectype_for_scalar_type (vinfo, NULL)
-> get_related_vectype_for_scalar_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #13 from Matthias Kretz (Vir) ---
Should I open a new PR for the remaining ((u)int64, 16) <-> (float, 16)
conversions?
https://godbolt.org/z/x3xPMYKj3
Note that __builtin_convertvector produces the code we want.
template
using V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114767
--- Comment #6 from mjr19 at cam dot ac.uk ---
I was starting to wonder whether this issue might be related to that in bug
114324, which is a slightly more complicated example in which multiplication by
a purely imaginary number destroys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
--- Comment #18 from GCC Commits ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:b9ee0c8830592212678c402aed8a6b11ef8d2640
commit r12-10348-gb9ee0c8830592212678c402aed8a6b11ef8d2640
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114772
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
Georg-Johann Lay changed:
What|Removed |Added
Keywords||documentation
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114781
Bug ID: 114781
Summary: Error in ALLOCATE with MOLD=
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #7 from Jonathan Wakely ---
I think we might want to add __attribute__((cold)) to std::vector functions
that are now implicitly inline due to the addition of `constexpr`. We probably
don't want to use noinline as that's too strong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773
Xi Ruoyao changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #6 from Xi Ruoyao ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #9 from Georg-Johann Lay ---
When this PR won't be fixed, then maybe at least the documentation could
clarify how to port macros to inline functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:9451b6c0a941dc44ca6f14ff8565d74fe56cca59
commit r14-10039-g9451b6c0a941dc44ca6f14ff8565d74fe56cca59
Author: Thomas Schwinge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #8 from Richard Biener ---
I tried removing the TREE_SIDE_EFFECTS check at some point and it had quite
some fallout even in the testsuite. Don't remember the PR I tried this for ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780
Bug ID: 114780
Summary: Using C23 nullptr as sentinel gives missing sentinel
warning
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
--- Comment #5 from Jan Hubicka ---
> > Looking into it, instead of having simple outer loop it needs to
> > maintain worklist of defs to proceed each annotated with live bitmap,
> > rigt?
>
> Yeah, I have some patch on some branch somewhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #6 from Georg-Johann Lay ---
Recognizing more __builtin_constant_p situations is a good thing, IMO.
It would allow to transition from macros to inline functions in such
situations, for example in inline asm that has extra opcodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #5 from Jakub Jelinek ---
It isn't about side-effects. It is about it having pointer type.
If you change your testcase to
uintptr_t psfr_int = (uintptr_t) psfr;
if (! __builtin_constant_p (psfr_int))
then it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769
--- Comment #2 from Tamar Christina ---
I believe this is safe, but the interface is definitely not the cleanest.
vect_recog_absolute_difference has two callers:
1. vect_recog_sad_pattern where if you return true with unprom not set, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650
--- Comment #2 from GCC Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:4d4929fe0654d51b52a2bf6e6188d7aad0bf17ac
commit r14-10036-g4d4929fe0654d51b52a2bf6e6188d7aad0bf17ac
Author: Iain Buclaw
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #4 from Georg-Johann Lay ---
As far as I understand, & SFR has no side effects.
But when it is used as argument to an (inline) function, then it does have side
effects?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
--- Comment #5 from Giuseppe D'Angelo ---
Just to understand, are we talking about an implementation challenge (because
within a class you may refer to stuff not yet declared when parsing the
noexcept spec, or similar), or that using noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #3 from Jakub Jelinek ---
But in that case the POINTER_TYPE_P case doesn't trigger, because it is
INTEGER_CST and
so
/* If we know this is a constant, emit the constant of one. */
if (CONSTANT_CLASS_P (arg)
|| (TREE_CODE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #2 from Georg-Johann Lay ---
Notice that when is used directly in __builtin_constant_p without an
inline function, then the code works as expected:
int main (void)
{
if (__builtin_constant_p (& SFR))
__asm (".warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #33 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #32)
> Ah, but get_alias_set has quite special handling of pointers, it finds the
> ultimately pointed type and uses TYPE_MAIN_VARIANT for it, so it actually
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #32 from Jakub Jelinek ---
Ah, but get_alias_set has quite special handling of pointers, it finds the
ultimately pointed type and uses TYPE_MAIN_VARIANT for it, so it actually
ignores TYPE_CANONICAL of the pointer type itself for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
Bug ID: 114779
Summary: __builtin_constant_p does not work in inline functions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #31 from Jakub Jelinek ---
I've tried to construct a wrong-code testcase, but so far haven't been
successful.
In e.g.
struct S { int s; } s;
struct T { long l; } t;
const struct S *
foo (const struct S **p, const struct T **q)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
--- Comment #4 from rguenther at suse dot de ---
On Fri, 19 Apr 2024, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
>
> --- Comment #3 from Jan Hubicka ---
> > Yes, DSE walking doesn't "branch" but goes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739
--- Comment #8 from Paul Thomas ---
Thanks for the report. Fixed on mainline.
The incorrect errors will have to be fixed on 13-branch at very least.
Unfortunately, this is not a question of using a backport but I will get onto
it right away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
--- Comment #3 from Jan Hubicka ---
> Yes, DSE walking doesn't "branch" but goes to some length handling some
> trivial
> branches only. Mainly to avoid compile-time issues. It needs larger
> re-structuring to fix that, but in principle it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #28 from LIU Hao ---
(In reply to Andrew Pinski from comment #27)
> %zu should be added to ms_printf too.
MSVCRT.DLL from Windows 7 does not support the `z` modifier.
It seems supported on Windows 10; however people really should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103471
--- Comment #10 from Paul Thomas ---
(In reply to Paul Thomas from comment #9)
> > This looks more user friendly.
>
> Also true. I have put it on to regtest but I think that it might be a good
> idea to understand how the symbol evades
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #27 from Andrew Pinski ---
%zu should be added to ms_printf too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #26 from LIU Hao ---
(In reply to Martin Storsjö from comment #25)
> But since the change in c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a (released
> in GCC 12 already), we probably don't need this any longer. So I think it
> might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] Suspicious |[14 Regression] Suspicious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #25 from Martin Storsjö ---
(In reply to Andrew Pinski from comment #23)
> Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be
> fixed to incldue that.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114762
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9f295847a9c32081bdd0fe908ffba58e830a24fb
commit r14-10035-g9f295847a9c32081bdd0fe908ffba58e830a24fb
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114762
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:36f4c8a9ac8f71fc21fcb169c7913e8fef30d15c
commit r14-10034-g36f4c8a9ac8f71fc21fcb169c7913e8fef30d15c
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103471
--- Comment #9 from Paul Thomas ---
> This looks more user friendly.
Also true. I have put it on to regtest but I think that it might be a good idea
to understand how the symbol evades resolution :-)
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103471
--- Comment #8 from Paul Thomas ---
> This looks more user friendly.
Also true. I have put it on to regtest but I think that it might be a good idea
to understand how the symbol evades resolution :-)
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
89 matches
Mail list logo
