https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #21 from Richard Biener ---
*** Bug 85862 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
Matt Weber changed:
What|Removed |Added
CC||matthew.weber@rockwellcolli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #19 from rguenther at suse dot de ---
On Wed, 9 May 2018, romain.naour at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
>
> Romain Naour changed:
>
>What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
Romain Naour changed:
What|Removed |Added
CC||romain.naour at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #17 from Richard Biener ---
(In reply to romain.naour from comment #16)
> Hi,
>
> gcc 7.3.0 is affected by this bug but only on microblaze architecture, see
> [1].
> Do you plan to backport this patch on gcc 7.x?
> It is safe to do s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #16 from romain.naour at smile dot fr ---
Hi,
gcc 7.3.0 is affected by this bug but only on microblaze architecture, see [1].
Do you plan to backport this patch on gcc 7.x?
It is safe to do so without take the risk to break something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #14 from Richard Biener ---
Author: rguenth
Date: Fri Apr 6 08:30:52 2018
New Revision: 259166
URL: https://gcc.gnu.org/viewcvs?rev=259166&root=gcc&view=rev
Log:
2018-04-06 Richard Biener
PR middle-end/85180
* al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #13 from Richard Biener ---
Created attachment 43851
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43851&action=edit
other alternative
Like this.
11.00user 0.01system 0:11.01elapsed 99%CPU (0avgtext+0avgdata
43204maxresident)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #12 from Jakub Jelinek ---
True, but might eat more compile time memory.
Further, the question stands, is what find_base_term returns for a particular
VALUE cacheable for the whole duration between cselib_init and cselib_finish in
eac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #11 from Richard Biener ---
So it looks like caching in cselib_val->rtx and unwinding that via a stack
might be the fastest variant (if we care)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #10 from Richard Biener ---
Created attachment 43850
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43850&action=edit
alternative patch
The most simple hash_map variant is the attached. Comparing (-O0 optimized
cc1)
compile-ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #9 from rguenther at suse dot de ---
On Thu, 5 Apr 2018, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
>
> --- Comment #8 from Jakub Jelinek ---
> If find_base_term always returned whatever fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #8 from Jakub Jelinek ---
If find_base_term always returned whatever first returned non-NULL up to the
ultimate caller, then I think the above would work fine. Sadly, that is the
case only in most of the spots, not all of them.
The P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #7 from Richard Biener ---
Created attachment 43849
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43849&action=edit
patch
Patch I am testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #6 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> Actually, find_base_value is probably ok, it doesn't handle VALUEs and for
> PLUS/MINUS it just guesses one operand on which to recurse, rather than both.
find_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #5 from Jakub Jelinek ---
Another testcase running into this.
char *bar (void);
__INTPTR_TYPE__ baz (void);
void
foo (__INTPTR_TYPE__ *q)
{
char *p = bar ();
__INTPTR_TYPE__ a = baz ();
__INTPTR_TYPE__ b = baz ();
int i = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #4 from Jakub Jelinek ---
Actually, find_base_value is probably ok, it doesn't handle VALUEs and for
PLUS/MINUS it just guesses one operand on which to recurse, rather than both.
Another possibility is to add some counter and count h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #3 from Jakub Jelinek ---
Simplified testcase:
struct words
{
#define V(n) short word_##n;
#define W(n) V(n)
#define X(n) W(n##0) W(n##1) W(n##2) W(n##3) W(n##4) W(n##5) W(n##6) W(n##7)
W(n##8) W(n##9)
#define Y X(0) X(1) X(2) X(3) X(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
Richard Biener changed:
What|Removed |Added
Keywords||compile-time-hog
Status|UNC
22 matches
Mail list logo
