Hello, can you try a cast like this:
(uint32_t *)(void *)dst This is also used in dsp563xx.c to cast from an uint8_t pointer to a uin32_t pointer. Regards, Mathias On 09.02.2012 18:51, Andrew Parlane wrote: > Hi Peter, > > That's the same conclusion I came to, I just wanted to let the relevant > people know of the issue. > > Slightly confused as to how no one else has seen this yet, I guess it > could be my toolchain being picky. > > Thanks, > Andy > > On 09/02/2012 16:55, Peter Stuge wrote: >> Andrew Parlane wrote: >>> I'm trying to compile openocd for the zy1000, using the current HEAD: >>> f86986a9ef9ca863bad3bec5ffbdea748d011b40 >>> >>> Unfortunately I'm getting an error during compilation. I should add >>> that a few months ago I succeeded in building, and it is only since >>> I pulled the last few months changes in that I came across the >>> problem. >> .. >> >>> The error is: >>> >>> cc1: warnings being treated as errors >>> stm32_stlink.c: In function 'stm32_stlink_read_memory': >>> stm32_stlink.c:648: warning: cast increases required alignment of target >>> type >>> stm32_stlink.c: In function 'stm32_stlink_write_memory': >>> stm32_stlink.c:697: warning: cast increases required alignment of target >>> type >> .. >>> ./configure --enable-ioutil --enable-zy1000 --host=nios2-linux-gnu >> The line currently looks like >> >> res = stlink_if->layout->api->read_mem32(stlink_if->fd, address, c, >> (uint32_t *)dst); >> >> The offending commit is >> >> commit c2ab3b4d5efba0201d88d899dc0fd310574ef5b9 >> Author: Mathias K<[email protected]> >> Date: Thu Jan 12 21:07:57 2012 +0100 >> >> stlink: add none 32bit memory read/write functions >> >> This patch add none 32bit memory read/write functions. >> >> Change-Id: Ie3a761cf006249b30d0691d1ea167d69a012c36a >> Signed-off-by: Mathias K<[email protected]> >> Reviewed-on: http://openocd.zylin.com/367 >> Tested-by: jenkins >> Reviewed-by: Spencer Oliver<[email protected]> >> >> which added the cast, as part of also supporting accesses of sizes >> other than 32 bits. >> >> Assuming that the code worked earlier, it seems that the input >> parameter "buffer" will be correctly aligned anyway. But I guess it's >> not guaranteed, or gcc would not complain. So if read_mem32() is to >> be kept and used, then the calling code must also work with a buffer >> which is guaranteed to be aligned properly. Possibly not so trivial >> to fix. >> >> >> //Peter >> >> ------------------------------------------------------------------------------ >> Virtualization& Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> OpenOCD-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/openocd-devel > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > OpenOCD-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openocd-devel ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
