ARM/Linux: Is this a cross-compiler bug? $B!J(Bmemcpy doesn't work as expected)

I can reproduce the problem. But if I write this:

void *p1 = &bar; void *p2 = (void*)(foo->m);

it works, at least with g++ 4.1.2 on my NAS system, for which I've changed the internal firmware to a standard Debian Linux. The interesting thing: If I'm using my own memcpy, as you described:

void mymemcpy(void* p1, void* p2, int size) { unsigned char* p11 = (unsigned char*) p1; unsigned char* p22 = (unsigned char*) p2; for (int i = 0; i < size; i++) p11[i] = p22[i]; }

it works all the time. I guess this could be an alignment problem with memcpy. You should file a bug report, see

Compile command: g++ -O2 -Wall test.c

System on which I've tested it:

# g++ --version g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

# cat /proc/cpuinfo Processor : ARM926EJ-Sid(wb) rev 0 (v5l) BogoMIPS : 266.24 Features : swp half thumb fastmult edsp java CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 0

I guess most C ARM cross compilers are based on the GNU compiler, which could be the reason why it is the same error. There are other bugs for the ARM implementation, which I could confirm and was fixed:

Maybe try the latest version of GCC, if you are lucky and manage to compile the compiler :-)

If I compile the code with Visual Studio 2005 for ARM (for a WindowsCE system), your code works, too (needs only one additional "typedef unsigned char uint8_t", because the compiler is not fully ANSI C99 compliant and doesn't know the header file stdint.h).

This is not strictly a bug..

You're violating the C-rules of aliasing. In short: You must not modify a value/stucture of type A and read from the same memory by casting a pointer from A to B. The compiler is allowed to assume that because the types differ the two pointers point to different memory.

I know this is common practice. However, the C-compiler can do anything it wants to in this case. Gcc got a better aliasing analysis backend recently that is more strict about the rules. Lots of old code that depended on this behaviour broke, but even more code improved in performance.. All in all that was a good change.

The way around this is to cast the one of the pointers temporarily to (char *). That's the official way to tell a C-compiler that the data may alias with other data. Char * is the wild-card. Another - more drastic way would be to declare the pointer you read from as volatile, but that effectively disables any optimizations.

FYI: Delacring the pointers as void* may help as well. Also: x86 code often works simply due to the fact that values have to be reloaded from memory due to the lack of registers. The compiler could optimize bit it can't because 7 registers aren't enough... So this is one of the bugs you'll first encounter (if ever) if you compile your code on ARM or MIPS or other architectures that have plenty of registers..

Nils

value/stucture of type A and read from the

assume that because the types differ the two

There is no aliasing issue in the example. You would be right if he accessed both foo and p2 at the same time in a context where the obvious relation between the pointers is not visible (eg. if both are passed to a different function). There is no aliasing, and neither the memcpy nor the initialization of Foo is redundant (as its address is leaked), so it's a compiler bug.

Wilco

Can you cite the chapters in the standard? My first feeling was the same, because using void* worked, but it works with Visual C for ARM, which I think does a good register optimization, too, and Wilco says, it is not an aliasing problem.

In what sense is that "better"? A warning, perhaps, a switch for "strict" mode, but breaking existing code is a stupid thing to do.

JS

Looks like it is a problem with memcpy:

but I'm not sure, if it is a compiler bug. If you specify "-Ono_memcpy" or "-fpack-struct" when compiling your code, there is no bug anymore. I guess the casting of a member of a struct to a struct pointer is dangerous in combination with the built-in memcpy functions.

What the standard says is not relevant. The C standards are consistently and deliberately underspecified, unclear and are more concerned with features that were obsolete 20 years ago (like ones-complement and signed overflow) than actually specifying important features like bitfields. So compiler writers typically add their own rules, the most important of which says "thou shalt correctly compile existing code".

What would be more interesting is the generated code for the cp() function. That would clear up whether it is a bug in memcpy or inter procedural alias analysis.

Btw. The -Ono_memcpy option you mentioned in another post only works on the ARM compiler, which is not based on GCC.

Wilco

If that were always true, compilers could never improve. Breakage of

What a horrible (and dangerous) attitude. Not only that, but inaccurate also.

One of the great problems with C is the failure to catch overflow in signed integral expressions. It is not solvable, because of the necessity of supporting older code. Bitfields are unimportant, because there are adequate replacements available in the form of constants and bit manipulation operations.

One of the strengths of C is the fact that code that meets the requirements of the standard is almost always totally portable. By itself this is not the final word, but it makes it easy to isolate and emphasize what code needs modification during a port.

The standard hasn't changed. Thus 'better' in the sense that code that violates the standard is detected. The code didn't break, it was always broken.

Most compiler optimizations are independent of language semantics, so it's not true compilers could not improve if they had to be conservative. I know for a fact that one can beat compilers with aggressive optimizations (like GCC) by a huge margin while being very conservative.

Of course if you don't use volatile correctly then it's your own fault. Non-conforming code is not the same though. In general incorrect code fails on most compilers when optimizations are enabled, while non-conforming works on most compilers.

Wilco

But the code of the OP demonstrates that sometimes it is difficult to meet the standard. For me it is not clear, if the code is violating the standard. Would be nice, if a compiled source code would behave exactly the same on every platform and for all optimization switches, otherwise the compiler should signal an error for ambiguities.

Is there any other standarized computer language, which is more restrictive defined? Like Java: There are no dangerous pointer operations, alignment and aliasing problems, the size of the basic types are fixed for every platform, the VM is simple and well defined etc. But Java is not a standard, e.g. like the ECMAScript standard (aka JavaScript). Looks like C# and the upcoming C++/CLI are interesting languages, but because of the CLI it would be difficult to use it for small microcontrollers.

Is it possible to define it more restrictive and still fast at all? If "int" would be defined 32 bit for all platforms, but the microcontroller has only 16 bit native registers, this would be slower than a C implementation.

GCC may not be a good example of aggressive optimization. GCC's generic targeting is rarely competative with well targeted specific processor compiler. Penalties of 30% or so in the processors I regularly work with.

The biggest weakness of many C compilers is in error reporting. Good error test suites are much less common than functional testing and syntax testing test suites.

Regards,

-- Walter Banks Byte Craft Limited

But the optimisation possible on non-volatile variables *did* break a lot of code that was out there (and still does, with every improvement to this area of optimisation). So my point stands I think: a "conservative" approach would have left all memory accesses alone, in case they were "important".

I admit I am unclear about the difference here!

... snip ...

Yes. For example, ISO10206. Note that a more complex language is specified in a considerably shorter standard. Yet the language is simpler to use. I am refraining from referencing ISO 7185 because there are usage limitations there.

As referenced above. In your example, if that size of operand is required, the code writer should have specified the long type. Failure to do so is simply a mistake.

Want a warning for that? No problem.

gcc -Wstrict-aliasing ... does exactly what you're asking for.

Try some -Wstrict-overflow for extra fun. You may be surprised how often you depend on non portable behaviour.

Nils

Hm... well. I'm not sure.. He's not explicitely casting from one type to another (that one would be to easy). Instead he copies via a self-written memcpy function.

However, he does his memcpy via the unit8_t type. Isn't that one a built-in type these days? I only know that the compiler is forced to assume aliasing if the data is cast to char* or volatile * something.

I don't have the slightest idea if the compiler can assume aliasing if you copy via uint8_t. It's the same kind of data-type in the end, but afaik char* is special because of the aliasing handling.

I don't have access to the standard, but I know some regular posters do have access. Maybe they can chime in and take a look at this special case..

From the guts I'd still say it's an aliasing issue. I bet it goes away if memcpy is rewritten to use char* instead of unit8_t*.

Cheers, Nils

I think the Pascal syntax is too redundant and you have to think all the time when you have to write ";" or when it is not allowed. And in the ISO10206 text many parts are implementation-defined. Not only the size of integer types, but important things like module activation order. The text contains more than 50 occurances of "implementation-defined". This doesn't look like a very restrictive definition, which allows to compile programs for different implementations without modification, like it is possible with Java.

But this makes programming a lot harder. For writing portable programs, you have to check each statement with the standard definition. In languages like Java you can write tests for the corner cases for one compilation and then you can be sure it works the same on every VM.