https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
Bug ID: 89725
Summary: ICE in get_fnname_from_decl, at varasm.c:1723
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89713
--- Comment #3 from Feng Xue ---
Yes, people seldom write an empty loop in real application. These loops are
always by-products of some loop optimizations, such as loop unswitch and loop
split etc. Pragma does be a means to pass loop information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89713
--- Comment #2 from Feng Xue ---
Yes, people seldom write an empty loop in real application. These loops are
always by-products of some loop optimizations, such as loop unswitch and loop
split etc. Pragma does be a means to pass loop information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85014
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Paolo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85014
--- Comment #5 from Paolo Carlini ---
Looking into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89685
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722
--- Comment #5 from Jonathan Wakely ---
-Wignored-qualifiers (C and C++ only)
Warn if the return type of a function has a type qualifier such as "const".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722
--- Comment #4 from Xavier ---
Arf I did not understand this was a const problem. Maybe the warning could be a
bit clearer ? :)
I confirm that it works fine with typeof(*(bits) + 0).
This code is in a header shared between C and C++, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722
--- Comment #3 from Jonathan Wakely ---
(In reply to Xavier from comment #0)
> This does not seem to occur with gcc, nor with g++ <= 7.
I implemented the warning for GCC 8.
> I could not find a workaround.
Stop using macros?
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89724
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89724
Bug ID: 89724
Summary: Fortran diagnostics give wrong line number because of
math-vector-fortran.h header file
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89723
Bug ID: 89723
Summary: Bogus maybe-uninitialized warning with -Og
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #7 from joseph at codesourcery dot com ---
The relation definitely is not transitive (so you can't declare the same
function to return two different enum types, for example).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84394
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89650
--- Comment #4 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Mar 14 20:38:52 2019
New Revision: 269694
URL: https://gcc.gnu.org/viewcvs?rev=269694=gcc=rev
Log:
i386: Handle REG_EH_REGION note
When we split:
(insn 18 17 76 2 (set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722
--- Comment #2 from Andrew Pinski ---
typeof(*(bits))
Try using decltype instead; typeof is a GNU extension.
or use:
typeof(*(bits) + 0)
Which will remove the const part.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722
Bug ID: 89722
Summary: [8/9 regression] strange warning: type qualifiers
ignored on cast result type [-Wignored-qualifiers]
Product: gcc
Version: 8.3.1
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89715
--- Comment #2 from Segher Boessenkool ---
Yeah it looks like that a lot, thanks. Let's wait with marking it as
dup until we know for sure though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #6 from Alexander Monakov ---
... and even considering that the standard never actually says that "compatible
type" relation is transitive, and so two enums technically need not be
compatible with each other, the following should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
Eric Gallager changed:
What|Removed |Added
CC||federico.kircheis at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89718
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
Bug ID: 89721
Summary: __builtin_mffs sometimes optimized away
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573
--- Comment #6 from joseph at codesourcery dot com ---
On Thu, 14 Mar 2019, rguenther at suse dot de wrote:
> I see. This means the different cases in the testcase in question are
> not equivalent (when excess precision is involved) and thus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89719
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89719
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720
Bug ID: 89720
Summary: [9 Regression] Spurious -Warray-bounds warning
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #4 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89719
Bug ID: 89719
Summary: [9 regression] gcc.target/aarch64/spellcheck_[456].c
testsuite failures
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89715
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89718
--- Comment #4 from Federico Kircheis ---
(In reply to Jakub Jelinek from comment #2)
> The tokens on which you expect the warning come from an area of the code
> that is not in between the pragmas, so the gcc behavior looks good to me
> here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89718
--- Comment #3 from Andrew Pinski ---
I think this is a dup of bug 55578.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89718
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525
--- Comment #25 from Martin Jambor ---
My work is done here. I'm not sure if it means that we can close this, given
that the underlying problem is not "really fixed(TM)."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89718
--- Comment #1 from Federico Kircheis ---
I've missed a line while copy-pasting the test program, there was a missing ')'
at the end:
#define DIAGNOSTIC_HELPER0(x) #x
#define DIAGNOSTIC_HELPER1(kind, y) DIAGNOSTIC_HELPER0(GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525
--- Comment #24 from Martin Jambor ---
Author: jamborm
Date: Thu Mar 14 16:54:43 2019
New Revision: 269688
URL: https://gcc.gnu.org/viewcvs?rev=269688=gcc=rev
Log:
Zero local estimated benefit for cloning extern inline function
2019-03-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89718
Bug ID: 89718
Summary: _Pragma GCC diagnostic ignored inside macro
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525
--- Comment #23 from Martin Jambor ---
Author: jamborm
Date: Thu Mar 14 16:50:50 2019
New Revision: 269687
URL: https://gcc.gnu.org/viewcvs?rev=269687=gcc=rev
Log:
Zero local estimated benefit for cloning extern inline function
2019-03-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89591
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69724
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #3 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69724
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89716
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89716
--- Comment #3 from Andreas Schwab ---
Why do you think that long unsigned int should be 32 bit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89716
--- Comment #2 from Martin Sander ---
(In reply to Andreas Schwab from comment #1)
> Why do you think that __uint64_t is not long unsigned int?
Because it is supposed to be long long unsigned int - with two times "long" -
while long unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89717
Bug ID: 89717
Summary: Test case gcc.dg/uninit-pred-8_b.c fails after r269650
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89716
--- Comment #1 from Andreas Schwab ---
Why do you think that __uint64_t is not long unsigned int?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #5 from Alexander Monakov ---
C11 6.7.2.2 p4 says,
Each enumerated type shall be compatible with char, a signed integer type, or
an unsigned integer type [...]
and 6.5 p7 says,
An object shall have its stored value accessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89716
Bug ID: 89716
Summary: Bogus warning -Wformat= in printf with __uint64_t
argument
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89591
--- Comment #2 from Alexandre Bique ---
> It's initialized here:
>
>> id() noexcept : _M_thread() { }
I did not know that it would initialize it to 0.
In that case let's hope that pthread_t == "value-initialized" will never
happen.
Thank you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89245
--- Comment #1 from Dragan Mladjenovic ---
The issue seems to be that jump pass tail merges two blocks ending in indirect
calls to mit_tsi.isra.2 and emit_branch.isra.5 ignoring the REG_CALL_DECL
notes attached to them which messes up the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761
--- Comment #16 from Jeffrey A. Law ---
Yea, just not enough time to push through the regression I've seen.
At this point addressing fix-r4000-10.c looks like getting the DF/REG_NOTES
consistent within the regcprop pass. Once that's in place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79704
Bug 79704 depends on bug 89275, which changed state.
Bug 89275 Summary: [9 Regression] Slowdown in mcperf on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89275
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89275
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #16 from Martin Liška ---
Andrey: Can you please send a patch for it into gcc-patches mailing list?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89711
--- Comment #7 from Martin Liška ---
(In reply to Richard Biener from comment #4)
> Ah, the target:
>
> /* Build result decl and add to function_decl. */
> t = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE, ptr_type_node);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89715
Bug ID: 89715
Summary: ICE deep in C++ frontend building g++.dg/cpp0x/cond1.C
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89692
--- Comment #3 from Jan Hubicka ---
So I assume that SRA takes the type from somewhere which is not visited by
free_lang_data?
I saw similar problem with lists of type variants (i.e. if you try to build a
variant type you may get one that was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85821
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85821
--- Comment #2 from Jonathan Wakely ---
Created attachment 45967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45967=edit
Implement standard-conforming signatures when GNU extensions are disabled
This patch would fix your testcase, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075
--- Comment #6 from Charles ---
This appears to have been fixed for at least 8.3. Mikhail's reduced version
compiles without error for both c++14 and 17. Note that I added the -c flag.
cfrasch@cff-ultra:~/gcc_bug_69075$ g++ -std=c++14 -flto -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89704
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
--- Comment #11 from Richard Biener ---
Btw, it is exactly the current pessimization of vector construction that makes
the AVX256 variant not profitable:
0x40e04e0 *co_99(D)[_53] 1 times vec_construct costs 112 in body
that's because we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89712
Martin Liška changed:
What|Removed |Added
Known to work||8.3.1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89712
--- Comment #4 from Martin Liška ---
Author: marxin
Date: Thu Mar 14 14:19:33 2019
New Revision: 269684
URL: https://gcc.gnu.org/viewcvs?rev=269684=gcc=rev
Log:
Remove dead option from manual (PR other/89712).
2019-03-14 Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86023
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89712
--- Comment #3 from Martin Liška ---
(In reply to Martin Liška from comment #2)
> @Maxim: I see -fdump-class-hierarchy[-n] mentioned in PDF manual. Where do
> you see -fdump-class-hierarchy mentioned in GCC 8.x documentation?
Sorry, I wanted to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89712
--- Comment #2 from Martin Liška ---
@Maxim: I see -fdump-class-hierarchy[-n] mentioned in PDF manual. Where do you
see -fdump-class-hierarchy mentioned in GCC 8.x documentation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89711
Richard Biener changed:
What|Removed |Added
Known to work||9.0
Summary|[8/9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2016-01-19 00:00:00 |2019-3-14
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89711
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Thu Mar 14 14:05:26 2019
New Revision: 269683
URL: https://gcc.gnu.org/viewcvs?rev=269683=gcc=rev
Log:
2019-03-14 Richard Biener
PR target/89711
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
--- Comment #10 from Richard Biener ---
(In reply to Michael Matz from comment #9)
> (In reply to Richard Biener from comment #8)
> >
> > I'm out of ideas suitable for GCC 9 (besides reverting the patch, reverting
> > to bogus state).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89591
--- Comment #1 from Jonathan Wakely ---
(In reply to Alexandre Bique from comment #0)
> Hi,
>
> I've been reading the header and I've found that the thread id of
> std::thread is not initialized, I hope that I'm wrong and I missed something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89712
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89710
Richard Biener changed:
What|Removed |Added
Known to work||9.0
Summary|[7/8/9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89378
--- Comment #4 from Paul Hua ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 45960 [details]
> gcc9-pr89378.patch
>
> Untested (quite obvious) fix, though I don't really have a way to test this.
> If you could test this, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #9 from Martin Jambor ---
I have proposed the patch on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00708.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714
Bug ID: 89714
Summary: allow for overriding the thread-detection mechanism
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89684
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Thu Mar 14 13:05:34 2019
New Revision: 269681
URL: https://gcc.gnu.org/viewcvs?rev=269681=gcc=rev
Log:
PR ipa/89684
* multiple_target.c (create_dispatcher_calls): Change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #4 from Richard Biener ---
Note I can't find any bit in the C standard that would make the testcase
well-defined and support reporters view. My clang version doesn't "miscompile"
it though.
With LTO we'd treat both enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89679
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89679
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Thu Mar 14 12:21:36 2019
New Revision: 269680
URL: https://gcc.gnu.org/viewcvs?rev=269680=gcc=rev
Log:
PR rtl-optimization/89679
* expmed.c (expand_mult_const): Don't add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89700
--- Comment #5 from Jonathan Wakely ---
No, because that would mean almost every class written for C++03 would fail to
compile in C++11 or later, which would be absurd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805
Florian Weimer changed:
What|Removed |Added
Status|NEW |WAITING
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89704
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89710
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Thu Mar 14 11:07:41 2019
New Revision: 269679
URL: https://gcc.gnu.org/viewcvs?rev=269679=gcc=rev
Log:
2019-03-14 Richard Biener
PR tree-optimization/89710
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89711
--- Comment #4 from Richard Biener ---
Ah, the target:
/* Build result decl and add to function_decl. */
t = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE, ptr_type_node);
DECL_ARTIFICIAL (t) = 1;
DECL_IGNORED_P (t) = 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89711
--- Comment #3 from Richard Biener ---
The issue is that the same DECL_RESULT is used for xd.resolver and tx.resolver.
Maybe they are commoned by IPA ICF? But the function decls still are
different...
tx.resolver/6 (tx.resolver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89709
--- Comment #2 from Jakub Jelinek ---
Created attachment 45965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45965=edit
gcc9-pr89709.patch
Untested fix. The above mentioned revision added STRIP_ANY_LOCATION_WRAPPERS
to the beginning of
1 - 100 of 136 matches
Mail list logo
