Hi all, There is a patch i submitted but it is not merged now[1], this patch will solve this error, but as you know the i386 do not have atomic instruction So atomic related code should not compiled at all, now the check-atomic.m4 will pass check that indicates the i386 support atomic. I will provide a new patch to add compare_and_swap check to avoid this issue.
1. http://www.rtems.org/pipermail/rtems-devel/2013-August/004081.html WeiY Best Regards 在 2013-8-17，下午8:37，Gedare Bloom <ged...@rtems.org> 写道： > 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
