https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109561
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #8 from Puneet B ---
could some one provide some pointers here? if its observed in gcc.9.3.0 and
fixed in latest GCC, please point me the same, i will pick and validate quickly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #3 from Richard Biener ---
Created attachment 54886
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54886&action=edit
preprocessed source of the affected TU
it contains the single affected function libkeccak_degeneralise_spec a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109560
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bd4a1a547242a924663712ac7a13799433cdf476
commit r14-106-gbd4a1a547242a924663712ac7a13799433cdf476
Author: Jakub Jelinek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #24 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bd4a1a547242a924663712ac7a13799433cdf476
commit r14-106-gbd4a1a547242a924663712ac7a13799433cdf476
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109560
--- Comment #3 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:3907147aa9bf51ae2bc5d8ddd5bf8d6ddfdf4bf5
commit r12-9449-g3907147aa9bf51ae2bc5d8ddd5bf8d6ddfdf4bf5
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #25 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:3907147aa9bf51ae2bc5d8ddd5bf8d6ddfdf4bf5
commit r12-9449-g3907147aa9bf51ae2bc5d8ddd5bf8d6ddfdf4bf5
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #4 from Richard Biener ---
Created attachment 54887
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54887&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109560
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815
--- Comment #7 from Martin Liška ---
> Many thanks, Martin.
You're welcome!
> PS How do you do this location - by hand or do you have a script to do the
> bisection?
I have a script that uses pre-built GCC binaries:
https://github.com/marxin/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445
--- Comment #2 from jun zhang ---
Created attachment 54888
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54888&action=edit
random unlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #5 from Richard Biener ---
So the failure mode is different than the previous case since there's no
backedge involved at all. Instead all of the VREL_EQ relations we add
are for PHIs like
output_73 = PHI
where we equate the resul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445
--- Comment #3 from Andrew Pinski ---
Yep it was just pure luck that the difference causes the unit growth limit to
hit now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445
--- Comment #4 from jun zhang ---
Created attachment 54889
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54889&action=edit
leela_r.wpa.085i.inline log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
Bug ID: 109565
Summary: -Wstrict-overflow false positive
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
--- Comment #1 from Andrew Pinski ---
I suspect the warning is correct.
In this case it is p < p + size where size is known to be 2 because of the
previous condition.
So there is an assumption for pointer overflow not to happen for p+2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445
--- Comment #5 from jun zhang ---
Created attachment 54890
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54890&action=edit
set param_inline_unit_growth to 41
Hello, Andrew
this patch could work!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
--- Comment #2 from Frank Heckenbach ---
Maybe technically correct, but not useful to the user.
The user's code doesn't involve pointers at all. It makes two queries about a
span object. As the user, I don't even (and shouldn't have to) care wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
Bug ID: 109566
Summary: powerpc: unrecognizable insn for -mcpu=e6500
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #6 from Martin Liška ---
(In reply to Richard Biener from comment #4)
> Created attachment 54887 [details]
> testcase
Note the reduced test-case already started to fail with
r13-1938-g87dd4c8c83768a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
Richard Biener changed:
What|Removed |Added
Attachment #54887|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061
Milan Svoboda changed:
What|Removed |Added
CC||milan.svoboda at centrum dot cz
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #3 from Jonathan Wakely ---
(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, the b.x is not initialized at
> > all. So the question
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Derived is an aggregate since C++17.
Correction, it's an aggregate *only* in C++17. In C++20 the rule changed again
so the user-declared (but not user-provi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #8 from Richard Biener ---
We basically see
if (!have_bitrate) {
state_size = (have_state_size ? state_size : (1600L));
output = ((state_size << 5) / 100L + 7L) & ~0x07L;
bitrate = output << 1;
}
optimized to
if (!have_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #9 from Martin Liška ---
Simplified a bit more to:
struct libkeccak_generalised_spec {
int state_size;
int word_size;
} main_gspec;
long gvar;
int libkeccak_degeneralise_spec(struct libkeccak_generalised_spec *spec) {
int st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
--- Comment #3 from Richard Biener ---
(In reply to Frank Heckenbach from comment #2)
> Since I can't easily upgrade to trunk, I need to know if the warning is
> bogus in 12.2 and I can safely disable it, or do I need to worry about the
> genera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #5 from Jonathan Wakely ---
(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=109564
--- Comment #10 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> I fear something more fundamental is broken here and we
> possibly should play safe and not register any equivalence relation
> from PHIs.
>
> diff --git a/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109567
Bug ID: 109567
Summary: Useless stack adjustment by 16 around calls with odd
stack-argument counts on SysV x86_64
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #12 from Richard Biener ---
Completely scrapping PHI equivalences will cause
FAIL: gcc.dg/pr102648.c scan-tree-dump-not optimized "foo"
FAIL: gcc.dg/pr103359.c scan-tree-dump-not evrp "c = 0"
FAIL: gcc.dg/tree-ssa/evrp-ignore.c scan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #13 from Richard Biener ---
(In reply to Martin Liška from comment #9)
> Simplified a bit more to:
>
> struct libkeccak_generalised_spec {
> int state_size;
> int word_size;
> } main_gspec;
>
> long gvar;
>
> int libkeccak_deg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #7 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #2)
> Note for some x86 cores having 2 or more cmove back to back is worse than a
> conditional jump so maybe the testcase is now catching what it should happen
> ...
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:705b0d2b62318b3935214f08a1cf023b1117acb8
commit r14-108-g705b0d2b62318b3935214f08a1cf023b1117acb8
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061
--- Comment #8 from Milan Svoboda ---
Well, additional workaround is to use -fdata-sections. Then the workaround with
the linker script works also for the templated static functions and for
functions (templated, static) in anonymous namespace (wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568
Bug ID: 109568
Summary: [12/13 Regression] Spurious "potential null pointer
dereference" in shared_ptr_base.h with "-O1"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #14 from Richard Biener ---
I think the issue is a bit more involved - when
_1 = PHI <_2, _3>
and _2 is UNDEFINED _on the edge!_, the equivalence _1 == _3 only holds
when the condition making _2 UNDEFINED holds. Trivially that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568
Richard Biener changed:
What|Removed |Added
Blocks||86172
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
Bug ID: 109569
Summary: warning: ‘void* __builtin_memmove(void*, const void*,
long unsigned int)’ writing 1 or more bytes into a
region of size 0 overflows the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
--- Comment #1 from Frank Heckenbach ---
At least I found a work-around (for now): Moving, rather than copying the
(emtpy) shared_ptr parameter to the (unused) shared_ptr member avoids the
warning.
Still, I'd like to know if this is an actual b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
--- Comment #4 from Jonathan Wakely ---
(In reply to Frank Heckenbach from comment #2)
> Maybe technically correct, but not useful to the user.
Agreed, but you asked for it with that option.
> The user's code doesn't involve pointers at all. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568
--- Comment #2 from Jakub Jelinek ---
Plus, because dynamic_cast((Base*)nullptr) is valid and has to return
(Derived*)nullptr, the emitted code effective has to use
if (var)
var_ref = ...
else
var_ref = nullptr;
if (var_ref->empty ())
and so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
--- Comment #5 from Frank Heckenbach ---
> Agreed, but you asked for it with that option.
Nope, I asked for warnings about signed integer overflow.
> So you shouldn't have to care about begin(c) < end(c) either, it has to be
> true. But you as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109564
--- Comment #15 from Richard Biener ---
Created attachment 54892
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54892&action=edit
patch I am testing
This is the patch I am testing which XFAILs the four testcases. It would be
nice to some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #10 from Jonathan Wakely ---
Ah, it works for C++ because of r12-5108-g80fe172ba98201
With a recent glibc __gthread_cond_timedwait just calls pthread_cond_timedwait
directly, so use correctly redirected to __pthread_cond_timedwait64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the
> weak refs in gthr-posix.h
I think that is indeed the correct fix, as you ori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568
--- Comment #3 from zed.three at gmail dot com ---
Ah, I see what you mean. Putting in a guard clause
if (!var_ref) return false;
does indeed silence the warning.
But should the warning not be on the `var_ref->empty()` call itself then,
in
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
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=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
--- 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 #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 #7 from Jonathan Wakely ---
Probably either PR 105329 or PR 105651
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=105545
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
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=109535
Kito Cheng changed:
What|Removed |Added
Target Milestone|--- |13.2
Summary|internal compiler
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
--- 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=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=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=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=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=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=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=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=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=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=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=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=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=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=109535
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=108248
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=109574
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
Andrew Pinski changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
1 - 100 of 155 matches
Mail list logo
