This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] mainline->branch merge status
Dale Johannesen <dalej@apple.com> writes:
> On Jan 28, 2004, at 10:22 AM, Diego Novillo wrote:
>> A heads-up for those of us following SPEC results. The new merge brings
>> in the removal of assignments to non-lvalues. This produces a compile
>> error in 176.gcc:
>>
>> reorg.c: In function `find_end_label':
>> reorg.c:831: error: invalid lvalue in increment
>> reorg.c: In function `delete_from_delay_slot':
>> reorg.c:1033: error: invalid lvalue in increment
>> reorg.c: In function `make_return_insns':
>> reorg.c:4157: error: invalid lvalue in increment
>> reorg.c: In function `dbr_schedule':
>> reorg.c:4237: error: invalid lvalue in increment
>> specmake: *** [reorg.o] Error 1
>>
>> This comes from the old obstack.h file. I fixed the file, but cc1
>> miscompares at runtime. Maybe my fix is wrong, or maybe we've inherited
>> a bug from mainline. I still don't know.
>
> Well, how did you fix it? The offending code is
>
> *((void **)__o->next_free)++ = ((void *)datum); \
>
> If you just break this into two in the obvious fashion
>
> { \
> *((void **)__o->next_tree) = ((void*)datum); \
> ((void **)__o->next_tree)++; \
> } \
This has the same problem.
{ \
*(void **) __o->next_free = (void *) datum; \
__o->next_free += sizeof (void *); \
} \
> can happen. I believe the following is correct, performance neutral, and
> standard-conforming:
>
> {
> \
> void ***t = (void ***)&(__o->next_free);
> \
> **t = ((void *)datum); \
> (*t)++;
> \
> } \
I think this will break strict aliasing.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."