This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re : questions about gcalc front end





----- Message d'origine ----
De : Philip Herron <redbrain@gcc.gnu.org>
À : Andre-Marcel Hellmund <mail@andihellmund.com>
Cc : charfi asma <charfiasma@yahoo.fr>; gcc-help@gcc.gnu.org
Envoyé le : Ven 17 septembre 2010, 16h 12min 28s
Objet : Re: questions about gcalc front end

On 17 September 2010 14:54, Andre-Marcel Hellmund <mail@andihellmund.com> wrote:
> Hey Asma,
>>
>> I tried to compile a .gcal file using gcalc fe.
>> test.gcal contains only x=2;
>>
>> [root@is010178 Gcalc]# /usr/local/bin/gcal -S -fdump-tree-all t.gcal
>> calc1: note: primary: INTEGER
>> calc1: note: expression: primary
>> calc1: note: expression: expression '=' expression
>> calc1: note: statements: statements stmt
>>
>
> Great that it works without any errors so far ;-)
>>
>> when I look at gimple and generic IR I notice that it is not the same
>> structure
>> (as Philip said).
>> I red last year papers in the GCC summit saying that gimple and generic
>> have the
>> same grammar with some restriction in gimple: only 3 adress structure are
>> allowed, ...
>> but I can see here that Generic is a composed of tree codes
>> (function_decl,
>> integer_cst, ...) however gimple is a set of gimple instruction that are
>> different from tree code (gimple_assign, gimple_bind,... )
>>
>
> I'm not sure which papers (which year?) you read, but yes, there are some
> older papers which state that GIMPLE and GENERIC share the same structure.
> From what I know, this was true for the first versions of GIMPLE, it was
> redesigned in 2008 to be tuple-based instead of tree-based. The single
> GIMPLE-tuples however then use the GENERIC (sub)trees as operands.
>>
>> My questions are:
>>
>> 1. Is this difference due to changes applyed to Gimple that becomes based
>> on
>> tuples rather than trees ?
>>
>
> Yes, I think so ...
>>
>> 2. what is the function (in the gcalc fe) that transform generic to gimple
>> ?
>>
>
> The main function for the transformation of single functions is
> gimplify_function_tree, while the real worker function is gimplify_expr
> (attention: this function is very complex!!!)
>>
>> 3. when I want to generate the executable from x=2 (I omit the -S option)
>> I get
>> this error (linker error)
>>
>> [root@is010178 Gcalc]# /usr/local/bin/gcal -fdump-tree-all t.gcal
>> calc1: note: primary: INTEGER
>> calc1: note: expression: primary
>> calc1: note: expression: expression '=' expression
>> calc1: note: statements: statements stmt
>> /usr/bin/ld: cannot find -lgcalc
>>
>
> Ohhh, thanks for catching this. The gcalc demonstration front-end is still
> work in progress and we need to improve the runtime-library interaction. It
> seems that the runtime library wasn't built. As a workaround, do
>
> # /usr/local/bin/gcal -fdump-tree-all t.gcal -v
>
> And then copy+paste the ld/collect2 command while omitting the -lgcalc. This
> should then work. We'll obviously improve this ;-)
>

Hmm maybe i need to look at the compiler driver again, though it works
on my end fine well on my laptop haven't installed it on my desktop.
The way i like to think of the two IR's is that GENERIC is a Directed
Acyclic Graph as in an expression such as <x = 1 + 2;> will produce
something like, you may want to look at our front-end documentation in
the internals manual within the gcalc git branch (its in
gcc/doc/languages.texi)

  =
/   \
x   +
    /  \
   1    2

So its a more semantic level operation, where as Gimple will produce:

t1 = 1 + 2
x = t1

Well this is highly simplified but its the way i tend to think of them.

--Phil

Hello,

this is the result of # /usr/local/bin/gcal t.gcal -fdump-tree-all -v

[root@is010178 Gcalc]# /usr/local/bin/gcal t.gcal -fdump-tree-all -v
Driving: /usr/local/bin/gcal t.gcal -fdump-tree-all -v -l gcalc -l m
Utilisation des specs internes.
COLLECT_GCC=/usr/local/bin/gcal
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configuré avec: ../gcc-dev/configure --enable-languages=python --disable-werror 
: (reconfigured) ../gcc-dev/configure --enable-languages=c,c++,python,gcalc 
--disable-werror
Modèle de thread: posix
gcc version 4.6.0 20100907 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-fdump-tree-all' '-v' '-mtune=generic' '-march=pentiumpro'
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/calc1 t.gcal -quiet -dumpbase 
t.gcal -mtune=generic -march=pentiumpro -auxbase t -version -fdump-tree-all -o 
/root/tmp/cc7sQ8S2.s
GNU Calc Frontend (GCC) version 4.6.0 20100907 (experimental) 
(i686-pc-linux-gnu)
    compiled by GNU C version 4.6.0 20100907 (experimental), GMP version 4.3.2, 
MPFR version 2.4.2, MPC version 0.8.1
heuristiques GGC: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Calc Frontend (GCC) version 4.6.0 20100907 (experimental) 
(i686-pc-linux-gnu)
    compiled by GNU C version 4.6.0 20100907 (experimental), GMP version 4.3.2, 
MPFR version 2.4.2, MPC version 0.8.1
heuristiques GGC: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
calc1: note: primary: INTEGER
calc1: note: expression: primary
calc1: note: expression: expression '=' expression
calc1: note: statements: statements stmt
COLLECT_GCC_OPTIONS='-fdump-tree-all' '-v' '-mtune=generic' '-march=pentiumpro'
 as -V -Qy --32 -o /root/tmp/ccI2mN5Y.o /root/tmp/cc7sQ8S2.s
GNU assembler version 2.19.51.0.2 (i586-mandriva-linux-gnu) using BFD version 
(Linux/GNU Binutils) 2.19.51.0.2.20090204
COMPILER_PATH=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/libexec/gcc/i686-pc-linux-gnu/:/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/lib/gcc/i686-pc-linux-gnu/

LIBRARY_PATH=/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/

COLLECT_GCC_OPTIONS='-fdump-tree-all' '-v' '-mtune=generic' '-march=pentiumpro'
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m 
elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o 
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/crtbegin.o 
-L/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0 
-L/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../.. /root/tmp/ccI2mN5Y.o 
-lgcalc -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed 
-lgcc_s --no-as-needed /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/crtend.o 
/usr/lib/crtn.o
/usr/bin/ld: cannot find -lgcalc
collect2: ld a retourné 1 code d'état d'exécution

I do not realy understand how can I copy+paste the ld/collect2 command while 
omitting the -lgcalc ?? should I add to the command gcal t.gcal the option :

-L/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m 
elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o 
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/crtbegin.o 
-L/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0 
-L/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../.. /root/tmp/ccI2mN5Y.o 
-lgcalc -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed 
-lgcc_s --no-as-needed /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/crtend.o 
/usr/lib/crtn.o 


and ommit -lgcalc ??

THANKS

ASMA





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]