Current head compilation problem

[Gedare Bloom]

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
<sreehars at 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.sherrill at 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_vipul at 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.sherrill at OARcorp.com        On-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available                (256) 722-9985
>>
>