https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547
Kito Cheng changed:
What|Removed |Added
Summary|RISC-V: Multiple vsetvli|[13] RISC-V: Multiple
|f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547
--- Comment #3 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:d51f2456ee51bd59a79b4725ca0e488c25260bbf
commit r14-129-gd51f2456ee51bd59a79b4725ca0e488c25260bbf
Author: Juzhe-Zhong
Date: Fri Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109572
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #20 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f980561c60b0446cc427595198d7f3f4f90e0924
commit r13-7231-gf980561c60b0446cc427595198d7f3f4f90e0924
Author: Andrew MacLeod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109571
--- Comment #3 from Frank Heckenbach ---
Thanks for the explanation, that was really helpful.
If I understand it correctly, since B has a vtable and A doesn't, upcasting
means to add some offset to the pointer, but of course not if it's null. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108812
--- Comment #2 from CVS Commits ---
The releases/gcc-12 branch has been updated by HaoChen Gui
:
https://gcc.gnu.org/g:a8f45d61caba90649b3f264babab17353d774751
commit r12-9460-ga8f45d61caba90649b3f264babab17353d774751
Author: Haochen Gui
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
--- Comment #14 from JuzheZhong ---
(In reply to Mathieu Malaterre from comment #12)
> @JuzheZhong
>
> Technically you are supposed to simply remove the keyword '14' from the
> title and close when backported on 13...
Thank you for correcting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581
--- Comment #3 from Daniel Schürmann ---
I can confirm that -fno-finite-math-only fixes the issue.
Since this a new behavior in GCC 13 and it is also a hard to find issue, which
took us many hours to dig it down, it would be nice tho have at l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #4 from Jeffrey A. Law ---
Vineet, we've got some bits here you might want to play with. I'm about to
leave for the evening, but I'll put you in touch with Raphael tomorrow
afternoon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #3 from Vineet Gupta ---
Debugging of ctz3 case
The insns of interest are:
insn_cost 4 for 6: r74:SI=ctz(r73:DI#0)
REG_DEAD r73:DI
insn_cost 4 for 7: r72:DI=sign_extend(r74:SI)
REG_DEAD r74:SI
Before the commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
--- Comment #5 from Andrew Pinski ---
(In reply to Alex Wang from comment #4)
> Just realized my previous searches were only searching the summary.
>
> Is this bug a duplicate of either
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96716 and/o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
--- Comment #4 from Alex Wang ---
Just realized my previous searches were only searching the summary.
Is this bug a duplicate of either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96716 and/or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
JuzheZhong changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581
--- Comment #2 from Andrew Pinski ---
>From evrp:
Folding predicate inf.2_3 <
-1.79769313486231570814527423731704356798070567525844996599e+308 to 0
Removing basic block 3
Merging blocks 2 and 4
Because there is nothing smaller than that with -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109581
Bug ID: 109581
Summary: Comparing with -HUGE_VAL wrong result
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
--- Comment #6 from Andrew Pinski ---
Yes it should mention overflow on pointers.
Anyways also see
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fwrapv-pointer
and right below that with fstrict-overflow .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109580
Bug ID: 109580
Summary: #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is
ineffective
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Anyways maybe the issue with PR 29968 was a scheduling issue which was fixed
> later on that GCC didn't realize divide could trap.
I was right on that, it was a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
--- Comment #4 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #3)
> Anyways maybe the issue with PR 29968 was a scheduling issue which was fixed
> later on that GCC didn't realize divide could trap.
OK, thanks, I can see your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41239
Andrew Pinski changed:
What|Removed |Added
CC||tiamat at komi dot mts.ru
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #6 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968
--- Comment #5 from Andrew Pinski ---
(In reply to Vincent Lefèvre from comment #4)
> (In reply to Andreas Schwab from comment #2)
> > Your program is invoking undefined behaviour. You should not perform the
> > division if the divisor is zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
--- Comment #3 from Andrew Pinski ---
(In reply to Vincent Lefèvre from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > We don't removing code before undefined behavior ...
> > That is GCC does not know that printf does not have s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
--- Comment #2 from David Malcolm ---
Thanks for filing this bug.
I think -fanalyzer should warn about fclose(NULL), but not for free(NULL).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109567
--- Comment #1 from Andrew Pinski ---
Compiling with -fno-omit-frame-pointer shows what is happening really.
It is reserving space for the frame pointer on the stack. I am not 100% sure
but I think that is required even if the frame pointer is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
--- Comment #2 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #1)
> We don't removing code before undefined behavior ...
> That is GCC does not know that printf does not have side effects.
Then GCC is incorrect in bug 29968,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109579
Bug ID: 109579
Summary: -Wanalyzer-out-of-bounds false positive in Emacs
mapping stack
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568
Andrew Pinski changed:
What|Removed |Added
Summary|[12/13/14 Regression] |Spurious "potential null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578
Bug ID: 109578
Summary: fail to remove dead code due to division by zero
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
Georg-Johann Lay changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #15 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577
Bug ID: 109577
Summary: -Wanalyzer-allocation-size mishandles
__builtin_mul_overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.7.1, 5.1.0
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
Andrew Pinski changed:
What|Removed |Added
Summary|Incorrect rejection of |access checking done on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2023-04-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109576
Bug ID: 109576
Summary: Incorrect rejection of constexpr local var due to
private member even with visible conversion operator
Product: gcc
Version: 12.2.0
Status: UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109571
--- Comment #2 from Andrew Pinski ---
You get the same warning with:
struct A
{
int i = 0;
};
struct B: A
{
virtual ~B ();
};
int f(B *tmp)
{
A *a = tmp;
return a->i;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109571
Andrew Pinski changed:
What|Removed |Added
Component|c++ |tree-optimization
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
Bug ID: 109575
Summary: Implement runtime check for valid function result
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #8 from Andrew Pinski ---
(In reply to Pablo Anigstein from comment #7)
> Here is an updated example: https://godbolt.org/z/YePjhxKE4.
I don't see an updated example, all I see is an URL ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #7 from Pablo Anigstein ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Jonathan Wakely from comment #3)
> > (In reply to Pablo Anigstein from comment #2)
> > > (In reply to Andrew Pinski from comment #1)
> > > > Hmm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #6 from Pablo Anigstein ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Pablo Anigstein from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Hmm,
> > > I noticed that since GCC 7 with -std=c++17, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #21 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #19)
> PS: I think what you want to with a runtime check and an undefine
> function result is a good idea. I haven't looked to see where
> and how hard this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #20 from anlauf at gcc dot gnu.org ---
Created attachment 54894
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54894&action=edit
Extended testcase
Testcase for Steve's variant of the diagnostic, checking that we also catch
proc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
Andrew Pinski changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109574
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109574
Bug ID: 109574
Summary: RISC-V: gcc.dg/pr90838.c failing due to extra ANDI 127
on releases/gcc-13
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #19 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:17aa9ddb34581855dd013745c8be27dda024de4a
commit r14-122-g17aa9ddb34581855dd013745c8be27dda024de4a
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #22 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:87c9bae4e32b54829dce0a93ff735412d5f684f8
commit r14-121-g87c9bae4e32b54829dce0a93ff735412d5f684f8
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107041
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3d7ab53d6c59499624aa41c8dea0664976820b3b
commit r14-120-g3d7ab53d6c59499624aa41c8dea0664976820b3b
Author: Jakub Jelinek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573
Bug ID: 109573
Summary: [12/13/14 regression] ICE in
vectorizable_live_operation, at tree-vect-loop.cc:9060
when building chromium's maglev-assembler-x64.cc with
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #25 from Jonathan Wakely ---
... and non-empty types, I'm just saying that's the obvious case that proves
it's possible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #24 from Jonathan Wakely ---
(In reply to Arthur O'Dwyer from comment #23)
> - There may be padding in the middle of an object, and I'm not confident
> that the Standard actually forbids it from being used. Of course your
> approach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338
--- Comment #14 from Patrick O'Neill ---
I picked this back up, v7 is here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616080.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
--- Comment #13 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #9)
> The _M_num_put cache exists to avoid doing the RTTI check implied by
> use_facet every time we use the stream. But that RTTI check has been removed
> for GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #19 from Steve Kargl ---
On Thu, Apr 20, 2023 at 05:22:59AM +, kargl at gcc dot gnu.org wrote:
>
> I think we agree on all points. Here's the diff I envision.
> NOte, I've restricted it to user defined functions. Remove
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #18 from Andrew Macleod ---
(In reply to Richard Biener from comment #16)
> (In reply to Richard Biener from comment #15)
> > Created attachment 54892 [details]
> > patch I am testing
>
> Bootstrapped and tested on x86_64-unknown-li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109572
Bug ID: 109572
Summary: new test case gcc.dg/vect/pr109011-4.c from
r14-108-g705b0d2b62318b fails
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
--- Comment #12 from Mathieu Malaterre ---
@JuzheZhong
Technically you are supposed to simply remove the keyword '14' from the title
and close when backported on 13...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952
--- Comment #10 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:272484dae6b5264baa0f41eba80a9521e9b7ecf5
commit r14-117-g272484dae6b5264baa0f41eba80a9521e9b7ecf5
Author: Uros Bizjak
Date: Thu Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108247
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:07e2576d6f344acab338deeb051845c90c1cf6a3
commit r14-116-g07e2576d6f344acab338deeb051845c90c1cf6a3
Author: Raphael Zinsly
Date: Thu Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #17 from Andrew Macleod ---
Created attachment 54893
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54893&action=edit
new patch
Alternatively, we can simply allow undefined SSA_NAMES to also be checked or
single arguments like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #12 from Puneet B ---
Thanks for update , since we are using gcc-2.34 , this need to picked as fix.
but do you seen any side impact of this fix which need to be validated?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #23 from Arthur O'Dwyer ---
(In reply to Jonathan Wakely from comment #22)
>
> Richi suggested that we could avoid these runtime branches (which hurt
> optimization, see PR 109445) if we knew how many bytes of tail padding there
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
--- Comment #13 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:2e4210698c644e44f9e0645dc7bc49710fd60ce8
commit r12-9457-g2e4210698c644e44f9e0645dc7bc49710fd60ce8
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
--- Comment #17 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:2e4210698c644e44f9e0645dc7bc49710fd60ce8
commit r12-9457-g2e4210698c644e44f9e0645dc7bc49710fd60ce8
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
--- Comment #31 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:e016a6ddbf0038056b9d8f2bc0bad350ff026632
commit r12-9456-ge016a6ddbf0038056b9d8f2bc0bad350ff026632
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
--- Comment #9 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:2e4210698c644e44f9e0645dc7bc49710fd60ce8
commit r12-9457-g2e4210698c644e44f9e0645dc7bc49710fd60ce8
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
--- Comment #12 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:24cf9f4c6f45f7d8b37757cdb34576ee5d2d40e1
commit r12-9454-g24cf9f4c6f45f7d8b37757cdb34576ee5d2d40e1
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #22 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> const ptrdiff_t _Num = __last - __first;
> - if (_Num)
> + if (__builtin_expect(_Num > 1, true))
> __builtin_memmove(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109571
Bug ID: 109571
Summary: potential null pointer dereference
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
--- Comment #1 from Ivan Sorokin ---
Generalizing. Perhaps similarly free(NULL) can be detected?
void* obj = malloc(...);
if (!obj)
{
free(obj);
return false;
}
Unliky fclose(NULL), free(NULL) is completely well defined operation, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
Bug ID: 109570
Summary: detect fclose on unopened or NULL files
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568
--- Comment #5 from zed.three at gmail dot com ---
Ah ok, I see the whole thing now. It still feels like a confusing warning, but
it seems reasonable that there isn't much that can be done about it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
--- Comment #10 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:a2d12abedc89a9439fd6aadc38730fdadca0684f
commit r14-113-ga2d12abedc89a9439fd6aadc38730fdadca0684f
Author: Ju-Zhe Zhong
Date: Wed A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546
Martin Liška changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
Kito Cheng changed:
What|Removed |Added
Target Milestone|--- |13.2
Summary|internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651
Jonathan Wakely changed:
What|Removed |Added
CC||jvb at cyberscience dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #16 from Richard Biener ---
(In reply to Richard Biener from comment #15)
> Created attachment 54892 [details]
> patch I am testing
Bootstrapped and tested on x86_64-unknown-linux-gnu, the XFAILs of
gcc.dg/pr102648.c and gcc.dg/pr10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
--- Comment #7 from Jonathan Wakely ---
Probably either PR 105329 or PR 105651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
--- Comment #6 from Frank Heckenbach ---
(In reply to Frank Heckenbach from comment #4)
> Thanks.
>
> I just got another similar one, this time with string.insert. But I guess
> it's pointless to dissect this one, or do you need more examples f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
--- Comment #5 from Jonathan Wakely ---
So it's a dup of one of these:
PR libstdc++/107852
PR libstdc++/106199
PR libstdc++/100366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
--- Comment #4 from Frank Heckenbach ---
Thanks.
I just got another similar one, this time with string.insert. But I guess it's
pointless to dissect this one, or do you need more examples for your test
suite?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
Jonathan Wakely changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #3 from Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568
--- Comment #4 from Jakub Jelinek ---
(In reply to zed.three from comment #3)
> But should the warning not be on the `var_ref->empty()` call itself then,
> instead of inside `shared_ptr::operator==`? I guess that it's ultimately
> triggered by t
1 - 100 of 155 matches
Mail list logo
