Menu
▾
▴
gcc4cli-devel — Discussions on development issues of the project
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(6) |
Feb
(4) |
Mar
(46) |
Apr
(2) |
May
|
Jun
(4) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(21) |
Mar
(2) |
Apr
|
May
(19) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Gabriele S. <gab...@gm...> - 2010-02-19 08:04:02
|
2010/2/19 Erven Rohou <erv...@in...>: > Ciao, > > Many benchmarks (unfortunately) use setjmp and longjmp, which we do not support. > However, longjmp is often used to handle exceptional situations, mostly errors. > Here is a proposal: we could define setjmp to return 0, and longjmp to abort (or > print a message and abort,...) We could compile and run benchmarks that do not > have errors. Probably we keep a warning in the header file. > What do you think? Sounds like a good idea, I believe most of the stuff will work well under normal conditions. Gabriele |
|
From: Erven R. <erv...@in...> - 2010-02-19 08:00:01
|
Ciao, Many benchmarks (unfortunately) use setjmp and longjmp, which we do not support. However, longjmp is often used to handle exceptional situations, mostly errors. Here is a proposal: we could define setjmp to return 0, and longjmp to abort (or print a message and abort,...) We could compile and run benchmarks that do not have errors. Probably we keep a warning in the header file. What do you think? -- Erven. |
|
From: Erven R. <erv...@in...> - 2010-01-27 08:31:22
|
For the record: I think Andrea convinced himself that it could be a problem in
our linker.
--
Erven.
Andrea Carlo Ornstein a écrit :
> If I recall it correctly it is an error of ilasm, it does not
> recognize the signature correctly.
> I think I inserted it in novell bugzilla, but I am not sure.
>
> I remember that Dotgnu had the same problem
> and I have a hack in the mono linker for it.
> (the difference is that Dotgnu generates an incomplete assembly that I
> can fix, mono ilasm just breaks)
>
> Andrea
>
>
> On Wed, Jan 20, 2010 at 5:05 PM, Erven Rohou <erv...@in...> wrote:
>> Ciao a tutti,
>>
>> the following piece of code does not link when -DBUG is passed (ie when the
>> vararg method is static): "Error: Can't find method: foo"
>> This vaguely reminds me something. Is it just me? Do you also remember a problem
>> like this?
>>
>> [Note: this is cc.c-torture/execute/va-arg-11.c]
>>
>> Thanks,
>>
>> --
>> Erven.
>>
>>
>>
>> #include <stdarg.h>
>> #include <stdlib.h>
>>
>> #ifdef BUG
>> static
>> #endif
>> int foo (int a, ...)
>> {
>> va_list va;
>> int i, res;
>>
>> va_start (va, a);
>>
>> for (i = 0; i < 4; ++i)
>> (void) va_arg (va, int);
>>
>> res = va_arg (va, int);
>> va_end (va);
>> return res;
>> }
>>
>> int
>> main (void)
>> {
>> if (foo (5, 4, 3, 2, 1, 0))
>> abort ();
>> exit (0);
>> }
|
|
From: Thierry L. <thi...@in...> - 2010-01-22 13:26:57
|
Ciao a tutti, FYI, I've just commited the attached patch on our branch. It's a trivial fix for test gcc.dg/20020312-2.c I'm not to send this patch to gcc-patches, but tell me if I should. Regards, Thierry Lafage. |
|
From: Erven R. <erv...@in...> - 2010-01-21 08:32:55
|
Hi Andrea,
I checked all the bug you entered in the Novell Bugzilla. Several seem related
(pinvoke varargs, or vararg fun called without parameters), but I could not find
this one. Do you mind taking a look? If it is not entered, I'll submit it.
But how can you tell it is ilasm? When I disassemble the .o (cil32-objdump or
parse.NET), the only difference I can see it the flag of method foo: private or
public.
--
Erven.
Andrea Carlo Ornstein a écrit :
> If I recall it correctly it is an error of ilasm, it does not
> recognize the signature correctly.
> I think I inserted it in novell bugzilla, but I am not sure.
>
> I remember that Dotgnu had the same problem
> and I have a hack in the mono linker for it.
> (the difference is that Dotgnu generates an incomplete assembly that I
> can fix, mono ilasm just breaks)
>
> Andrea
>
>
> On Wed, Jan 20, 2010 at 5:05 PM, Erven Rohou <erv...@in...> wrote:
>> Ciao a tutti,
>>
>> the following piece of code does not link when -DBUG is passed (ie when the
>> vararg method is static): "Error: Can't find method: foo"
>> This vaguely reminds me something. Is it just me? Do you also remember a problem
>> like this?
>>
>> [Note: this is cc.c-torture/execute/va-arg-11.c]
>>
>> Thanks,
>>
>> --
>> Erven.
>>
>>
>>
>> #include <stdarg.h>
>> #include <stdlib.h>
>>
>> #ifdef BUG
>> static
>> #endif
>> int foo (int a, ...)
>> {
>> va_list va;
>> int i, res;
>>
>> va_start (va, a);
>>
>> for (i = 0; i < 4; ++i)
>> (void) va_arg (va, int);
>>
>> res = va_arg (va, int);
>> va_end (va);
>> return res;
>> }
>>
>> int
>> main (void)
>> {
>> if (foo (5, 4, 3, 2, 1, 0))
>> abort ();
>> exit (0);
>> }
>>
>>
|
|
From: Andrea C. O. <and...@gm...> - 2010-01-20 16:48:09
|
If I recall it correctly it is an error of ilasm, it does not
recognize the signature correctly.
I think I inserted it in novell bugzilla, but I am not sure.
I remember that Dotgnu had the same problem
and I have a hack in the mono linker for it.
(the difference is that Dotgnu generates an incomplete assembly that I
can fix, mono ilasm just breaks)
Andrea
On Wed, Jan 20, 2010 at 5:05 PM, Erven Rohou <erv...@in...> wrote:
> Ciao a tutti,
>
> the following piece of code does not link when -DBUG is passed (ie when the
> vararg method is static): "Error: Can't find method: foo"
> This vaguely reminds me something. Is it just me? Do you also remember a problem
> like this?
>
> [Note: this is cc.c-torture/execute/va-arg-11.c]
>
> Thanks,
>
> --
> Erven.
>
>
>
> #include <stdarg.h>
> #include <stdlib.h>
>
> #ifdef BUG
> static
> #endif
> int foo (int a, ...)
> {
> va_list va;
> int i, res;
>
> va_start (va, a);
>
> for (i = 0; i < 4; ++i)
> (void) va_arg (va, int);
>
> res = va_arg (va, int);
> va_end (va);
> return res;
> }
>
> int
> main (void)
> {
> if (foo (5, 4, 3, 2, 1, 0))
> abort ();
> exit (0);
> }
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
>
|
|
From: Erven R. <erv...@in...> - 2010-01-20 16:05:26
|
Ciao a tutti,
the following piece of code does not link when -DBUG is passed (ie when the
vararg method is static): "Error: Can't find method: foo"
This vaguely reminds me something. Is it just me? Do you also remember a problem
like this?
[Note: this is cc.c-torture/execute/va-arg-11.c]
Thanks,
--
Erven.
#include <stdarg.h>
#include <stdlib.h>
#ifdef BUG
static
#endif
int foo (int a, ...)
{
va_list va;
int i, res;
va_start (va, a);
for (i = 0; i < 4; ++i)
(void) va_arg (va, int);
res = va_arg (va, int);
va_end (va);
return res;
}
int
main (void)
{
if (foo (5, 4, 3, 2, 1, 0))
abort ();
exit (0);
}
|
|
From: Thierry L. <thi...@in...> - 2010-01-18 17:31:54
|
Hi, I've just commited the patch we discussed concerning source location information in our branch (including fixes wrt. coding guidelines). Regards, Thierry Lafage. Gabriele Svelto a écrit : > 2009/12/14 Thierry LAFAGE <thi...@in...>: > >> Ok. Thanks. >> I'll try to comply with those quite annoying formatting rules (have to >> better tune my IDE). >> > > Yes, it's the easiest thing to avoid problems, also ensure that the > editor always trims trailing spaces when saving files, there a few > places in GCCs were trailing spaces were left and nobody modified them > for a long time in order not to make merges harder (yeah, it's > completely crazy). > > >> Concerning location information directly from gimple, I hope that this >> information will be correct and accurate in 4.5 since it does not seem to be >> the case at the moment (for this reason I had to pick it into the tree >> representation). If the gimple2cil pass is rewritten to comply with version >> 4.5 then I'll make my code comply to it too. >> > > I have checked in GCC trunk's svn history and apparently > gimple_to_tree() has already been removed so 4.5 won't have the > GIMPLE->TREE->RTL scheme anymore (GIMPLE->TREE->CLI). I was wondering > how they do get proper location information on the other hand because > the TREE from which you extract the source location has been built > from GIMPLE statements. Looking at the old code apparently source > location information was converted from GIMPLE back into the TREE > representation at the bottom of the gimple_to_tree() function in > cfgexpand.c. Here's the relevant snippet: > > /* Set EXPR_LOCATION in all the embedded expressions. */ > loc = gimple_location (stmt); > walk_tree (&t, set_expr_location_r, (void *) &loc, NULL); > > Ciao! > > Gabriele > |
|
From: Erven R. <erv...@in...> - 2009-12-18 16:54:15
|
With mono-2.6 you had 44385 PASS and 1248 FAIL. My latest run with mono-2.4.2.3 had 44375 PASS and 1256 FAIL, with some variability. So we are within the noise. Ciao, -- Erven. Gabriele Svelto a écrit : > Here's the gcc.sum and gcc.log results of mono-2.6. I tested it > tonight on my laptop (Fedora 10/i386), I don't want to know how much > time it took... If I have more time I will compile mono-2.6 with the > LLVM back-end and do another test run to see if the results differ > from Mono's built-in JIT compiler. > > Gabriele > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel |
|
From: Gabriele S. <gab...@gm...> - 2009-12-17 18:54:51
|
2009/12/17 Erven Rohou <erv...@in...>: > Ciao Gabriele, > > What is the .xz extension? :-) The .lzma prefix under a different name ;-). On a more serious note it's an excellent compressor which is replacing bzip2 (for example the .rpm and .deb packages for the latest Fedora/Ubuntu distributions use it instead of bzip2). The tool (xz) works just like gzip/bzip2 and is available in the xz-utils package in the Debian-based distros and in the xz package in the Red Hat-based ones. Gabriele |
|
From: Erven R. <erv...@in...> - 2009-12-17 18:32:52
|
Ciao Gabriele, What is the .xz extension? :-) -- Erven. Gabriele Svelto a écrit : > Here's the gcc.sum and gcc.log results of mono-2.6. I tested it > tonight on my laptop (Fedora 10/i386), I don't want to know how much > time it took... If I have more time I will compile mono-2.6 with the > LLVM back-end and do another test run to see if the results differ > from Mono's built-in JIT compiler. > > Gabriele > |
|
From: Gabriele S. <gab...@gm...> - 2009-12-17 07:57:33
|
Here's the gcc.sum and gcc.log results of mono-2.6. I tested it tonight on my laptop (Fedora 10/i386), I don't want to know how much time it took... If I have more time I will compile mono-2.6 with the LLVM back-end and do another test run to see if the results differ from Mono's built-in JIT compiler. Gabriele |
|
From: Gabriele S. <gab...@gm...> - 2009-12-16 10:14:22
|
See here: http://tirania.org/blog/archive/2009/Dec-15.html I will try to build it this afternoon and maybe launch the test suites tomorrow, I will post the results ASAP. I hope that they have fixed a few of the bugs which had been introduced in 2.4 and which came to bite us. Gabriele |
|
From: Gabriele S. <gab...@gm...> - 2009-12-14 09:57:37
|
2009/12/14 Thierry LAFAGE <thi...@in...>: > Ok. Thanks. > I'll try to comply with those quite annoying formatting rules (have to > better tune my IDE). Yes, it's the easiest thing to avoid problems, also ensure that the editor always trims trailing spaces when saving files, there a few places in GCCs were trailing spaces were left and nobody modified them for a long time in order not to make merges harder (yeah, it's completely crazy). > Concerning location information directly from gimple, I hope that this > information will be correct and accurate in 4.5 since it does not seem to be > the case at the moment (for this reason I had to pick it into the tree > representation). If the gimple2cil pass is rewritten to comply with version > 4.5 then I'll make my code comply to it too. I have checked in GCC trunk's svn history and apparently gimple_to_tree() has already been removed so 4.5 won't have the GIMPLE->TREE->RTL scheme anymore (GIMPLE->TREE->CLI). I was wondering how they do get proper location information on the other hand because the TREE from which you extract the source location has been built from GIMPLE statements. Looking at the old code apparently source location information was converted from GIMPLE back into the TREE representation at the bottom of the gimple_to_tree() function in cfgexpand.c. Here's the relevant snippet: /* Set EXPR_LOCATION in all the embedded expressions. */ loc = gimple_location (stmt); walk_tree (&t, set_expr_location_r, (void *) &loc, NULL); Ciao! Gabriele |
|
From: Thierry L. <thi...@in...> - 2009-12-14 09:43:48
|
Ok. Thanks.
I'll try to comply with those quite annoying formatting rules (have to
better tune my IDE).
Concerning location information directly from gimple, I hope that this
information will be correct and accurate in 4.5 since it does not seem
to be the case at the moment (for this reason I had to pick it into the
tree representation). If the gimple2cil pass is rewritten to comply with
version 4.5 then I'll make my code comply to it too.
Thierry Lafage.
Le 14/12/2009 10:29, Gabriele Svelto a écrit :
> 2009/12/14 Thierry LAFAGE<thi...@in...>:
>
>> Hi Gabriele,
>>
>> Thanks for your remarks. What kind of coding guidelines do you think of?
>> I can fix them before ciing.
>>
>> Thierry Lafage.
>>
> Some lines are longer than 80 characters, those should be split on two
> lines (there are many places were this is done so you can follow the
> style used in those lines). I also noticed a couple of places were you
> have left a multi-line statement without putting brackets around it,
> for example:
>
> if (TREE_CODE (node) == REALPART_EXPR)
> stmt = cil_build_stmt_arg (CIL_LDFLDA,
> cil_get_builtin_complex_real_fld (type));
>
> Should be:
>
> if (TREE_CODE (node) == REALPART_EXPR)
> {
> stmt = cil_build_stmt_arg (CIL_LDFLDA,
> cil_get_builtin_complex_real_fld (type));
> }
>
> BTW the same line has 8 spaces in front of the new statement, in GCC
> you should use 2, 4 or 6 spaces when indenting and insert a tabulator
> every 8 spaces. Finally a space is always left between the name of a
> function and the arguments, e.g.:
>
> cil_set_locus(stmt, sloc);
>
> Should become:
>
> cil_set_locus (stmt, sloc);
>
> I know it's annoying, GCC coding guidelines are very quirky but it's
> better to stick to them because it simplifies merges with the
> mainline. You will get used to them eventually ;-)5
>
> Just a final remark which you might find interesting for your future
> work. In our gimple-to-CIL phase we turn GIMPLE nodes into TREE nodes
> for simplicity because our original work was done in a time when this
> was not necessary because GIMPLE statements were 'special' tree nodes,
> now they are specific structures on the other hand. However even if
> GIMPLE nodes have their own structures the functionality used for
> turning them into trees was left into GCC because nobody wanted to
> rewrite the pass (expand) that turned GIMPLE code into RTL code (the
> lower-level GCC IR). I haven't been able to follow closely the latest
> GCC development but it is entirely possible that in version 4.5 that
> pass will have been rewritten and GIMPLE-to-tree functionality
> removed. We will have to rewrite the gimple2cil to accomodate for this
> in the future and the source location information will also have to
> come from GIMPLE so I suggest that you investigate (starting from
> gimple_location() and friends) if your work can be adapted to it. I
> believe it should be possible and fairly easy; in fact when we will
> have to deal with only GIMPLE nodes the whole pass should be simpler
> (and we will need a much better stack-promotion pass!). Ciao!
>
> Gabriele
>
|
|
From: Gabriele S. <gab...@gm...> - 2009-12-14 09:30:29
|
2009/12/14 Thierry LAFAGE <thi...@in...>:
> Hi Gabriele,
>
> Thanks for your remarks. What kind of coding guidelines do you think of?
> I can fix them before ciing.
>
> Thierry Lafage.
Some lines are longer than 80 characters, those should be split on two
lines (there are many places were this is done so you can follow the
style used in those lines). I also noticed a couple of places were you
have left a multi-line statement without putting brackets around it,
for example:
if (TREE_CODE (node) == REALPART_EXPR)
stmt = cil_build_stmt_arg (CIL_LDFLDA,
cil_get_builtin_complex_real_fld (type));
Should be:
if (TREE_CODE (node) == REALPART_EXPR)
{
stmt = cil_build_stmt_arg (CIL_LDFLDA,
cil_get_builtin_complex_real_fld (type));
}
BTW the same line has 8 spaces in front of the new statement, in GCC
you should use 2, 4 or 6 spaces when indenting and insert a tabulator
every 8 spaces. Finally a space is always left between the name of a
function and the arguments, e.g.:
cil_set_locus(stmt, sloc);
Should become:
cil_set_locus (stmt, sloc);
I know it's annoying, GCC coding guidelines are very quirky but it's
better to stick to them because it simplifies merges with the
mainline. You will get used to them eventually ;-)5
Just a final remark which you might find interesting for your future
work. In our gimple-to-CIL phase we turn GIMPLE nodes into TREE nodes
for simplicity because our original work was done in a time when this
was not necessary because GIMPLE statements were 'special' tree nodes,
now they are specific structures on the other hand. However even if
GIMPLE nodes have their own structures the functionality used for
turning them into trees was left into GCC because nobody wanted to
rewrite the pass (expand) that turned GIMPLE code into RTL code (the
lower-level GCC IR). I haven't been able to follow closely the latest
GCC development but it is entirely possible that in version 4.5 that
pass will have been rewritten and GIMPLE-to-tree functionality
removed. We will have to rewrite the gimple2cil to accomodate for this
in the future and the source location information will also have to
come from GIMPLE so I suggest that you investigate (starting from
gimple_location() and friends) if your work can be adapted to it. I
believe it should be possible and fairly easy; in fact when we will
have to deal with only GIMPLE nodes the whole pass should be simpler
(and we will need a much better stack-promotion pass!). Ciao!
Gabriele
|
|
From: Thierry L. <thi...@in...> - 2009-12-14 09:08:36
|
Hi Gabriele, Thanks for your remarks. What kind of coding guidelines do you think of? I can fix them before ciing. Thierry Lafage. Le 13/12/2009 20:36, Gabriele Svelto a écrit : > 2009/12/11 Thierry LAFAGE<thi...@in...>: > >> Hi all, >> >> Here is the second version of the patch for .line info in CIL generated >> code. >> Feel free to comment. >> If you have no other blocking points, I'll commit it as soon as I have my >> account on sourceware.org (which seems to last a bit). >> >> Regards, >> Thierry. >> > I've looked quickly at the patch and it seems good to me. I just > noticed a couple of places here and there were you didn't cope with > GCC coding guidelines but those can be fixed later. > > Gabriele > |
|
From: Thierry L. <thi...@in...> - 2009-12-14 08:20:24
|
Ciao, In fact, the first time you had to approve because I use @inria instead of @irisa (and I was registered as @irisa). Then I changed my account on the list to be registered as @inria. Then, this time an approval was needed because my post was too large... Regards, Thierry Lafage. Le 13/12/2009 16:24, Erven Rohou a écrit : > Andrea Carlo Ornstein a écrit : > >> I do not have any new remark :) >> >> BTW I do not understand why, but I have to approve all your emails, >> I did mistyped your email address? >> > We have many email addresses here: > lo...@ir... > fir...@ir... > fir...@in... > Maybe you registered Thierry with one and his mailer used another one? > > Thanks for the feedback on the patches, anyway. :-) > > Ciao, > > -- > Erven. > > > >> I set the mailing list to always accept mails from you, we will see. >> >> Andrea >> >> On Fri, Dec 11, 2009 at 4:56 PM, Thierry LAFAGE<thi...@in...> wrote: >> >>> Hi all, >>> >>> Here is the second version of the patch for .line info in CIL generated >>> code. >>> Feel free to comment. >>> If you have no other blocking points, I'll commit it as soon as I have my >>> account on sourceware.org (which seems to last a bit). >>> >>> Regards, >>> Thierry. >>> >> ------------------------------------------------------------------------------ >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> Gcc4cli-devel mailing list >> Gcc...@li... >> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel >> > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel > |
|
From: Erven R. <erv...@in...> - 2009-12-13 15:25:10
|
Andrea Carlo Ornstein a écrit : > I do not have any new remark :) > > BTW I do not understand why, but I have to approve all your emails, > I did mistyped your email address? We have many email addresses here: lo...@ir... fir...@ir... fir...@in... Maybe you registered Thierry with one and his mailer used another one? Thanks for the feedback on the patches, anyway. :-) Ciao, -- Erven. > I set the mailing list to always accept mails from you, we will see. > > Andrea > > On Fri, Dec 11, 2009 at 4:56 PM, Thierry LAFAGE <thi...@in...> wrote: >> Hi all, >> >> Here is the second version of the patch for .line info in CIL generated >> code. >> Feel free to comment. >> If you have no other blocking points, I'll commit it as soon as I have my >> account on sourceware.org (which seems to last a bit). >> >> Regards, >> Thierry. > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel |
|
From: Andrea C. O. <and...@gm...> - 2009-12-11 18:16:40
|
I do not have any new remark :) BTW I do not understand why, but I have to approve all your emails, I did mistyped your email address? I set the mailing list to always accept mails from you, we will see. Andrea On Fri, Dec 11, 2009 at 4:56 PM, Thierry LAFAGE <thi...@in...> wrote: > Hi all, > > Here is the second version of the patch for .line info in CIL generated > code. > Feel free to comment. > If you have no other blocking points, I'll commit it as soon as I have my > account on sourceware.org (which seems to last a bit). > > Regards, > Thierry. |
|
From: Thierry L. <thi...@in...> - 2009-12-11 15:56:49
|
Hi all, Here is the second version of the patch for .line info in CIL generated code. Feel free to comment. If you have no other blocking points, I'll commit it as soon as I have my account on sourceware.org (which seems to last a bit). Regards, Thierry. |
|
From: Thierry L. <Thi...@in...> - 2009-12-11 08:20:18
|
Hi all, First, checking that I can write to the mailing list. Then, to say that I agree with Andrea's remarks: we should split the patch into 2 and remove the unused macro, then I'll refactor my code in order to keep the same interface and add calls to set_locus() after calls to build*(). When it's done, I'll submit it to you again on this list if you agree. Regards, Thierry Lafage. |
|
From: Gabriele S. <gab...@gm...> - 2009-12-10 17:36:05
|
Let's see if it works for me too... Gabriele 2009/12/10 Erven Rohou <erv...@in...>: > Thanks Andrea! > Let's see if I can post to the mailing list... > > -- > Erven. > > Andrea Carlo Ornstein a écrit : >> Hi, >> >> we should probably start to maintain a changelog file for cli to >> complain to gcc policies >> I propose to call it ChangeLog.CLI and to put it in the dir gcc >> >> I created one for the work done in ST with svn2cl, I want to call it >> ChangeLog-ST.CLI >> but I have to check with Giuseppe if I can ci it. >> >> >> This was just a first email to see if the mailing list is working. >> >> Andrea >> >> ------------------------------------------------------------------------------ >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> Gcc4cli-devel mailing list >> Gcc...@li... >> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel >> > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel |
|
From: Erven R. <erv...@in...> - 2009-12-10 17:19:53
|
Thanks Andrea! Let's see if I can post to the mailing list... -- Erven. Andrea Carlo Ornstein a écrit : > Hi, > > we should probably start to maintain a changelog file for cli to > complain to gcc policies > I propose to call it ChangeLog.CLI and to put it in the dir gcc > > I created one for the work done in ST with svn2cl, I want to call it > ChangeLog-ST.CLI > but I have to check with Giuseppe if I can ci it. > > > This was just a first email to see if the mailing list is working. > > Andrea > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel > |
|
From: Andrea C. O. <and...@gm...> - 2009-12-10 17:10:18
|
Hi, we should probably start to maintain a changelog file for cli to complain to gcc policies I propose to call it ChangeLog.CLI and to put it in the dir gcc I created one for the work done in ST with svn2cl, I want to call it ChangeLog-ST.CLI but I have to check with Giuseppe if I can ci it. This was just a first email to see if the mailing list is working. Andrea |
