These testcase on powerpc:
gcc.target/powerpc/405-dlmzb-strlen-1.c scan-assembler dlmzb\\\\. (-m32)
gcc.target/powerpc/440-dlmzb-strlen-1.c scan-assembler dlmzb\\\\. (-m32)
fail since expand from SSA. That's because TER can't work around a frontend
deficiency anymore. The code therein is:
size_t strlen8(const long long *s)
{ return strlen((const char *)s); }
the parameter is "long long *" to make the alignment known to the compiler.
There are of course other ways, but this is not what this report is about.
In any case the target type of *s is aligned(8).
The cast is there to be type-correct for strlen, but the destination type
of that cast simply is "const char *", where "char" of course is aligned(1).
For the middle-end the case to char* is not useless, hence we can't get
rid of it, so the pointer alignment as far as strlen is concerned is 1, which
is why the transformation doesn't happen anymore. TER could work around this
in some case (single use of that temporary), but not always. Now it doesn't
do that work-around in any case.
What IMO needs to happen is that the frontend construct a new type as
destination type of the cast, as if the user had written:
typedef char alignedchar __attribute__((aligned(8)));
x = (const alignedchar *)s;
Unfortunately this can't be easily transformed into a testcase using
__alignof__, because __alignof__((*(char*)s)) is already transformed by
the frontend looking through the casts. That disregards that the same
can't be done by the middle-end.
--
Summary: casts loose alignment info
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40060
