https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106716
--- Comment #3 from Andrew Pinski ---
[[unlikely]]/[[likely]] attribute gets expanded into
PREDICT_EXPR:PRED_HOT_LABEL/PRED_COLD_LABEL:TAKEN/NOT_TAKEN see
cp/cp-gimplify.cc (process_stmt_hotness_attribute) and is removed.
And that is all done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106716
--- Comment #2 from Tomer Vromen ---
IMO, attribute information should be checked in this optimization stage, so
that ipa-icf knows the functions are different. It seems like maybe this is
already partially the behavior - removing the attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099
--- Comment #11 from Zdenek Sojka ---
And with another degenerate flags on the testcase above:
# x86_64-pc-linux-gnu-gcc -O -fno-tree-forwprop -fno-tree-dominator-opts
-fharden-conditional-branches -funreachable-traps -fno-tree-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106717
Bug ID: 106717
Summary: [13 Regression] ICE: tree check: expected integer_cst,
have poly_int_cst in get_len, at tree.h:6247
Product: gcc
Version: 13.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Summary|fixincludes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106707
--- Comment #4 from Xionghu Luo (luoxhu at gcc dot gnu.org) ---
Maybe guard the pattern with...
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 58fcc382fa2..2a9d70da6d0 100644
--- a/gcc/config/i386/i386.md
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 106687, which changed state.
Bug 106687 Summary: [13 Regression] Wrong code with -O2 since
r13-438-gcf2141a0c640fc9b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:de6d9e0b3d5c08896cbf047b299fc7f8d1e42be7
commit r13-2147-gde6d9e0b3d5c08896cbf047b299fc7f8d1e42be7
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106716
--- Comment #1 from Andrew Pinski ---
I suspect fipa-icf does not compare the branch predication data while doing the
comparison. I don't know if this is the right thing to do or not. Because if
there was exact data from profiling feedback then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106716
Bug ID: 106716
Summary: Identical Code Folding (-fipa-icf) confuses between
functions with different [[likely]] attributes
Product: gcc
Version: 12.1.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106695
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:5abe0657553580bd1b7488dd84d55138a8d9f23c
commit r13-2144-g5abe0657553580bd1b7488dd84d55138a8d9f23c
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cc4fa7a210b638d6a46f14dab17f2361389d18e1
commit r13-2145-gcc4fa7a210b638d6a46f14dab17f2361389d18e1
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106607
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:1b09eea33f2bf9d1eae73b25cc25efb05ea1dc3f
commit r13-2143-g1b09eea33f2bf9d1eae73b25cc25efb05ea1dc3f
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100948
--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to José Rui Faustino de Sousa from comment #6)
> Created attachment 51002 [details]
> Patch and changelog
I took a look at the attached patch.
While it does resolve the ICE on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106564
Dimitar Dimitrov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106564
--- Comment #1 from CVS Commits ---
The master branch has been updated by Dimitar Dimitrov :
https://gcc.gnu.org/g:10dd6dea95c5fc41c789c6506338e101e0590a02
commit r13-2140-g10dd6dea95c5fc41c789c6506338e101e0590a02
Author: Dimitar Dimitrov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
--- Comment #4 from Peter Bergner ---
(In reply to Kewen Lin from comment #2)
> Confirmed, this is a test issue, power10 and up specific.
>
> The difference comes from the function thud, it aims to test the pattern
> works for vector type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106557
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106557
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:7e51df048ae849115e12bf12702bdf1b65893be7
commit r13-2139-g7e51df048ae849115e12bf12702bdf1b65893be7
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713
--- Comment #2 from Arsen Arsenović ---
Created attachment 53491
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53491=edit
Reduced test case
Alright, managed to get a reduced test case out of C-Vise. Though, this doesn't
build on clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106715
Tobias Burnus changed:
What|Removed |Added
Summary|[OpenMP][5.2] Permit|[OpenMP][5.2] Permit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106715
--- Comment #1 from Jakub Jelinek ---
It is not just internally, it is what the standard says.
So, ordered is closely nested in simd, but not closely nested in
worksharing-loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106715
Bug ID: 106715
Summary: [OpenMP][5.2] Permit 'order' clause with 'for
simd'/'do simd' + improve error message
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106714
Bug ID: 106714
Summary: Incorrect casts macros in amxtileintrin.h
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106662
--- Comment #1 from Tobias Burnus ---
"Likewise with a combined construct:" – Strike that I think that's not quite
right.
Seems that one expert on omp-lang believes that for this "worksharing-simd
construct and firstprivate" example in comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103370
--- Comment #8 from Joseph S. Myers ---
This build failure has come back on GCC mainline, some time between commit
3cab897a67af120aa18efa7ddd7ee49b9a29e5dd and
7f5ec900e53f6c7f7c06c641b4fb303ebdc83785.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106712
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106709
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106709
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713
--- Comment #1 from Arsen Arsenović ---
Created attachment 53490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53490=edit
Preprocessed test (gz-compressed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106599
--- Comment #5 from Jonathan Wakely ---
This delegating constructor example seems like a third case of
https://wg21.link/cwg2403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713
Bug ID: 106713
Summary: Coroutine regression in GCC 11.3.0: if (co_await ...)
crashes with a jump to ud2
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106599
--- Comment #4 from Fedor Chelnokov ---
And if one deletes copy constructor of A:
struct A {
constexpr A() = default;
constexpr A(const A&) = delete;
constexpr A(int) : A(A()) {}
};
A a(2);
Then Clang rejects the program,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106711
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629
Mathieu Malaterre changed:
What|Removed |Added
Known to fail||12.1.0
--- Comment #21 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #17 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #16)
> (In reply to Segher Boessenkool from comment #15)
> > (In reply to Andreas Krebbel from comment #14)
> > > > So you are suggesting that every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #16 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #15)
> (In reply to Andreas Krebbel from comment #14)
> > > So you are suggesting that every strict_low_part after reload can just be
> > > removed? If that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #16 from Jakub Jelinek ---
(In reply to Tobias Burnus from comment #15)
> Besides the post-commit comment by Thomas (last comment before mine; comment
> 14),
> there is another issue:
> The commit causes for SPEC HPC2021's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #15 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #14)
> > So you are suggesting that every strict_low_part after reload can just be
> > removed? If that is true, should we not just do exactly that then?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #15 from Tobias Burnus ---
Besides the post-commit comment by Thomas (last comment before mine; comment
14),
there is another issue:
The commit causes for SPEC HPC2021's 521.miniswp_t (OpenMP) 400% slowdown.
The question is whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106712
--- Comment #1 from Ed Catmur ---
I believe this is happening because start_decl can modify prefix_attributes (by
first chaining it onto attributes, then passing the merged chain to
grokdeclarator which can then chain onto that merged chain).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106712
Bug ID: 106712
Summary: Incorrect propagation of C++11 attributes to
subsequent function declarations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106700
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106700
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:827f64135957ce21617cd0345508077439fa29d8
commit r13-2137-g827f64135957ce21617cd0345508077439fa29d8
Author: Martin Liska
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106607
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106599
--- Comment #3 from Jonathan Wakely ---
(In reply to Fedor Chelnokov from comment #0)
> So we need to consider the constructors, and select A(const A&) : v(1)
We do select that, but then for C++17 (and later) the copy is elided, which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106711
Bug ID: 106711
Summary: Incorrect format overflow warning with previously
checked strings
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674
--- Comment #9 from Richard Biener ---
uninit analysis has the guarding condition r_14(D) <= 18 but the guard of
the PHI is computed in non-optimal way since this is a PHI use of a PHI
with an uninitialized val on an edge but the paths we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106710
Bug ID: 106710
Summary: Ability to disable -Wfree-nonheap-object for specific
free() implementations
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106709
Bug ID: 106709
Summary: GCC incorrectly warns about stringop-overread
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106622
--- Comment #2 from Jonathan Wakely ---
Also please check whether this is a duplicate of Bug 104435, Bug 105115, Bug
106224, or Bug 106641.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105115
--- Comment #3 from Jonathan Wakely ---
Maybe a dup of PR 104435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106622
--- Comment #1 from Jonathan Wakely ---
Please provide a more useful title than "Bug report". Everything in bugzilla is
a bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106631
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-08-22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106629
--- Comment #5 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #4)
> Even though cppreference is not part of the C++ standard. It would be useful
> to put a reference to that defect report on
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106695
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=106695
--- Comment #2 from Jonathan Wakely ---
Probably r11-2736-gbb1b7f087bdd02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106614
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106599
Jonathan Wakely changed:
What|Removed |Added
CC||jlame646 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78717
--- Comment #4 from Jonathan Wakely ---
This is because the std::basic_string::find function isn't marked 'inline' and
there is an explicit instantiation declaration for std::string. GCC simply
won't inline a non-inline function if there's an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82113
--- Comment #2 from Jonathan Wakely ---
c.f. https://wg21.link/cwg2403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90413
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106176
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106176
Jonathan Wakely changed:
What|Removed |Added
CC||accelerator0099 at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106584
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106659
Martin Liška changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80858
Jonathan Wakely changed:
What|Removed |Added
CC||accelerator0099 at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106584
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106696
--- Comment #5 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #3)
> Because of the C++ vs. C differences, -Wreturn-type warning is on by default
> in C++ while it is only included in -Wall for C, users just shouldn't ignore
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #14 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #13)
> (Sorry I missed this)
>
> (In reply to Andreas Krebbel from comment #11)
> > I've tried to change our movstrict backend patterns to use a predicate on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
--- Comment #19 from Jonathan Wakely ---
I suppose the libstdc++ header could do something like:
#pragma GCC diagnostic push
#if defined __SANITIZE_ADDRESS__ && defined __OPTIMIZE__
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
#endif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164
--- Comment #14 from Jonathan Wakely ---
Running out of stack space is not acceptable, that's why this is considered a
bug. As already stated in comment 8, I started work on fixing it, but the
rewritten code had bugs that I haven't had time to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106672
--- Comment #1 from Jonathan Wakely ---
The macro seems appropriate for old code relying on a deprecated feature. I
don't think GCC should support this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
--- Comment #8 from Jayesh Badwaik ---
> Oh and you don't need the tr either that is any whitespace in a response
> file is will be treated as a seperator.
> So just:
> g++ -Q --help=warnings | tail -n +2 | awk '{print $1}' > cxxflags.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
Paweł Bylica changed:
What|Removed |Added
CC||chfast at gmail dot com
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106646
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-08-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
--- Comment #11 from Martin Liška ---
> Ah, indeed. That still leaves the question whether we execute the
> WPA stage with the FDs open - I suppose you checked?
Yes, I can confirm it correctly works on Linux with FDs provided by jobserver.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106708
Bug ID: 106708
Summary: [rs6000] 64bit constant generation with oris xoris
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
Bug 98940 depends on bug 106645, which changed state.
Bug 106645 Summary: [C++23] P2290R3 - Delimited escape sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106645
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106645
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106686
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106707
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106686
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:e228683b244c6afbe3bdfef7ba607fbda813bd0f
commit r13-2135-ge228683b244c6afbe3bdfef7ba607fbda813bd0f
Author: Tobias Burnus
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106695
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
--- Comment #18 from Richard Biener ---
(In reply to Sven Hesse from comment #17)
> I still get this with gcc 12.2.0 (Gentoo 12.2.0 p9), but only when compiling
> with (at least with) -O1 -fsanitize=address, in addition to any warning flag
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106675
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704
--- Comment #8 from Hongtao.liu ---
_5 = VIEW_CONVERT_EXPR(mask_4(D));
_6 = _5 < { 0, 0, 0, 0, 0, 0, 0, 0 };
_7 = VEC_COND_EXPR <_6, b_3(D), a_2(D)>;
It's lowered ly veclower since vcondv8sfv8si and vec_cmpv8si is define under
AVX2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704
--- Comment #7 from Hongtao.liu ---
(In reply to Richard Biener from comment #3)
> get_vcond_icode (vmode=E_V8SFmode, cmode=E_V8SImode, uns=false) at
> /home/rguenther/src/trunk/gcc/optabs-query.h:117
>
> gets us CODE_FOR_nothing though,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106702
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106707
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704
--- Comment #5 from rguenther at suse dot de ---
On Mon, 22 Aug 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704
>
> --- Comment #4 from Jakub Jelinek ---
> So perhaps the
1 - 100 of 117 matches
Mail list logo
