> Oh, I didn't realize curr_location is of type location_t. I'm not very
> familiar with these bits. Btw, insn_locators_alloc initializes it with -1
> while it should probably initialize it with UNKNOWN_LCOATION as well.
Indeed, will adjust them afterwards.
> So it looks like the patch is perfe
On Mon, Mar 28, 2011 at 1:08 PM, Eric Botcazou wrote:
>> This overloads UNKNOWN_LOCATION for both insn_locator and
>> source_location, I don't think this is the best idea. It'll eventually
>> break when compiling with C++ anyway.
>
> Could you elaborate? UNKNOWN_LOCATION isn't used for INSN_LOCA
> This overloads UNKNOWN_LOCATION for both insn_locator and
> source_location, I don't think this is the best idea. It'll eventually
> break when compiling with C++ anyway.
Could you elaborate? UNKNOWN_LOCATION isn't used for INSN_LOCATOR at all
thanks for the curr_insn_locator hunk.
> The exp
On Mon, Mar 28, 2011 at 11:00 AM, Eric Botcazou wrote:
> Hi,
>
> when optimization is enabled, especially -O2 and above, you can have lines in
> the assembly file with really bogus source location info. The scenario is as
> follows: an optimization pass at the Tree level (typically PRE) creates a
Hi,
when optimization is enabled, especially -O2 and above, you can have lines in
the assembly file with really bogus source location info. The scenario is as
follows: an optimization pass at the Tree level (typically PRE) creates a new
statement and inserts it at some place in the dominator t
