Bugs item #963769, was opened at 2004-05-31 21:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=963769&group_id=2435
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grigi (grigi)
Assigned to: Nobody/Anonymous (nobody)
Summary: 16bit array handled wrongly
Initial Comment:
Using the gcc 3.4.0 build available on the mingw site:
All other components updated.
I found this bug whilst compiling the Ogg/Vorbis sample
decoder found in the win32 sdk version.
it would take an 16-bit array like this:
__int16 *a=<some allocated region>;
now if you do the following:
a[i]=(some calculation)
or
*a=(some caluculation)
a++
The result is exactly the same.
This was working with previous versions of the GCC
compiler.
Analysing the result: data will be stored like this:
0xXX000000 (in hex) (where XX is the high 8-bits of the
16-bit int)
it doesn't seem to cause a pagefault so I assume it
doesn't treat each 16-bit int as 32-bit.
But doing the following:
__int16 a=()
__int16 b=()
int *c[i]=a<<16+b
would give the correct result.
I have a suspicion this might be related to a bug in
the new 3.4.0 C/C++ parser (semantic phase), as the bug
wasn't present in gcc 3.3.3
Setting optimisation on or off would make NO difference
to the result of this code. so it isn't an optimization
problem.
I have no idea if this is a mingw-only related
regression, as I don't have GCC 3.4.0 on any other
platform.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=963769&group_id=2435
|
