On 24/04/13 15:40, Richard Biener wrote:
> I expected we preserve edges across RTL expansion? We cannot re-create
> them optimally from scratch, but yes, re-construction is possible. Can you
> open a bugreport pointing out the missing RTL bits?
Done.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
On Wed, Apr 24, 2013 at 3:25 PM, Andreas Krebbel
wrote:
> On 23/04/13 17:19, Florian Weimer wrote:
>> On 04/23/2013 04:45 PM, Andreas Krebbel wrote:
>>> I was not able to reproduce the problem with head GCC. But I couldn't
>>> find anything which addresses the problem either. So I assume that a
>
On 23/04/13 17:19, Florian Weimer wrote:
> On 04/23/2013 04:45 PM, Andreas Krebbel wrote:
>> I was not able to reproduce the problem with head GCC. But I couldn't
>> find anything which addresses the problem either. So I assume that a
>> different situation before the scheduling pass hides the pro
On 04/23/2013 04:45 PM, Andreas Krebbel wrote:
I was not able to reproduce the problem with head GCC. But I couldn't
find anything which addresses the problem either. So I assume that a
different situation before the scheduling pass hides the problem.
The fix for PR56982 might address this one
Hi,
with GCC 4.1 and GCC 4.4 (RHEL 5.9) the example below prints a value
of 1 for netwait (on x86_64 and s390x). The problem is that the
assignment at /* 2 */ is moved to /* 1 */ during instruction
scheduling.
The quick fix is to make "netwait" volatile. But according to the C
standard (7.13.2.
