https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #3 from jojo ---
Haha..., get_address_cost() will cost down some address which is not my
expected, you
can get that code from my the 1st comment, i can not understand why adding that
code
in new version :(
(In reply to Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90240
--- Comment #8 from bin cheng ---
Patch proposed at:
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg01101.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
Jan van Dijk changed:
What|Removed |Added
CC||j.v.dijk at tue dot nl
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
Bug ID: 90271
Summary: [missed-optimization] failure to keep variables in
registers during "faux" memcpy
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90272
Bug ID: 90272
Summary: internal compile error with full backtrace
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
--- Comment #5 from Jan van Dijk ---
Thanks a lot for this change.
One more nit: the standard clause 28.6.7(2) allows (== does not forbid)
negative count arguments, in which case generate_n is a no-op returning
__first, but this is not reflected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #1 from Eyal Rozenberg ---
Can also reproduce this in C, with slightly different code:
int replace_bytes_3(int v1 ,char v2)
{
memcpy( (void*) (((char*)&v1)+1) , &v2 , sizeof(v2) );
return v1;
}
int foo3()
{
int x = 3;
char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90262
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #1 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90269
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #4 from Jakub Jelinek ---
One thing is that store-merging doesn't optimize this, I think we have an open
enhancement request for that that should be able to cure that case.
Another one is that perhaps we should consider such MEM_REFs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #5 from rguenther at suse dot de ---
On Sun, 28 Apr 2019, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
>
> --- Comment #4 from Jakub Jelinek ---
> One thing is that store-merging doesn't opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #6 from Eyal Rozenberg ---
> Is the example from real-world code?
Yes. Example: Some machines support atomic instructions on aligned 32 bits or
on 64 bits, but not directly on 1, 2, 3, 5, 6 or 7 bytes. So in order to
atomically chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
--- Comment #6 from Jonathan Wakely ---
(In reply to Jan van Dijk from comment #5)
> Somewhat off-topic: IMHO the standard is not explicit about the fact that
> gen() is (of course) to be invoked separately for every element in the range:
> "The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #90 from Iain Sandoe ---
(In reply to Zaak from comment #89)
> Anyone have a patch for 4.9? A user wants one, but I can't build 4.9 from
> source on Mojave.
4.9is long-closed [as are 5, 6] , is there some reason the user can't move
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90269
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> Otherwise the patch looks sensible, mind to test/post it?
It bootstrapped and regtested fine, I'll send it later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
Bug ID: 90273
Summary: [9/10 Regression] GCC runs out of memory building
Firefox
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
Eric Gallager changed:
What|Removed |Added
Keywords||build, memory-hog
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #2 from Jan Hubicka ---
http://www.ucw.cz/~hubicka/Unified_cpp_dom_events0-8.ii.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #13 from Eric Gallager ---
(In reply to Jim Wilson from comment #12)
> I no longer have access to IA-64 hardware. I was leaving myself as
> maintainer just so that there was someone responsible for answering
> questions. I don't car
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
Jan Hubicka changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #4 from Jan Hubicka ---
The code is:
inline bool IsNodeInternal() const { return false; }
template
inline bool IsNodeInternal(First aFirst, Args... aArgs) const {
return mNodeInfo->Equals(aFirst) || IsNodeInternal(aArgs...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90274
Bug ID: 90274
Summary: untranslated string literal in opts.c
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 43728, which changed state.
Bug 43728 Summary: Add warning for redundant static function prototypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30123
--- Comment #5 from Eric Gallager ---
(In reply to Jürgen Reuter from comment #4)
> This seems like one of these documentation tasks which is in principle very
> easy to do but nobody is motivated to do.^^
Indeed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #4 from bin cheng ---
On AArch64, iovpts generates following code:
[local count: 954449108]:
# crc_20 = PHI
# ivtmp.5_18 = PHI <1(2), ivtmp.5_17(5)>
_19 = &final_counts + 18446744073709551612;
_1 = MEM[base: _19, index: iv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #5 from Andrew Pinski ---
(In reply to bin cheng from comment #4)
> On AArch64, iovpts generates following code:
>[local count: 954449108]:
> # crc_20 = PHI
> # ivtmp.5_18 = PHI <1(2), ivtmp.5_17(5)>
> _19 = &final_counts +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #6 from bin cheng ---
(In reply to Andrew Pinski from comment #5)
> (In reply to bin cheng from comment #4)
> > On AArch64, iovpts generates following code:
> >[local count: 954449108]:
> > # crc_20 = PHI
> > # ivtmp.5_18 = P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #7 from bin cheng ---
Also, when calling move_fixed_address_to_symbol, fixed_address_object_p looks
too restricted, it only considers link time constant address. In this case,
it's an array object in stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71188
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90230
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #9 from Richard Biener ---
(In reply to bin cheng from comment #7)
> Also, when calling move_fixed_address_to_symbol, fixed_address_object_p
> looks too restricted, it only considers link time constant address. In this
> case, it's a
38 matches
Mail list logo
