mysterious error while compiling device driver

[yeah]

hi all
I am working with linux environment and i compiled device driver
programs using native compiler "gcc".In one of my macro i have these
lines

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too low!
#endif

while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.
plz Help me to eliminate this error...

[Martin Ambuhl]

yeah wrote:

hi all
I am working with linux environment and i compiled device driver
programs using native compiler "gcc".In one of my macro i have these
lines

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too low!
#endif

while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.
plz Help me to eliminate this error...

Whatever the nonstandard macro HARDIRQ_BITS is defined as seems to be to
low, unless your code is lying to you. Defining it to be a large enough
value will make the error message go away. What other behavior that
might introduce is another question.

[Martin Wells]

yeah:

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too low!
#endif

The logic seems very strange here. I would have expected:

#if (1u << HARDIRQ_BITS) MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too high!
#endif

while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.
plz Help me to eliminate this error...

Purchase a fully-functional human brain with an intelligence rating
higher than 5. With such a device, I think you'd clearly see that
either:

1: HARDIRQ_BITS is too small
2: MAX_HARDIRQS_PE R_CPU is too big

(...that's assuming your logic is right)

And I'd advocate not to do bitshifting on signed integers, I'd prefer
"1u << ".

Martin

[Mark Bluemel]

yeah wrote:

hi all
I am working with linux environment and i compiled device driver
programs using native compiler "gcc".In one of my macro i have these
lines

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too low!
#endif

while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.

Of course it means a particular type of error. But it's not really one
which we as a newsgroup are particularly well-placed to help you resolve.

plz Help me to eliminate this error...

I'm sure someone will be along to castigate me for this, but to
paraphrase the great Obi-Wan Kenobi "this is not the newsgroup you are
looking for".

In fact it's doubtful that a newsgroup is the right place to look at all.

How about contacting the originator of the code? (I assume you didn't
write it as otherwise you'd know what the error implied).

Alternatively, a brief scan with Google indicates that there's a fair
amount of information about this stuff on the web.

[Erik Trulsson]

Martin Wells <wa****@eircom. netwrote:

yeah:

>#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too low!
#endif

The logic seems very strange here. I would have expected:

#if (1u << HARDIRQ_BITS) MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too high!
#endif

That depends on what the rest of the code does. My guess
is that test is to see that HARDIRQ_BITS is large enough to
keep track of all the possible HARDIRQS, in which case the
logic is right.

>

>while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.
plz Help me to eliminate this error...

Purchase a fully-functional human brain with an intelligence rating
higher than 5. With such a device, I think you'd clearly see that
either:

1: HARDIRQ_BITS is too small
2: MAX_HARDIRQS_PE R_CPU is too big

(...that's assuming your logic is right)

And I'd advocate not to do bitshifting on signed integers, I'd prefer
"1u << ".

Martin

--
<Insert your favourite quote here.>
Erik Trulsson
er******@studen t.uu.se

[yeah]

On Oct 3, 1:08 pm, Martin Wells <war...@eircom. netwrote:

yeah:

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too low!
#endif

The logic seems very strange here. I would have expected:

#if (1u << HARDIRQ_BITS) MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too high!
#endif

while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.
plz Help me to eliminate this error...

Purchase a fully-functional human brain with an intelligence rating
higher than 5. With such a device, I think you'd clearly see that
either:

1: HARDIRQ_BITS is too small
2: MAX_HARDIRQS_PE R_CPU is too big

(...that's assuming your logic is right)

And I'd advocate not to do bitshifting on signed integers, I'd prefer
"1u << ".

Martin

hi martin:

First understand that the error is not while running but during the
compilation.
So no matter whether the condition is true or false.

thanks

[santosh]

yeah wrote:

On Oct 3, 1:08 pm, Martin Wells <war...@eircom. netwrote:

>yeah:

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too low!
#endif

The logic seems very strange here. I would have expected:

#if (1u << HARDIRQ_BITS) MAX_HARDIRQS_PE R_CPU
# error HARDIRQ_BITS is too high!
#endif

while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.
plz Help me to eliminate this error...

Purchase a fully-functional human brain with an intelligence rating
higher than 5. With such a device, I think you'd clearly see that
either:

1: HARDIRQ_BITS is too small
2: MAX_HARDIRQS_PE R_CPU is too big

(...that's assuming your logic is right)

And I'd advocate not to do bitshifting on signed integers, I'd prefer
"1u << ".

hi martin:

First understand that the error is not while running but during the
compilation. So no matter whether the condition is true or false.

Martin perfectly understands the code. It you who is not understanding. A
conforming compiler is required to abort translation when it encounters an
active #error directive.

In the case of this code the conditional following the #if directive
apparently is true, hence the #error directive is selected and hence
translation stops.

Your solution involves understanding exactly what the conditional means,
semantically, and doing what is necessary to prevent the statement from
resolving to true. This involves information specific to your system and
the program in question and we cannot give any answer from the perspective
of Standard C.

Also it's better to supply a string literal to the #error directive than a
sequence of token like you've done above.

[Martin Wells]

yeah:

hi martin:

First understand that the error is not while running but during the
compilation.
So no matter whether the condition is true or false.

thanks

My troll-o-meter is starting to beep a little... but I'll give you one
last try.

If you don't understand the following, then I think you should take up
gardening.

#define ROWS 5
#define COLS 6

#if COLS ROWS
# error "Can't have more columns than rows!"
#endif

This is EXACTLY what's happening in your code.

Martin

[Richard Heathfield]

santosh said:

A conforming compiler is required to abort translation when it encounters
an active #error directive.

Only in C99. Astonishingly, this is *not* required in C90. (Nevertheless,
C90 compilers are free to stop translation if they wish, and I don't know
of any that don't.)

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Old Wolf]

On Oct 4, 1:24 am, Richard Heathfield <[e-mail].i nvalidwrote:

santosh said:

A conforming compiler is required to abort translation when it encounters
an active #error directive.

Only in C99. Astonishingly, this is *not* required in C90. (Nevertheless,
C90 compilers are free to stop translation if they wish, and I don't know
of any that don't.)

The one I'm using currently reports the #error but then
continues to translate the rest of the file. It does
report a failure code to the caller though, so the 'make'
system stops the build after that.

The command is:
arm-linux-unknown-gnu-gcc-3.4.4 -c -std=c89 -Os -Wall

and a handful of other warnings and CPU-specific code
generation flags.