pre-processor symbols and gcc -v

pre-processor symbols and gcc -v

[kevin diggs]

Hi,

If a pre-processor macro, say __m68k__ is defined shouldn't it show up
in gcc -v? gcc version is 3.4.6.

int main(int argc, char **argv)
{
void *handle;
double (*cosine)(double),arg,res;
char *error,*msg="cos(%f)=%.7f\n";

        handle = dlopen ("libm.so", RTLD_LAZY);
        if (!handle)
        {
                fputs (dlerror(), stderr);
                exit(1);
        }

        cosine = dlsym(handle, "cos");
        if ((error = dlerror()) != NULL)
        {
                fprintf (stderr, "%s\n", error);
                exit(1);
        }

        arg=2.0;
        res=(*cosine)(arg);
        printf(msg,arg,res);
        dlclose(handle);

        /*
         * 680x0 constraints are:
         *      a       address register
         *      d       data register
         *      f       floating point
         *      I       integer [1,8]
         *      J       16-bit signed integer
         *      K       signed number whose magnitude is > 0x80
         *      L       integer [-1,-8]
         *      M       signed number whose magnitude is > 0x100
         *      G       non 68881 rom float constant
         * '=' is used to indicate output, '&' means noclobber
         * Some floating point examples are:
         *      ("fsincos" : "=t" (cos), "=u" (sin) : "0" (inp))
         *      ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)")
         */
#ifdef __i386__
        __asm__ __volatile ("fldl (%%edi); fld %%st(0); fcos; "
                "leal -8(%%esp),%%esp; fstpl (%%esp); leal -8(%%esp),%%esp; "
                "fstpl (%%esp); pushl %%esi; call printf; leal 20(%%esp),%%esp"
                :
                :"D" (&arg), "S" (msg));
#elif defined(__m68k__)
#ifdef __HAVE_FPU__
#if defined(__mc68020__) || defined(__mc68030__)
        __asm__ __volatile ("fcos.x %1,%0"
                :"=f" (res)
                :"f" (arg));

        printf(msg,arg,res);
#elif defined(__mc68040__) || defined(__mc68060__)
        __asm__ __volatile ("fcos.x %1,%0"
                :"=f" (res)
                :"f" (arg));

        printf("Instruction implemented by trap:  ");
        printf(msg,arg,res);
#endif
#endif
#endif

#ifdef __m68k__
#error __m68k__ is defined!
#endif

        return 0;
}

Thanks!

kevin

P.S.:  Anyone point me to an example of how to use the 68k 'Q' constraint?

And while I'm here, anyway to see when an instruction causes an
unimplemented instruction trap (like fcos on a 68040)?

Re: pre-processor symbols and gcc -v

[Jonathan Wakely]

On 2 March 2011 20:24, kevin diggs wrote:
> Hi,
>
> If a pre-processor macro, say __m68k__ is defined shouldn't it show up
> in gcc -v? gcc version is 3.4.6.

Are you asking if you should expect to see -D__m68k__ in the commands
displayed by gcc -v?

No, it's probably defined automatically, or failing that defined by a
system header.

Re: pre-processor symbols and gcc -v

[kevin diggs]

On Wed, Mar 2, 2011 at 2:54 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 2 March 2011 20:24, kevin diggs wrote:
>> Hi,
>>
>> If a pre-processor macro, say __m68k__ is defined shouldn't it show up
>> in gcc -v? gcc version is 3.4.6.
>
> Are you asking if you should expect to see -D__m68k__ in the commands
> displayed by gcc -v?
>
Yes, that is exactly what I am asking.

> No, it's probably defined automatically, or failing that defined by a
> system header.
>
My bad. I thought all definitions were passed by the driver to the
pre-processor.

Thanks!

kevin

Re: pre-processor symbols and gcc -v

[Ian Lance Taylor]

kevin diggs <diggskevin38@gmail.com> writes:

> My bad. I thought all definitions were passed by the driver to the
> pre-processor.

Ah, yes, that is how it used to work before the integrated preprocessor.
Well, not every definition, but ones like __m68k__ were indeed passed as
explicit -D options.

Ian

Re: pre-processor symbols and gcc -v

[Ian Lance Taylor]

kevin diggs <diggskevin38@gmail.com> writes:

> If a pre-processor macro, say __m68k__ is defined shouldn't it show up
> in gcc -v? gcc version is 3.4.6.

gcc -v does not list predefined preprocessor macros.  You can see them
by running "gcc -x c /dev/null -E -dM".

> P.S.:  Anyone point me to an example of how to use the 68k 'Q' constraint?

In what sense?  There are various examples in gcc/config/m68k/m68k.md,
e.g., tst<mode>_cf.

> And while I'm here, anyway to see when an instruction causes an
> unimplemented instruction trap (like fcos on a 68040)?

I guess I don't understand the question.

Ian

Re: pre-processor symbols and gcc -v

[kevin diggs]

Hi,

As always thank you VERY much for taking the time to share your VAST
array of knowledge! I REALLY do appreciate it!!! (You to Jonathon)

On Wed, Mar 2, 2011 at 3:15 PM, Ian Lance Taylor <iant@google.com> wrote:
> kevin diggs <diggskevin38@gmail.com> writes:
>
>> If a pre-processor macro, say __m68k__ is defined shouldn't it show up
>> in gcc -v? gcc version is 3.4.6.
>
> gcc -v does not list predefined preprocessor macros.  You can see them
> by running "gcc -x c /dev/null -E -dM".
>
I am trying to figure out if I should apologize for being to stupid to
figure this out. In my defense and in this case I can't build the
documentation (gcc 3.4.6 on an old Quadra 700 (mc68040)). makeinfo or
some such thing is missing. I think it also wants perl. Like I have
enough disk space on this thing to install (or build) that.

Did this change when the pre-processor moved into cc1?

>> P.S.:  Anyone point me to an example of how to use the 68k 'Q' constraint?
>
> In what sense?  There are various examples in gcc/config/m68k/m68k.md,
> e.g., tst<mode>_cf.
>
I apologize for the vagueness. I am referring to usage in embedded asm.

        asm volatile("fmoveml %%fpcr/%%fpsr,%0@\n"
                :
                :"a"(save)
        );

Q is address register indirect. I thought I could write this:

fmoveml %%fpcr/%%fpsr,%0\n"
:
:"Q"(save)

The compiler pitched a major league hissy fit though:

fmoveml.c: In function `f':
fmoveml.c:14: error: impossible constraint in `asm'

Are some of these constraints meant to be used only in md files?

>> And while I'm here, anyway to see when an instruction causes an
>> unimplemented instruction trap (like fcos on a 68040)?
>
> I guess I don't understand the question.
>
> Ian
>
Using ktruss dltest will show lots of diagnostic stuff. If I
understand it, on a 68040 the fcos instruction has to implemented by a
trap of some sort. Is there any utility that I can see these happen
analogous to what ktruss does for system calls?

Thanks!

kevin

Re: pre-processor symbols and gcc -v

[Ian Lance Taylor]

kevin diggs <diggskevin38@gmail.com> writes:

> As always thank you VERY much for taking the time to share your VAST
> array of knowledge! I REALLY do appreciate it!!! (You to Jonathon)

You're welcome.


>> gcc -v does not list predefined preprocessor macros.  You can see them
>> by running "gcc -x c /dev/null -E -dM".
>>
> I am trying to figure out if I should apologize for being to stupid to
> figure this out. In my defense and in this case I can't build the
> documentation (gcc 3.4.6 on an old Quadra 700 (mc68040)). makeinfo or
> some such thing is missing. I think it also wants perl. Like I have
> enough disk space on this thing to install (or build) that.

The gcc 3.4.6 manual is online at
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/ .

But the -dM command sequence is a bit cryptic.

> Did this change when the pre-processor moved into cc1?

Hmmm.  I'm not sure.  I think it may have worked even before then.


> I apologize for the vagueness. I am referring to usage in embedded asm.
>
>         asm volatile("fmoveml %%fpcr/%%fpsr,%0@\n"
>                 :
>                 :"a"(save)
>         );
>
> Q is address register indirect. I thought I could write this:
>
> fmoveml %%fpcr/%%fpsr,%0\n"
> :
> :"Q"(save)
>
> The compiler pitched a major league hissy fit though:
>
> fmoveml.c: In function `f':
> fmoveml.c:14: error: impossible constraint in `asm'
>
> Are some of these constraints meant to be used only in md files?

You can use "Q" with inline asm, but you have to pass it an operand
which is in memory.  Try passing &save rather than save.  I don't know
if that will work, but something along those lines might.


>>> And while I'm here, anyway to see when an instruction causes an
>>> unimplemented instruction trap (like fcos on a 68040)?
>>
>> I guess I don't understand the question.
>>
> Using ktruss dltest will show lots of diagnostic stuff. If I
> understand it, on a 68040 the fcos instruction has to implemented by a
> trap of some sort. Is there any utility that I can see these happen
> analogous to what ktruss does for system calls?

I don't know.  Sorry.

Ian