https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84610
Alexandre Oliva changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Alexandre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84642
Alexandre Oliva changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Alexandre
||aoliva at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #4 from Alexandre Oliva ---
Mine
||aoliva at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #2 from Alexandre Oliva ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84620
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84620
--- Comment #5 from Alexandre Oliva ---
Author: aoliva
Date: Sat Mar 10 06:42:40 2018
New Revision: 258411
URL: https://gcc.gnu.org/viewcvs?rev=258411=gcc=rev
Log:
[IEPM] [PR debug/84620] use constant form for DW_AT_GNU_entry_view
When
||aoliva at gcc dot gnu.org
--- Comment #2 from Alexandre Oliva ---
Mine
||aoliva at gcc dot gnu.org
--- Comment #3 from Alexandre Oliva ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84682
Alexandre Oliva changed:
What|Removed |Added
Keywords||patch
--- Comment #6 from Alexandre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84404
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84682
--- Comment #5 from Alexandre Oliva ---
Created attachment 43594
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43594=edit
candidate patch
Here's what I'm testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84404
--- Comment #8 from Alexandre Oliva ---
Author: aoliva
Date: Thu Mar 8 08:27:56 2018
New Revision: 258355
URL: https://gcc.gnu.org/viewcvs?rev=258355=gcc=rev
Log:
[LVU] reset view at function entry, omit views at line zero
Location views
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
--- Comment #12 from Alexandre Oliva ---
Author: aoliva
Date: Thu Mar 8 08:27:56 2018
New Revision: 258355
URL: https://gcc.gnu.org/viewcvs?rev=258355=gcc=rev
Log:
[LVU] reset view at function entry, omit views at line zero
Location views
||aoliva at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #4 from Alexandre Oliva ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84596
Alexandre Oliva changed:
What|Removed |Added
Priority|P4 |P3
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582
Bug 84582 depends on bug 84596, which changed state.
Bug 84596 Summary: [8 Regression] internal compiler error: unexpected
expression '(bool)c' of kind implicit_conv_expr (cxx_eval_constant_expression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84231
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84593
Alexandre Oliva changed:
What|Removed |Added
Priority|P4 |P3
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84492
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84231
--- Comment #5 from Alexandre Oliva ---
Author: aoliva
Date: Tue Mar 6 06:25:12 2018
New Revision: 258271
URL: https://gcc.gnu.org/viewcvs?rev=258271=gcc=rev
Log:
[C++] [PR84231] overload on cond_expr in template
A non-type-dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84593
--- Comment #3 from Alexandre Oliva ---
Author: aoliva
Date: Tue Mar 6 06:24:53 2018
New Revision: 258270
URL: https://gcc.gnu.org/viewcvs?rev=258270=gcc=rev
Log:
[PR c++/84593] ice on braced init with uninit ref field
If an initializer expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84492
--- Comment #4 from Alexandre Oliva ---
Author: aoliva
Date: Tue Mar 6 06:24:40 2018
New Revision: 258269
URL: https://gcc.gnu.org/viewcvs?rev=258269=gcc=rev
Log:
[PR c++/84492] stmt expr ending with overload
We ICEd when returning a stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84620
--- Comment #4 from Alexandre Oliva ---
Jakub, ok, I'll move the union field, but I thought it would be better to keep
it close to logically-similar entries. If the point is just to make it
parallel to the order of the enum, maybe moving the
||2018-03-02
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexandre Oliva ---
Created attachment 43539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43539=e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84456
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
||aoliva at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #3 from Alexandre Oliva ---
Created attachment 43526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43526=edit
candidate patch
Mine, here's what
||aoliva at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #2 from Alexandre Oliva ---
Created attachment 43524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43524=edit
candidate patch
Mine, here's what
||aoliva at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #3 from Alexandre Oliva ---
Created attachment 43523
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43523=edit
candidate patch
Mine. Here's the pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005
--- Comment #4 from Alexandre Oliva ---
I guess this is a case of adding xfails or target requirements to the dg
comments, but I'm not sufficiently familiar with the various vector-related
pseudo-target names to tell which ones would be right,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #24 from Alexandre Oliva ---
Author: aoliva
Date: Wed Feb 28 05:25:34 2018
New Revision: 258053
URL: https://gcc.gnu.org/viewcvs?rev=258053=gcc=rev
Log:
[PR81611] turn inc-and-use-of-dead-orig into auto-inc
When the addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84404
--- Comment #6 from Alexandre Oliva ---
Patch posted
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01224.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
--- Comment #11 from Alexandre Oliva ---
FYI, the patch I'm working on for PR 84404 will add forced view resets at
function entry points, which should alleviate this somewhat, assuming there's
more than one function in the testcase.
||2018-02-21
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Alexandre Oliva ---
On it. At least in the x86_64 testcase in c3, the problem is that we have a
gomp function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
--- Comment #10 from Alexandre Oliva ---
I forgot to mention, compiling with -ginternal-reset-location-views will issue
view resets where GCC would place them if the hook were defined so as to just
return zero, so we can easily confirm whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
--- Comment #9 from Alexandre Oliva ---
Pardom for taking so long to chime in.
I suspect the source of the problem is the lack of internal view reset
computations. Without that, the assembler gets an uninterrupted chain of
symbolic views, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84342
--- Comment #8 from Alexandre Oliva ---
That's the hook, yes. But if you return 1, then the view-computing logic will
behave just as if it noticed a nonzero length for the insn. If the branch is
eliminated and no code it generated for that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84342
Alexandre Oliva changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84317
--- Comment #4 from Alexandre Oliva ---
The corrected patch, that I emailed you just after I got your email and
realized I'd posted the patch without that fix, has been in the trunk since
yesterday, FWIW.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84342
--- Comment #3 from Alexandre Oliva ---
Make it https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00723.html
The earlier patch was missing a fix without which it wouldn't even build.
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #2 from Alexandre Oliva ---
This assembler assert error is caused by a bug in the arm back-end, that makes
GCC assume it can reset the view counter at an insn because the back-end says
it has positive min length, but the insn turns
||2018-02-13
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexandre Oliva ---
Mine. I suspect this is a symptom of a latent bug in the internal line number
generator
||2018-02-13
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexandre Oliva ---
Rainer, thanks for the report.
do you still get this with after revision 257562? it may very
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84231
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84231
--- Comment #3 from Alexandre Oliva ---
The difference arises because, when resolving the % overload in
normal_function, the result operands of the ternary operator have gained
rvalue-forcing NOP_EXPRs, which makes their lvalue_kind clk_none, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84231
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005
--- Comment #3 from Alexandre Oliva ---
With the current vect alignment computations, we end up using the alignment of
the arrays, so on x86_64 it's 256bits (DATA_ALIGNMENT bumps the alignment up)
and on ppc64 it's 32bits, no alignment bump.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #21 from Alexandre Oliva ---
Author: aoliva
Date: Tue Jan 30 17:40:50 2018
New Revision: 257194
URL: https://gcc.gnu.org/viewcvs?rev=257194=gcc=rev
Log:
[PR81611] accept copies in simple_iv_increment_p
If there are copies between
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #19 from Alexandre Oliva ---
I was copied, presumably because the problem occurred in var-tracking.
I've tried to duplicate the problem on gcc112. I bootstrapped the trunk
(without any --with-cpu flag), and then build attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #18 from Alexandre Oliva ---
Vacations over, patches formatted and posted.
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01994.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480
--- Comment #9 from Alexandre Oliva ---
didn't we print a warning if we found VTA and sel-sched enabled at the same
time, too? I guess that might be useful in this case as well. (thanks for
taking care of this!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480
--- Comment #6 from Alexandre Oliva ---
It seems like sel-sched really can't deal with debug insns; I agree it makes
sense to disable all sorts of debug insns when sel-sched is selected/enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #17 from Alexandre Oliva ---
Created attachment 43025
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43025=edit
another complement to the initial partial patch, this one improving
auto-inc-dec
We already had code to turn the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #16 from Alexandre Oliva ---
Even if create_mem_ref_raw created a MEM_REF, we'd still allocate a new pseudo
for the reg - 1 at cfgexpand, and that ends up preventing the post_inc
addressing mode from being selected.
The more I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #15 from Alexandre Oliva ---
As we create_mem_ref within ivopts, create_mem_ref_raw requires a
valid_mem_ref_p, which in memory_address_addr_space_p calls
targetm.addr_space.legitimate_address_p, and that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #13 from Alexandre Oliva ---
We do have such constant propagation on such ports as x86* and arm, but not on
avr. Presumably (I haven't checked) it has to do with available addressing
modes, and gimple's avoiding, even in MEM_REFs,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #11 from Alexandre Oliva ---
Testing has revealed that the alternative complementary candidate patch
introduces a number of regressions, in tests intended specifically to detect
this kind of problem. I don't see an easy way to delay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
Alexandre Oliva changed:
What|Removed |Added
Attachment #42971|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
Alexandre Oliva changed:
What|Removed |Added
Attachment #42969|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #8 from Alexandre Oliva ---
Created attachment 42970
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42970=edit
alternative (?) complementary candidate patch
This addresses the concern of post-increment in non-loops. It solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #7 from Alexandre Oliva ---
Hmm, what the complementary patch won't do is improve the odds of auto_inc or
even saving a temp in spaghetti code, rather than in loops. Maybe that's
important too? I wonder if we should add the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #6 from Alexandre Oliva ---
Created attachment 42969
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42969=edit
complementary candidate patch
This patch complements the earlier one.
On AVR, unlike other ports, we had the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #5 from Alexandre Oliva ---
Created attachment 42968
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42968=edit
partial candidate patch
Alas, although it restores good code for x86_64 and arm, it doesn't go as far
as enabling
-optimization|tree-optimization
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #4 from Alexandre Oliva ---
Mine; patch will be attached momentarily.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
||aoliva at gcc dot gnu.org
Resolution|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #15 from Alexandre Oliva ---
AFAICT this is fixed; thanks, Martin!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83527
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83419
--- Comment #9 from Alexandre Oliva ---
Author: aoliva
Date: Fri Dec 22 02:07:31 2017
New Revision: 255966
URL: https://gcc.gnu.org/viewcvs?rev=255966=gcc=rev
Log:
[SFN] sync up debug-only stmt list's side effects with empty stmts too
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83527
--- Comment #5 from Alexandre Oliva ---
Author: aoliva
Date: Fri Dec 22 02:07:31 2017
New Revision: 255966
URL: https://gcc.gnu.org/viewcvs?rev=255966=gcc=rev
Log:
[SFN] sync up debug-only stmt list's side effects with empty stmts too
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83527
--- Comment #4 from Alexandre Oliva ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01462.html
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #3 from Alexandre Oliva ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83419
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83419
--- Comment #7 from Alexandre Oliva ---
Author: aoliva
Date: Thu Dec 21 18:14:06 2017
New Revision: 255947
URL: https://gcc.gnu.org/viewcvs?rev=255947=gcc=rev
Log:
[SFN] propagate single-nondebug-stmt's side effects to enclosing list
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #6 from Alexandre Oliva ---
Mine. Fixed, IIUC. Please reopen otherwise.
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #6 from Alexandre Oliva ---
Mine. Patch posted at https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01393.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #84 from Alexandre Oliva ---
Author: aoliva
Date: Wed Dec 20 14:48:34 2017
New Revision: 255895
URL: https://gcc.gnu.org/viewcvs?rev=255895=gcc=rev
Log:
[SFN] debug markers before labels no more
Make sure that gimple and RTL IRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83422
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83422
--- Comment #8 from Alexandre Oliva ---
Author: aoliva
Date: Tue Dec 19 17:50:54 2017
New Revision: 255834
URL: https://gcc.gnu.org/viewcvs?rev=255834=gcc=rev
Log:
SFN: don't drop markers for skipping var-tracking
Although debug markers are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #82 from Alexandre Oliva ---
Author: aoliva
Date: Tue Dec 19 17:50:31 2017
New Revision: 255833
URL: https://gcc.gnu.org/viewcvs?rev=255833=gcc=rev
Log:
[SFN] start rtl block with label, then markers
Emitting markers before labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #80 from Alexandre Oliva ---
A preprocessed testcase and command line would be welcome to try to debug the
armv8 issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #77 from Alexandre Oliva ---
Created attachment 42891
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42891=edit
fix libiberty/unix-pex bootstrap compare (stage3 configure)
... and if you find that bootstrap-debug compare fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #76 from Alexandre Oliva ---
Created attachment 42890
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42890=edit
move markers after labels while building the cfg
This is a follow up to comment 61, that adjusts the IR to reject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #70 from Alexandre Oliva ---
ktkatchov, I'll submit the patch as soon as it completes testing, which should
be Real Soon Now (TM) :-) If you got the cycles to give it a spin, by all
means let us know how it goes! Thanks,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83422
--- Comment #6 from Alexandre Oliva ---
Created attachment 42887
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42887=edit
candidate patch
Here's what I'm testing.
||2017-12-14
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Alexandre Oliva ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #66 from Alexandre Oliva ---
Jakub, *nod*, that's among the "changes added to support that".
Ulrich, thanks for the report. r255639 compiles your testcase successfully on
x86_64-linux-gnu-x-spu-elf with -O -g, so I guess the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #63 from Jakub Jelinek ---
Comment on attachment 42885
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42885
expand labels before markers
If you do this, then we should also revert the var-tracking.c etc. changes to
look for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #62 from Alexandre Oliva ---
Author: aoliva
Date: Thu Dec 14 15:02:58 2017
New Revision: 255638
URL: https://gcc.gnu.org/viewcvs?rev=255638=gcc=rev
Log:
[SFN] next/prev_nonnote_insn_bb are no more, even for ports
The patch that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #61 from Alexandre Oliva ---
Created attachment 42885
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42885=edit
expand labels before markers
This patch fixes both ia64 problems. Basically, the ebb scheduler gets
thoroughly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83422
--- Comment #3 from Alexandre Oliva ---
Right now, I can't see a reason to drop markers just because VTA is disabled.
Although they do lose some value, they're probably still useful on their own.
So I suggest dropping both lines that clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #60 from Alexandre Oliva ---
Joseph, thanks for the feedback. I've fixed the SH (and ARC) build error in my
tree.
Andreas, thanks for the ia64 testcases, I'm looking into them. From your email
address, is it correct to assume that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #50 from Alexandre Oliva ---
Author: aoliva
Date: Wed Dec 13 19:09:45 2017
New Revision: 255612
URL: https://gcc.gnu.org/viewcvs?rev=255612=gcc=rev
Log:
[SFN] don't eliminate regs in markers
Eliminate regs in debug bind insns, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #19 from Alexandre Oliva ---
Created attachment 42860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42860=edit
additional patch for the sparc pr69102 FAIL
This patch fixes the testsuite regression reported by Rainier on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #18 from Alexandre Oliva ---
Created attachment 42859
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42859=edit
additional patch for the ia64 problem reported by andreas
Andreas, this patch (on top of the other) enables your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #17 from Alexandre Oliva ---
Rainier, I wasn't sure how "same" the bootstrap failure you'd observed was,
that's why I'd asked for a preprocessed testcase. Now, since the patch fixed
the problem, nevermind. I'll look into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
Alexandre Oliva changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83391
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
401 - 500 of 1091 matches
Mail list logo
