https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
Richard Biener changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
Robert Dubner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #20 from Robert Dubner ---
(In reply to Richard Biener from comment #15)
> (In reply to Robert Dubner from comment #14)
> > (In reply to Richard Biener from comment #13)
> > > (In reply to Robert Dubner from comment #7)
> > >
[...]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #18 from Robert Dubner ---
(In reply to Jakub Jelinek from comment #17)
> Note,
> * gengen.cc: applies if( !optimize ) test
> is not properly formatted ChangeLog entry, unfortunately it got through
> pre-commit hooks.
> For n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #19 from Sam James ---
(In reply to Robert Dubner from comment #18)
> I don't understand why the "The creation of assembler labels..." is going to
> become part of the ChangeLog. That text is above the line with the
> gcc/cobol: des
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #16 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:b673d7b593f63a526a85d56204f1217bc4fbf6a1
commit r15-8056-gb673d7b593f63a526a85d56204f1217bc4fbf6a1
Author: Robert Dubner
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #17 from Jakub Jelinek ---
Note,
* gengen.cc: applies if( !optimize ) test
is not properly formatted ChangeLog entry, unfortunately it got through
pre-commit hooks.
For next time, I think Richard provided what should have bee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #15 from Richard Biener ---
(In reply to Robert Dubner from comment #14)
> (In reply to Richard Biener from comment #13)
> > (In reply to Robert Dubner from comment #7)
> >
> > Yes. IMO the least invasive way is to instead use labe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
Robert Dubner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #13 from Richard Biener ---
(In reply to Robert Dubner from comment #7)
> Well, I did ask for suggestions. I suppose it's not surprising I don't
> really understand them. Yet.
>
> I should explain, a little further, the underlying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #12 from Robert Dubner ---
"Obvious," the man says.
Do you know the story about the professor doing a proof at the blackboard? He
finishes a step, then says, "It's obvious from step three that..."
A student interrupts. "Professor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #11 from Jakub Jelinek ---
There are many passes which can duplicate asm stmts, e.g. loop unrolling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #10 from Jakub Jelinek ---
The obvious way to check for -O0 is if (!optimize)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #9 from Robert Dubner ---
Having said all that, I finally got around to confirming the behavior, which I
did.
After noting that the problem doesn't manifest with "-O0 -ftracer", and noting
further that there is no way obvious to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #8 from Jakub Jelinek ---
It would work the same as
volatile int v;
static inline __attribute__((always_inline)) int foo (int x)
{
++v;
++v;
++v;
return x;
}
int
main ()
{
int x;
x = foo (1);
x += foo (2);
x += foo (3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #7 from Robert Dubner ---
Well, I did ask for suggestions. I suppose it's not surprising I don't really
understand them. Yet.
I should explain, a little further, the underlying problems.
This, for example, is a modified sample fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #6 from Jakub Jelinek ---
I don't see how we could easily track ranges of something not represented as
the BLOCK, only that way we find at final time this insn belongs to this set of
blocks and this next one doesn't and can create ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #5 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> I guess the options are pretend that FOO is an inlined call for debug info
> purposes (so DW_TAG_subprogram is created for it and the statements
> belonging are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
Jakub Jelinek changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
Robert Dubner changed:
What|Removed |Added
CC||rdubner at symas dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #1 from Richard Biener ---
That said, I suggest to disable all gg_insert_into_assembler () by default.
22 matches
Mail list logo
