Send a separate email with this bug info, or file a bug report. This is unrelated and was probably introduced by the code changes contributed by Hengyi. -Gedare
On Sat, Aug 17, 2013 at 2:38 AM, Sree Harsha Konduri <sreeh...@buffalo.edu> wrote: > Hello, > > After applying the patch that Joel has sent out, there is a new bug that is > occuring in smpatomic tests. > > The bug is shown below, > > gmake[6]: Entering directory > `/home/harsha/rtems/4.11/pc386/i386-rtems4.11/c/pc386/testsuites/smptests/smpatomic02' > i386-rtems4.11-gcc -B../../../../../pc386/lib/ -specs bsp_specs -qrtems > -DHAVE_CONFIG_H -I. > -I../../../../../../../rtems/c/src/../../testsuites/smptests/smpatomic02 > -I.. > -I../../../../../../../rtems/c/src/../../testsuites/smptests/../support/include > -mtune=i386 -O2 -g -Wall -Wmissing-prototypes > -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT > tasks.o -MD -MP -MF .deps/tasks.Tpo -c -o tasks.o > ../../../../../../../rtems/c/src/../../testsuites/smptests/smpatomic02/tasks.c > In file included from > ../../../../../pc386/lib/include/rtems/score/cpuatomic.h:29:0, > from > ../../../../../pc386/lib/include/rtems/score/atomic.h:21, > from > ../../../../../pc386/lib/include/rtems/rtems/atomic.h:26, > from > ../../../../../../../rtems/c/src/../../testsuites/smptests/smpatomic02/tasks.c:19: > ../../../../../pc386/lib/include/rtems/score/cpustdatomic.h: In function > 'Test_task': > ../../../../../pc386/lib/include/rtems/score/cpustdatomic.h:83:3: error: > invalid memory model for '__atomic_load' > return atomic_load_explicit( object, order ); > ^ > ../../../../../pc386/lib/include/rtems/score/cpustdatomic.h:91:3: error: > invalid memory model for '__atomic_load' > return atomic_load_explicit( object, order ); > ^ > gmake[6]: *** [tasks.o] Error 1 > gmake[6]: Leaving directory > `/home/harsha/rtems/4.11/pc386/i386-rtems4.11/c/pc386/testsuites/smptests/smpatomic02' > gmake[5]: *** [all-recursive] Error 1 > > Thanks, > Sree > > > > On Fri, Aug 16, 2013 at 4:57 PM, Joel Sherrill <joel.sherr...@oarcorp.com> > wrote: >> >> I think the change from #ifdef to #if changed this. >> pc386 set CLOCK_DRIVER_ISRS_PER_TICK to a >> string rather than a numeric value. I added >> CLOCK_DRIVER_ISRS_PER_TICK_VALUE and >> did some other clean up on the driver. >> >> With the attached patch, it compiles again and >> ticker runs. >> >> Please review and let me know if OK to commit. >> >> >> On 8/16/2013 11:03 AM, Gedare Bloom wrote: >>> >>> OK. If you find the bug in the modified clockdrv_shell.h think about >>> how it might be fixed. >>> >>> On Fri, Aug 16, 2013 at 11:49 AM, Vipul Nayyar <nayyar_vi...@yahoo.com> >>> wrote: >>>> >>>> Hello, >>>> >>>> Will look more closely into the matter. >>>> >>>> FWIW, I compiled the pc386 bsp giving the same configure statement as >>>> Sree >>>> gave, in my personal fork of rtems from github which is about 18 or so >>>> commits behind the master( that means my fork does not contain Sebastian >>>> & >>>> Chris' #define -> #if patches). >>>> >>>> And it compiled successfully, without giving any errors. >>>> >>>> What I feel, is that the following two patches that modified >>>> clockdrv_shell.h need to be checked again.. >>>> >>>> http://git.rtems.org/rtems/commit/?id=b7f206097313f794dbe53202542b5894aad6a117 >>>> >>>> http://git.rtems.org/rtems/commit/?id=d473dc0b22d3276130f893a51350c8bfb8beaac8 >>>> >>>> My patches for pc386 were checked carefully by Sebastian, but will have >>>> to >>>> look more closely to find any bug caused due to my patches. >>>> >>>> Regards >>>> Vipul Nayyar >> >> >> >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.com On-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available (256) 722-9985 >> > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
