Re: PRE_DEC, POST_INC
Thank you.
> I am assuming you already have basic generation of auto-incs and you
> have your definitions for legitimate{legitimize}_address all set up
> correctly.
Well, I think they are. But the problem could be this. Here are cuts
from the machine description dealing with auto-inc-dec:
#define HAVE_PRE_INCREMENT 0
#define HAVE_PRE_DECREMENT 1
#define HAVE_POST_INCREMENT 1
#define HAVE_POST_DECREMENT 0
int
tam16_legitimate_address_p (enum machine_mode mode ATTRIBUTE_UNUSED,
rtx x, int strict)
{
rtx op1,op2;
/* Post-inc and pre-dec addressing modes allowed. */
if ((GET_CODE (x) == POST_INC || GET_CODE (x) == PRE_DEC)
&& REG_P (XEXP (x, 0))
&& (strict ? REG_OK_FOR_BASE_STRICT_P (XEXP (x, 0))
: REG_OK_FOR_BASE_NOSTRICT_P (XEXP (x, 0)))
/*&& reload_completed*/)
{
return 1;
}
...
The legitimize address function is defined as the legitimate address
function. I took inspiration from msp430's md.
#define LEGITIMIZE_ADDRESS(X, OLDX, MODE, WIN) \
GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN)
> In this case you could start by tweaking your address costs macros.
I did. Here again I could be wrong in the implementation:
int
tam16_address_costs (rtx x)
{
switch (GET_CODE (x))
{
case REG:
/* (rn) */
return COSTS_N_INSNS (2);
break;
case PLUS:
/* X(rn) */
return COSTS_N_INSNS (4);
break;
case POST_INC:
case PRE_DEC:
/* -(rn) , (rn)+ */
return COSTS_N_INSNS (2);
break;
default:
break;
}
if (CONSTANT_ADDRESS_P (x))
{
return COSTS_N_INSNS (4);
}
/* Unknown addressing mode. */
debug_rtx (x);
return COSTS_N_INSNS (50);
}
According to you, is this enough to enable basic auto-inc-dec in GCC ?
I tried to compile some test-cases I found in emails about the
subject. The result is there is no pre-dec or post-inc generated at
all.
Regards.
Florent
Re: cloog static build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Pop schrieb: > On Mon, Aug 10, 2009 at 04:22, Rainer Emrich > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I build my gcc windows versions (*-pc-cygwin, *-pc-mingw32, *-w64-mingw32) >> using >> static build libraries gmp, mpfr, mpc, ppl and cloog. Configuration and >> building >> of gcc is really easy using the --with-host-libstdcxx configure switch. >> That's >> not true for cloog. If configured against static versions of gmp and ppl I >> have >> to edit the Makefile manually and add -lstdc++ to LIBS. >> >> Is there a possibility to check at configure time if a static version of gmp >> is >> used and add -lstdc++ dependent on the result? >> > > Fixed in the git repo: http://repo.or.cz/w/cloog-ppl.git and I will > put a new tar.gz on > ftp://gcc.gnu.org/pub/gcc/infrastructure/ > > Thanks for reporting this problem, > Sebastian > Thanks for the fast action! But that's still not working because you insert the library at the beginning of the library list. We need it at the end of the list after -lgmpxx to resolve correctly. Cheers, Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqBX8MACgkQoUhjsh59BL5VGwCdE73Gbpmgn4NrooK9Ba41detA nnUAni2uRTaxSccwq2wz20QXyC5jsmU1 =biKB -END PGP SIGNATURE-
Re: i370 port
Paul Edwards wrote: > I expected that the assembler generation wouldn't happen until > after the optimization was completed, and thus, by then, I > would know whether this was a main. That depends a bit on the compiler version and optimization level, but (in particular in the 3.x time frame) GCC may output assembler code on a function-by-function basis, without necessarily reading in the whole source file first. As I said, it seems the best way would be to not have care at all whether or not any particular source file contains a main routine, but instead do all entry-point processing in the crt0 startup file. > > As crt0.o can be (and usually is) completely > > written in assembler, you can arrange for everything to be in the sequence > > that is required. (On the linker command line, crt0.o would be placed > > first, so if the entry point is the first thing in crt0.o it will then > > also be the first thing in the executable.) > > Yes, I can do that, but that means I need to have a linker command > line! The way the MVS linker works, I can link my main program, > (which obviously doesn't have crt0 in it), and, thanks to the "END" > statement, I can specify an entry point. This means no complaint > from the linker about a default (and wrong) entry point, and no > need for any linker statements. It all automatically resolves. I don't know exactly how your port handles this on MVS, but usually GCC itself will invoke the linker, and will itself prepare an appropriate command linker for the linker. As part of this command line, things like crt files will be specified. You should set the STARTFILE_SPEC macro in your back-end to do that ... > > There doesn't seem to be an easy way to do this from the > > compiler. At the time compiler output is generated, the > > original source code text isn't even kept any more; you'd > > have to go back and re-read the original source files using > > the line-number debug data, just as the assembler would ... > > Ok, well - I would be content with just the source line number > appearing in the output assembler. Is this information > available as each assembler line is output? In current GCC, every insn contains "location" information pointing back to source code line (and column) numbers. However, in GCC 3.x I think this wasn't yet present, but you had to rely on line number notes interspersed with the insn stream. In any case, if you build with -g and use in addition the "debug assembler output" flag -dA the assembler output should contain human-readable comments containing line number information. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [lambda] Latest experimental polymorphic lambda patches
A few comments:
/* XXX: Any way to get current location? */
input_location
The following examples produce
equivalent functions:
1. [] (auto x, auto& y, auto const& z) { return x + y + z; }
2. [] (X x, Y& y, Z const& z) {
return x + y + z; }
3. [] (auto x, Y& y, auto const& z) { return x + y + z; }
IMO #3 should not be equivalent to the others; the auto template parms
should come after Y. And I believe that's currently the case with your
patch.
In fact it would be better
+ to keep building a tree list and only flatten into
+ a vector after parsing the parameter list. */
If you save up all the auto parms until the end and then assign indices
and adjust the parm vector then, that will avoid reallocating the vector
each time.
But don't worry about tidying tree_node_counts; it just tracks how many
of a particular tree code we create, not how many we currently have.
Normal GC throws away lots of stuff without adjusting the counts.
+ /* XXX: Maybe to loop rather than recurse here? */
At -O2, the GCC optimizers should convert tail recursion into looping.
+ if (type_dependent_expression_p (expr))
+/* TODO: Should defer this until instantiation rather than using
+ decltype. */
+return_type = type_decays_to (non_reference (finish_decltype_type
+ (expr, /*id_expression_or_member_access_p=*/false)));
Definitely need to defer it; type_decays_to and non_reference don't work
on DECLTYPE_TYPE.
Jason
Re: cloog static build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Pop schrieb: > Hi, > > Could you please test the attached version of CLooG-PPL? This looks perfect now. Thanks a lot! Only a minor flaw remains: make clean gives: rm /version.h rm: cannot remove `/version.h': No such file or directory Cheers, Rainer > > Thanks, > Sebastian Pop > -- > AMD - GNU Tools > > > > On Tue, Aug 11, 2009 at 07:10, Rainer Emrich > wrote: > Sebastian Pop schrieb: On Mon, Aug 10, 2009 at 04:22, Rainer Emrich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I build my gcc windows versions (*-pc-cygwin, *-pc-mingw32, > *-w64-mingw32) using > static build libraries gmp, mpfr, mpc, ppl and cloog. Configuration and > building > of gcc is really easy using the --with-host-libstdcxx configure switch. > That's > not true for cloog. If configured against static versions of gmp and ppl > I have > to edit the Makefile manually and add -lstdc++ to LIBS. > > Is there a possibility to check at configure time if a static version of > gmp is > used and add -lstdc++ dependent on the result? > Fixed in the git repo: http://repo.or.cz/w/cloog-ppl.git and I will put a new tar.gz on ftp://gcc.gnu.org/pub/gcc/infrastructure/ Thanks for reporting this problem, Sebastian > Thanks for the fast action! But that's still not working because you insert > the > library at the beginning of the library list. We need it at the end of the > list > after -lgmpxx to resolve correctly. > > Cheers, > Rainer > >> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqBinYACgkQoUhjsh59BL7bCgCcCS4P0+WhW2Amu10th5rMY3O6 8GIAn3M5lRAKIGjL4JE1y5OKSq7xWvQj =w7Xy -END PGP SIGNATURE-
Re: [lambda] Latest experimental polymorphic lambda patches
Thanks for the feedback.
Jason Merrill wrote:
>Adam Butcher wrote:
>> The following examples produce
>> equivalent functions:
>>
>>1. [] (auto x, auto& y, auto const& z) { return x + y + z; }
>>2. [] (X x, Y& y, Z const& z) {
>> return x + y + z; }
>>3. [] (auto x, Y& y, auto const& z) { return x + y + z; }
>
> IMO #3 should not be equivalent to the others; the auto template parms
> should come after Y. And I believe that's currently the case with your
> patch.
>
Sorry, I wasn't clear. I meant that they generate the same function from the
user's point of view, not that their
internals are the same. I didn't mean to suggest that the order of their
template parameters would be the same. It
was meant to demonstrate that using 'auto' and specifying an explicit unique
typename are equivalent from a client
point-of-view. You are correct that in #3's case the generated lambda is
equivalent to:
[] (__AutoT1 x, Y& y,
__AutoT2 const& z) { return x + y + z; }
Which is, from the user's perspective, equivalent to the lambda functions
defined by #1 and #2, just that the order of
the template arguments are different.
I accept that this does give a different function signature in terms of
template parameter indexes. I've assumed that
explicit specialization of the call operator is not useful and therefore the
user would never see the final template
parameter list and would not need to understand its ordering.
> If you save up all the auto parms until the end and then assign indices
> and adjust the parm vector then, that will avoid reallocating the vector
> each time.
>
Yes that would be better.
> But don't worry about tidying tree_node_counts; it just tracks how many
> of a particular tree code we create, not how many we currently have.
> Normal GC throws away lots of stuff without adjusting the counts.
>
Ah okay. Would it be worth enhancing the tree-vec interface to include block
reallocation with size doubling and end
marking to allow for more efficient reallocation? Such a structural change
maybe hidden by the macro front-end. I
wonder how many uses of make_tree_vec don't ggcfree their previous tree-vec
when using it in a 'realloc' way.
A quick grep for 'make_tree_vec\>' in gcc reveals about 80 uses, many of which
with an arithmetic expression as its
argument. I wonder how many of these might benefit from such an allocation
scheme and how many would be impaired by
it?
Maybe its an insignificant issue.
>> + /* XXX: Maybe to loop rather than recurse here? */
>
> At -O2, the GCC optimizers should convert tail recursion into looping.
>
Great, no worries there then.
>> + if (type_dependent_expression_p (expr))
>> +/* TODO: Should defer this until instantiation rather than using
>> + decltype. */
>> +return_type = type_decays_to (non_reference (finish_decltype_type
>> + (expr, /*id_expression_or_member_access_p=*/false)));
>
> Definitely need to defer it; type_decays_to and non_reference don't work
> on DECLTYPE_TYPE.
>
I thought as much -- I assume it's just trying to strip non-existent qualifiers
from `decltype(expr)' which amounts to
a no-op.
Thanks again for the feedback. I'll try to get deferred return type deduction
working when I get some time. Working
through that will probably end up sorting some of the issues with dependent
return type deduction inside templates.
Cheers,
Adam
Re: [lambda] Latest experimental polymorphic lambda patches
On 08/11/2009 11:20 AM, Adam Butcher wrote: Ah okay. Would it be worth enhancing the tree-vec interface to include block reallocation with size doubling and end marking to allow for more efficient reallocation? I don't think so; I expect that would end up being less space-efficient, since in most cases we know in advance exactly how much space we need. Feel free to add a realloc_tree_vec function to gcc/tree.c, though. Such a structural change maybe hidden by the macro front-end. I wonder how many uses of make_tree_vec don't ggc_free their previous tree-vec when using it in a 'realloc' way. That just means they'll live until the next GC pass, not a big deal. Jason
gcc-4.4-20090811 is now available
Snapshot gcc-4.4-20090811 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090811/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 150666 You'll find: gcc-4.4-20090811.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090811.tar.bz2 C front end and core compiler gcc-ada-4.4-20090811.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090811.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090811.tar.bz2 C++ front end and runtime gcc-java-4.4-20090811.tar.bz2 Java front end and runtime gcc-objc-4.4-20090811.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090811.tar.bz2The GCC testsuite Diffs from 4.4-20090804 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[gcc-in-cxx] replacing qsort with std::sort
I've recently started my contributions to the gcc-in-cxx project, and eventually decided on the qsort suggestion because it seems the easiest one. I've made the change in three places in cp/classes.c; the patch can be found here: http://code.google.com/p/ccppbrasil/wiki/GccInCxx Is this the way to go? Some questions occurred to me: in order to support a C and a C++ compiler at the same time, what "portability" mechanism should be used? #ifdef guards to switch between qsort and std::sort on the spot, based on __cplusplus? Should a helper function be declared somewhere? Also, std::sort requires a "less" function on reference-tovalue-type, so the current foo_cmp functions can't be reused. Would a separate patch to introduce foo_less variants be acceptable for GCC 4.5 right now? Also, is the gcc-in-cxx branch still active? Should my objective be to contribute patches to this branch? On a side note, I've studied vec.h and found it hard to change. One reason is because this header is included by the gen*.c stuff, which is still being compiled by a C compiler, even when building with a C++ compiler is enabled. I've considered providing a separate version of vec.h when C++ is being used, to avoid infinite #ifdefs. Is this a good idea? -- Pedro Lamarão
Re: i370 port
That depends a bit on the compiler version and optimization level, but (in particular in the 3.x time frame) GCC may output assembler code on a function-by-function basis, without necessarily reading in the whole source file first. Ok, actually it doesn't matter if it doesn't work all the time. I'll always be compiling with -Os anyway, so it sounds like I'm in with a chance of the whole file being read first? If so, where is my first opportunity, in 3.2.3, to see if there's a "main" function in this file? > As crt0.o can be (and usually is) completely > written in assembler, you can arrange for everything to be in the > sequence > that is required. (On the linker command line, crt0.o would be placed > first, so if the entry point is the first thing in crt0.o it will then > also be the first thing in the executable.) Yes, I can do that, but that means I need to have a linker command line! The way the MVS linker works, I can link my main program, (which obviously doesn't have crt0 in it), and, thanks to the "END" statement, I can specify an entry point. This means no complaint from the linker about a default (and wrong) entry point, and no need for any linker statements. It all automatically resolves. I don't know exactly how your port handles this on MVS, but usually GCC itself will invoke the linker, and will itself prepare an appropriate command linker for the linker. GCC on MVS *only* outputs assembler. ie you always have to use the "-S" option. By doing so, it turns GCC into a pure text-processing application, which will thus work in any C90 environment. In current GCC, every insn contains "location" information pointing back to source code line (and column) numbers. However, in GCC 3.x I think this wasn't yet present, but you had to rely on line number notes interspersed with the insn stream. In any case, if you build with -g and use in addition the "debug assembler output" flag -dA the assembler output should contain human-readable comments containing line number information. The GCC assembler is never invoked. After getting the assembler output from the -S option, this is fed into IFOX00/IEV90/ASMA90. Regardless, if line number notes are interspersed in the stream, maybe whenever I write out an assembler instruction I will have access to those notes and can print out a comment. Thanks. Paul.
