I had a problem that got solved in an ugly way. I think gcc ought
to provide a few ways to make a nicer solution.
There was an array of structs roughly like so:
struct{int w;float x;char y[4];short z[2];}foo[512][4];
The types within the struct are 4 bytes each; I don't actually
remember anythin
On Thu, Sep 30, 2010 at 5:39 AM, Richard Guenther
wrote:
> On Thu, Sep 30, 2010 at 9:54 AM, Albert Cahalan wrote:
>> int weird(float *fp){
>> // access an int as an int (see caller),
>> // so not an aliasing violation
>> return *(int*)fp;
>
int weird(float *fp){
// access an int as an int (see caller),
// so not an aliasing violation
return *(int*)fp;
}
int main(int argc, char *argv[]){
return weird((float*)&argc);
}
I just tried this code with gcc 4.4.5 on 32-bit powerpc using -O2 -W -Wall.
Assembly c
On Sat, Mar 22, 2008 at 8:24 PM, Paul Brook <[EMAIL PROTECTED]> wrote:
> This list is for development of gcc, not gcc users. In future gcc-help, or
> some other arm specific list is the correct place to ask such questions.
I guess it wasn't clear that I'm requesting a new attribute.
I want to for
As far as I can tell, there is no way to declare
that a particular function pointer will point at
plain ARM code or at Thumb code. I'm more
than a little surprised actually, so maybe I just
missed something. How can I do this?
Some background: The function is in ROM.
I'm using a linker script to g
On 11/29/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>> int f(int *a, float *b)
>> {
>> *a = 1;
>> *b = 2.0;
>> return *a == 2;
>> }
>>
>
> Problem: people don't write code that way. (well I hope not)
> People declare a few local variables, load them with data via
> the pointers, do stuff
On 11/28/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> I often need to convince people that gcc is not just
> defective for doing random nonsense to code which
> violates the C and C++ aliasing rules. Not that I'm
> real sure myself actually, given that gcc is able to
> generate warnings for all
I have code that goes something like this:
char *foo(char *buf){
*buf++ = 42;
*((short*)buf) = 0xfeed;
buf += 2;
*((int*)buf) = 0x12345678;
buf += 4;
*((int*)buf) = 0x12345678;
buf += 4;
return buf;
}
The buffer is really of type char. The above comes
from a pile of macro
I often need to convince people that gcc is not just
defective for doing random nonsense to code which
violates the C and C++ aliasing rules. Not that I'm
real sure myself actually, given that gcc is able to
generate warnings for all the normal cases, but anyway...
I'm up against the idea that Vis