13371 – [3.3.2 regression] infinite loop with packed struct and inlining (original) (raw)

cc1plus generates bad code for this testcase. An infinite loop is generated. I think it's because a scope statement is emitted twice (or something like that). you can see the bug in the .00.rtl file. I was able to recreate this with the gcc-ss-3_3-20031208 tag.

Compile with ./cc1plus -quiet -O2 foo.cc

enum state_e { STATE_0 = 0, STATE_1 = 1, };

struct packed_state_t { state_e state : 8; } attribute ((packed));

class foo_c { public:

void set_state (unsigned p, state_e s);

};

class bar_c { public:

struct { unsigned a; unsigned b; } r;

inline unsigned get_a () const { return this->r.a; }

inline unsigned get_b () const { return this->r.b; }

inline unsigned get_u (unsigned a) const { return a + this->get_b (); }

packed_state_t* state;

foo_c* foo_if;

void set_state (unsigned p, state_e s); };

enum state_params_e { STATE_LOG_CHUNK_SZ = 7, STATE_CHUNK_SZ = 1 << STATE_LOG_CHUNK_SZ }; static __inline__ unsigned get_state_index (unsigned a) { return a >> STATE_LOG_CHUNK_SZ; }

void bar_c::set_state (unsigned p, state_e s) { unsigned u = this->get_u (p); if (u < this->get_a ()) { this->state [get_state_index (u)].state = s; return; }

this->foo_if->set_state (p, s);

}

Study the resulting assembly for the `if' clause and you'll see this:

.L7: movl %edx, %eax shrl $7, %eax movb %bl, (%eax,%ecx) jmp .L7

Comment 1 Dara Hazeghi 2003-12-10 08:27:53 UTC

Same problem code is seen on 3.3 branch, but not on mainline or 3.3.1.

Comment 2 dje 2003-12-10 18:52:48 UTC

(In reply to comment #1)

Same problem code is seen on 3.3 branch, but not on mainline or 3.3.1.

Thanks for checking 3.3.1. Diffing the ChangeLog's and doing some semi-intelligent guessing, I narrowed it down to this patch.

2003-09-07 Jason Merrill <jason@redhat.com>

   [PR c++/12181](show%5Fbug.cgi?id=12181 "RESOLVED FIXED - [3.3 regression] Wrong code with comma operator and c++")
   * typeck.c (build_modify_expr): Don't always stabilize the lhs and
   rhs.  Do stabilize the lhs of a MODIFY_EXPR used on the lhs.

Sorry Jason. :-)

Comment 4 Dara Hazeghi 2003-12-11 08:15:02 UTC

I'm not sure if the reason why this doesn't occur on mainline is luck, or a bug in backporting. Mark you did the backport. Any suggestions? Thanks.

Comment 5 Mark Mitchell 2003-12-15 06:39:25 UTC

I really have no idea what's wrong. It probably makes sense to ask Jason, since it looks like this was this was his bug originally?

Comment 6 Dara Hazeghi 2003-12-15 22:24:30 UTC

Jason, the backport of your fix to PR12181 causes this regression on the 3.3 branch. Any suggestions? Thanks.

Comment 10 Jason Merrill 2003-12-19 20:25:56 UTC

Fixed.