Howdy....
Thanks.
This has been already fixed and the code is in CVS.
So, just checkout sources from cvs and recompile gcc or wait till next win 32
build.
As a workaround, you can cast the fifth (sixth, seventh, etc..) vat to int.
~d
On Monday 16 December 2002 05:20, matthew.c...@tekelek.com.au wrote:
> Howdy...
>
> It seems that my code has started giving msp430-gcc a fur ball, which is
> choking upon. This morning porting some functions from one of my previous
> avr-gcc projects it started generating insn errors which I assume are bad !
>
> Here is the scenario... My project is basically split into multiple
> source files. In my adcv.c module you will find the following function.
>
> ----------------------------------------------------------------
>
> void ADCV_InitChannel( u08 Channel, u16 InitialValue, \
> u08 SampleFrequency, u08 TimeConstant, u08 Flags)
> {
> /* code removed to protect the innocent */
> return;
> }
>
> In the adcv.h header file;
>
> extern void ADCV_InitChannel( u08 Channel, u16 InitialValue, \
> u08 SampleFrequency, u08 TimeConstant, u08 Flags);
>
> note:
>
> typedef unsigned char u08;
> typedef unsigned short u16;
>
> ----------------------------------------------------------------
>
> In my other modules (eg temp.c) the function above is called like so;
>
> void TEMP_InitSW(void)
> {
> ADCV_InitChannel(ADCV_TEMP_Channel, TEMP_DEFAULT_ADC, \
> TEMP_SAMPLE_FREQ, TEMP_FILTER_TC, \
> ADCV_ENABLED);
> return;
> }
>
> where
>
> #define ADCV_TEMP_Channel 0
> #define TEMP_DEFAULT_ADC 1936
> #define TEMP_SAMPLE_FREQ 60
> #define TEMP_FILTER_TC 4
> #define ADCV_ENABLED (1<<0)
>
> Note the sample freq, filter timeconst and default filter values change
> depending on module calling the Init Function.
>
> ----------------------------------------------------------------
>
> Now from the output window I get the following when I try to compile the
> above;
>
> msp430-gcc src\adcv.c -g -Os -Wall -fshort-enums -mmcu=msp430x447 \
> -Iinc -Wa,-ahlms=tilst\adcv.lst -c -o tiobj\adcv.o
> msp430-gcc src\temp.c -g -Os -Wall -fshort-enums -mmcu=msp430x447 \
> -Iinc -Wa,-ahlms=tilst\temp.lst -c -o tiobj\temp.o
> src/temp.c: In function `TEMP_InitSW':
> src/temp.c:190: unrecognizable insn:
> (insn 63 62 64 (set (mem/f:QI (pre_modify:HI (reg/f:HI 1 r1)
> (plus:HI (reg/f:HI 1 r1)
> (const_int -2 [0xfffffffe]))) [0 S1 A8])
> (const_int 1 [0x1])) -1 (nil)
> (nil))
> src/temp.c:190: Internal compiler error in extract_insn, at recog.c:2148
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
>
> ----------------------------------------------------------------
>
> My testing has shown that this error revolves around the number of
> variables I am passing to the ADCV_InitChannel() function. If I remove
> one variable ie "u08 Flags" then the code compiles without the insn error.
> eg see below;
>
> void ADCV_InitChannel( u08 Channel, u16 InitialValue, \
> u08 SampleFrequency, u08 TimeConstant)
> {
> /* code removed to protect the innocent */
> return;
> }
>
> void TEMP_InitSW(void)
> {
> ADCV_InitChannel(ADCV_TEMP_Channel, TEMP_DEFAULT_ADC, \
> TEMP_SAMPLE_FREQ, TEMP_FILTER_TC);
> return;
> }
>
> ----------------------------------------------------------------
>
> It does not matter which variable I remove from the function call, I only
> have to reduce the number of variables by one byte and it works. I do not
> believe it to be a variable type problem, just the number I am trying to
> pass.
>
> I have used this code previously and I am happy that all my chickens and
> eggs line up with respect to the relevant includes and dependencies between
> my source modules.
>
> I know that the above function is not efficient, I could pass a pointer and
> prevent this situation, but I was under the impression there were no
> limitations on how many variables can be passed to a function. ie once the
> number of available registers were consumed the compiler would start using
> the stack.
>
> For the time being I will revert to using a pointer to pass the relevant
> data, but I am hoping this is not a bug ?
>
> Cheers
>
> Matthew
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
/********************************************************************
("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ
`6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys
(_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44
_..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia
(il),-'' (li),' ((!.-' +7 (812) 3468202, 5585314
********************************************************************/
