Hi,
Sorry, mistyped. Please read `jne` instead of `je` in handwritten
"optimized" assembler.
---
With best regards, Konstantin
On Thu, Feb 21, 2013 at 3:57 PM, Konstantin Vladimirov
wrote:
> Hi,
>
> Discovered this optimization possibilty on private backend, but can
> easily reproduce on x86
>
On Thu, Feb 21, 2013 at 03:58:56PM +0400, Konstantin Vladimirov wrote:
> Hi,
>
> Sorry, mistyped. Please read `jne` instead of `je` in handwritten
> "optimized" assembler.
>
> ---
> With best regards, Konstantin
>
> On Thu, Feb 21, 2013 at 3:57 PM, Konstantin Vladimirov
> wrote:
> > Hi,
> >
> >
I'm trying to make IL verifying more streamlined - it's often
that passes have some random (or no) verification in their TODO
which makes pinning down issues to specific passes hard.
Thus I propose to unify the various TODO_verify_* flags into
a single one, TODO_verify_il, and based on what IL pr
On Thu, Feb 21, 2013 at 03:57:05PM +0400, Konstantin Vladimirov wrote:
> Hi,
>
> Discovered this optimization possibilty on private backend, but can
> easily reproduce on x86
>
> Consider code, say test.c:
>
> static __attribute__((noinline)) unsigned int*
> proxy1( unsigned int* codeBuffer, uns
On Thu, Feb 21, 2013 at 04:37:48PM +0400, Konstantin Vladimirov wrote:
> Hi,
>
> Can you please make more clear why possible self-modifying code in
> proxy2 blocks optimization of caller function? We just sending control
> from caller to proxy1 or proxy2 and saying goodbye. Am I missed
> something
On 02/21/13 05:37, Richard Biener wrote:
I'm trying to make IL verifying more streamlined - it's often
that passes have some random (or no) verification in their TODO
which makes pinning down issues to specific passes hard.
Thus I propose to unify the various TODO_verify_* flags into
a single o
Hi,
On Wed, 20 Feb 2013, Michael Matz wrote:
> I.e. it looks like as if a following reference once the link editor saw
> the definition of the symbol resets it's unique status. I can make both
> symbols wrong/non-unique by placing wlocale-inst.o last in the linker
> cmdline.
Actually this bu
Hi,
On Thu, 21 Feb 2013, Richard Biener wrote:
> Do people think that the fine-grained verification control
> is actually useful or do you agree with me that it leads to
> sloppiness?
I agree with you ...
> --- 1955,1982
> return;
>
> #if defined ENABLE_CHECKING
> ! if (flags
Hi,
On Thu, Feb 21, 2013 at 01:37:28PM +0100, Richard Biener wrote:
>
> I'm trying to make IL verifying more streamlined - it's often
> that passes have some random (or no) verification in their TODO
> which makes pinning down issues to specific passes hard.
>
> Thus I propose to unify the vario
On Thu, 21 Feb 2013, Martin Jambor wrote:
> Hi,
>
> On Thu, Feb 21, 2013 at 01:37:28PM +0100, Richard Biener wrote:
> >
> > I'm trying to make IL verifying more streamlined - it's often
> > that passes have some random (or no) verification in their TODO
> > which makes pinning down issues to spe
On Thu, Feb 21, 2013 at 7:37 AM, Richard Biener wrote:
>
> I'm trying to make IL verifying more streamlined - it's often
> that passes have some random (or no) verification in their TODO
> which makes pinning down issues to specific passes hard.
>
> Thus I propose to unify the various TODO_verify_
Hi,
the gdc D compiler currently doesn't implement "non-POD" types. As in C++ those
types can have copy constructors or destructors and should be kept in memory.
Right now I just set TREE_ADDRESSABLE on the RECORD_TYPE tree and it's mostly
working. Some test cases fail though if optimization / inl
On Thu, Feb 21, 2013 at 7:58 AM, Johannes Pfau wrote:
>
> the gdc D compiler currently doesn't implement "non-POD" types. As in C++
> those
> types can have copy constructors or destructors and should be kept in memory.
> Right now I just set TREE_ADDRESSABLE on the RECORD_TYPE tree and it's most
> I don't know exactly what is going wrong. But I can tell you that if
> a function returns a TREE_ADDRESSABLE type, that should be handled by
> passing in an invisible first parameter that is a pointer to the area
> on the stack where the function should write the return value.
Yes, TREE_ADDRESS
Hi!
(reposting to gcc@, probably gcc-bugs@ was the wrong list, sorry)
I'm not really sure which (g++ or libstdc++) problem this really is, so
posting into both lists.
The problem is described here:
http://cpp-next.com/archive/2009/10/exceptionally-moving/
- You have two classes:
A, which has
Hi,
GCCINT says that nop_expr is used to represent conversions that do not
require any code generation, while function tree_strip_nop_conversions
calls tree_nop_conversion, which returns false even for NOP_EXPR node
like "(unsigned int)a", where a has type int.
Did I miss something? Thanks
--
Bes
On Thu, Feb 21, 2013 at 7:16 PM, Bin.Cheng wrote:
> Hi,
> GCCINT says that nop_expr is used to represent conversions that do not
> require any code generation, while function tree_strip_nop_conversions
> calls tree_nop_conversion, which returns false even for NOP_EXPR node
> like "(unsigned int)a"
On Fri, Feb 22, 2013 at 12:14 PM, Andrew Pinski wrote:
> On Thu, Feb 21, 2013 at 7:16 PM, Bin.Cheng wrote:
>> Hi,
>> GCCINT says that nop_expr is used to represent conversions that do not
>> require any code generation, while function tree_strip_nop_conversions
>> calls tree_nop_conversion, which
On Thu, Feb 21, 2013 at 8:31 PM, Bin.Cheng wrote:
> On Fri, Feb 22, 2013 at 12:14 PM, Andrew Pinski wrote:
>> On Thu, Feb 21, 2013 at 7:16 PM, Bin.Cheng wrote:
>>> Hi,
>>> GCCINT says that nop_expr is used to represent conversions that do not
>>> require any code generation, while function tree_
On Fri, Feb 22, 2013 at 12:33 PM, Andrew Pinski wrote:
> On Thu, Feb 21, 2013 at 8:31 PM, Bin.Cheng wrote:
>> On Fri, Feb 22, 2013 at 12:14 PM, Andrew Pinski wrote:
>>> On Thu, Feb 21, 2013 at 7:16 PM, Bin.Cheng wrote:
Hi,
GCCINT says that nop_expr is used to represent conversions tha
20 matches
Mail list logo
