Andrew Pinski wrote:
> > FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not
> > set on the constructor, despite the presence of a function call in
> > the components.
> No, that is not the problem. The problem is that we gimplify the
> expression for side effects but don't actua
Olivier Hainque wrote:
> I'm not yet clear why the call is not issued there. This is my first
> dive in the gimplifier, so it might well be simple.
FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not
set on the constructor, despite the presence of a function call in
the compone
On Sep 9, 2005, at 4:40 PM, Olivier Hainque wrote:
Olivier Hainque wrote:
I'm not yet clear why the call is not issued there. This is my first
dive in the gimplifier, so it might well be simple.
FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not
set on the constructor, de
On Sep 9, 2005, at 4:40 PM, Olivier Hainque wrote:
Olivier Hainque wrote:
I'm not yet clear why the call is not issued there. This is my first
dive in the gimplifier, so it might well be simple.
FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not
set on the constructor, de
Andrew Pinski wrote:
> > I have been experimenting with a simple patch adding side effects
> > checks to the conditions, like "! TREE_SIDE_EFFECTS (value)"
> > in init_ctor_eval
>
> Yes the one in needs to gimplify only the expression as a statement
> and not add a modify statement. More on the t
Daniel Berlin wrote:
> > spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
>
> What exactly is this code expected to do?
> Call one_raw_spinlock and then throw away the result?
Yes. As you said, the result is nothing anyway, but the function should
still be called IMO.
>
Daniel Berlin <[EMAIL PROTECTED]> writes:
| >int main(void)
| >{
| > spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
|
| What exactly is this code expected to do?
| Call one_raw_spinlock and then throw away the result?
yes, that is implied by C99 semantics.
-- Ga
Dave Korn wrote:
> Surely returning the vaule of this uninitialised variable makes your code
> invalid?
Well, sure. Adding an initializer in one_raw_spinlock doesn't help.
The t03.gimple dump reads:
main ()
{
struct spinlock_t D.1783;
int D.1784;
struct spinlock_t lock;
>int main(void)
>{
> spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
What exactly is this code expected to do?
Call one_raw_spinlock and then throw away the result?
If so, feel free to change gimplify_init_ctor_eval to do that.
But again, if you expect "real" sets
Original Message
>From: Olivier Hainque
>Sent: 09 September 2005 14:25
> You may have side effect from an initializer when setting a zero
> sized field.
>
> For instance (variant of gcc.c-torture/compile/zero-strct-4.c), compiled
> with GCC 3.4, the code below prints "returning raw_lo
Daniel Berlin wrote:
> Even if you "fixed" init_ctor_eval (modify_expr gimplifies the lhs and rhs
> and throws away the assignment), you're going to run into problems in
> the subvar machinery if you really have 0 sized field accesses with side
> effects.
>
> I'm not sure what the heck a "0 siz
On Fri, 9 Sep 2005, Olivier Hainque wrote:
Hello,
In a number of places, the gimplifier simply discards what involves
zero sized entities. For instance:
in "gimplify_init_ctor_eval"...
FOR_EACH_CONSTRUCTOR_ELT (elts, ix, purpose, value)
...
if (zero_sized_field_decl (purpose
On Sep 9, 2005, at 8:30 AM, Olivier Hainque wrote:
Hello,
I have been experimenting with a simple patch adding side effects
checks to the conditions, like "! TREE_SIDE_EFFECTS (value)"
in init_ctor_eval
Yes the one in needs to gimplify only the expression as a statement
and not add a modify
Hello,
In a number of places, the gimplifier simply discards what involves
zero sized entities. For instance:
in "gimplify_init_ctor_eval"...
FOR_EACH_CONSTRUCTOR_ELT (elts, ix, purpose, value)
...
if (zero_sized_field_decl (purpose))
continue;
or in "gimplify_mod
14 matches
Mail list logo
