How to set the alignment
Hello all, I am doing a private port in GCC 4.4.0. For my target the following are the alignment requirements: int - 4 bytes short - 2 bytes char - 1 byte pointer - 4 bytes stack pointer - 4 bytes i am not able to implement the alignment for short. The following is are the macros that i used for this #define PARM_BOUNDARY 8 #define STACK_BOUNDARY 64 I have also defined STACK_SLOT_ALIGNMENT. but this is not affecting the output. What should i be doing to get the required alignment? Regards, Shafi
How to install multi gcc package (version 4.1.2 & 3.2.3)?
Hi you! I'm a C++ developer on Linux. I want you show me the ways to install both GCC 4.1.2 and GCC 3.2.3 on my Linux. Thank you very much!
Re: GCC 4.3.4 release candidate available
On 27.07.2009 18:12, Richard Guenther wrote: A release candidate for the GCC 4.3.4 is now available at ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.4-RC-20090727 I plan to roll out the final release at the beginning of next week if there are no major problems reported. testsuite doesn't show regressions compared to 4.3.3 on various Debian architectures (the compiler tested was the Debian gcc-4.3 package, not exactly the snapshot provided). alpha http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00134.html arm http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00135.html hppahttp://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00249.html i486http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03148.html ia64http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03233.html mipshttp://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00136.html mipsel http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03328.html powerpc http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03234.html s390http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03330.html sparc http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03329.html x86_64 http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03232.html i486-kfreebsd http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03235.html Matthias
In pt.c, find_parameter_packs_r, should TYPE_P(t) assure TYPE_CONTEXT(t)?
While trying to track down the cause of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092 I encountered what may be an error. In pt.c around line 2493, there's this: if (TYPE_P (t) ) cp_walk_tree (&TYPE_CONTEXT (t), &find_parameter_packs_r, ppd, ppd->visited); However, gdb shows TYPE_CONTEXT(t) is the constant, 0, during compile of src.cpp: http://gcc.gnu.org/bugzilla/attachment.cgi?id=18288 To avoid this, should the if condition be changed to: if (TYPE_P (t) && TYPE_CONTEXT(t) ) or is TYPE_CONTEXT(t) == 0 possibly caused by a bug elsewhere? TIA. -Larry
Re: How to install multi gcc package (version 4.1.2 & 3.2.3)?
On Mon, 3 Aug 2009, Nguyen Quang Minh wrote: > I'm a C++ developer on Linux. I want you show me the ways to install > both GCC 4.1.2 and GCC 3.2.3 on my Linux. This question is out of scope for this mailing list which is about the development _of_ GCC, not the development _with_ GCC. I believe you are looking for the description of --prefix in our documentation at http://gcc.gnu.org/install/ . Gerald
order of -D and -U is significant
In current gcc the order of options -D and -U is significant. The Single Unix(r) Specification explicitly specifies that the order should not matter for the c89 command. It reads (cited from version 2, which is ten years old): -D name[=value] Define name as if by a C-language #define directive. If no =value is given, a value of 1 will be used. The -D option has lower precedence than the -U option. That is, if name is used in both a -U and a -D option, name will be undefined regardless of the order of the options. Additional implementation-dependent names may be provided by the compiler. Implementations support at least 2048 bytes of -D definitions and 256 names. I did not find a justification for the current gcc behavior. Searching revealed a patch which implemented the behavior: http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00621.html and two messages earlier that year which might be relevant: http://gcc.gnu.org/ml/gcc/2000-09/msg00673.html http://gcc.gnu.org/ml/gcc-patches/2000-08/msg01271.html The original bug report was: http://gcc.gnu.org/ml/gcc-bugs/2000-08/msg00605.html Neither message mentions a possible dependency to the unix specification. Three years later the code went from the preprocessor to the frontend http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01432.html I now have two questions: 1) Does anybody recall a discussion of this topic? 2) Is this a bug? Erwin
PR33113
Ira and Dorit, Is there any chance that PR33113 will be addressed for gcc 4.5? If I recall correctly, it was one of the last major issues with vectorization in gfortran that wasn't addressed yet. Dorit made the following comment back in Aug 2008... >From: Dorit Nuzman >Date: Tue, 12 Aug 2008 14:48:07 +0300 >X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February >07, 2008) at > 12/08/2008 14:43:23 >MIME-Version: 1.0 >Content-type: text/plain; charset=US-ASCII >Status: RO >X-Status: A >Content-Length: 11751 >Lines: 335 > >Jack Howarth wrote on 10/08/2008 19:00:08: > >> Dorit, >> I believe the attached email has the most detailed discussion of the >> issue that I recall seeing. Perhaps Tobias can expand on these previous >> conversations. >> Jack >> ps I was hoping that the graphite code generation would be enabled by >>default >> at -O3 in gcc 4.4 and that the vectorization code could be modified to >utilize >> its presence to do some optimizations on gfortran flat arrays which will >now >> have stride information via graphite. > >Hi Jack, > >There is currently no connection between the Graphite pass and any passes >that follow it. We will be looking into how to incorporate vectorization >with Graphite, but that will not happen during the 4.4 timeframe. However, >I think that this is not a prerequisite for vectorizing flat arrays; AFAIU, >Graphite itself is based on the scev analysis, so whichever stride >information Graphite gets out of scev, the vectorizer can already get it >too. Following our discussion below I had opened PR33113, where it turned >out that scev can easily be made to return symbolic stride information >instead of failing, and the problem is only inside the vectorizer which >needs to be enhanced to handle symbolic strides. I would actually be >interested in enabling that - I will try to look into it in the coming >weeks. > >dorit I ask because we seem to only get marginal improvements in the Polyhedron 2005 benchmarks between recent releases and these missed vectorization opportunities might provide a significant performance increase for those benchmarks. Thanks in advance for any clarifications. Jack
Re: extern variable
On Mon, 2009-08-03 at 09:44 +0530, sumanth wrote: >How can i make sure my tool chain knows the difference between > global variable r0 and register r0. The simple solution is to either add a prefix to variable names, or to add a prefix to register names. In ELF, the convention is to not add a prefix to variables names, we add a prefix to register names instead if we need one, e.g. %eax on i386, or $4 on mips. You can of course choose to add a prefix to variable names. It just isn't the convention. See for instance how the arm-elf port works when you use the -fleading-underscore option. A less simple solution is to have an assembler syntax that avoids ambiguity between register names and variable names. If for instance you have a move instruction that can accept either a register or a variable as source, then you have an ambiguity. You could instead have a load instruction for reading memory, and a move instruction for reading registers, and then you don't have an ambiguity anymore. You can also do things with addressing modes and relocation operators to reduce ambiguities. Jim
Re: MELT tutorial on the wiki
> "Dave" == Dave Korn writes: Dave> Were you using a --prefix? The PPL checks (by design I think) only Dave> look for PPL in your prefix. Dave> I do not know it; I have merely observed the behaviour. It may Dave> even not be by design for all I know, though I suspect it makes Dave> sense - where else would you look but in the prefix? Prefixes Dave> exist to create separation between packages. That didn't seem to be what the code on Basile's branch does. But, if this is what the PPL checks do actually do somewhere, then they are broken. Prefix is for specifying the install tree -- specifying how the build is done is handled by other options. Tom
Re: MELT tutorial on the wiki
> "Paolo" == Paolo Bonzini writes: Paolo> MELT looks extremely cool! You may want to use this too, however: Paolo> http://lwn.net/Articles/315686/ Yes, I'm also looking at Coccinelle and TreeHydra. As this is strictly a spare-time project, I am trying to find the approach that requires the least effort on my part. Coccinelle has the advantage that it is already packaged on Fedora. However, the documentation is not excellent (AFAICT there is a grammar and a bunch of examples, but nothing else) and that makes it difficult to use. Also it does not seem to handle GDB's heavily macroized code very well (maybe there's a way ... but again, the docs). TreeHydra looks very promising but it seems complicated to build. It wasn't clear which patches ought to be applied. I'm going to get it built one of these weeks... I was hoping that because all the code was on a branch, MELT would be the simplest to get working. Now I've spent more time on it than on the other two combined ;) Tom
Re: MELT tutorial on the wiki
Basile> Thanks for the bug report. In fact, melt_generated_dir should be the Basile> same as melt_source_dir Basile> I just committed rev 150330 of MELT branch to fix that. Tom, could you Basile> be patient & kind enough to try again! Many thanks! Thanks, that worked. Now to actually try MELT... exciting. Tom
Re: How to set the alignment
On 08/03/2009 02:14 AM, Mohamed Shafi wrote: short - 2 bytes i am not able to implement the alignment for short. The following is are the macros that i used for this #define PARM_BOUNDARY 8 #define STACK_BOUNDARY 64 You haven't explained what the actual problem is. Is there a problem with global variables? Is the variable initialized or uninitialized? If it is uninitialized, is it common? If this a local variable? Is this a function argument or parameter? Is this a named or unnamed (stdarg) argument or parameter? Etc. It always helps to include a testcase. You should also mention what gcc is currently emitting, why it is wrong, and what the output should be instead. All this talk about stack and parm boundary suggests that it might be an issue with function arguments, in which case you will probably have to describe the calling conventions a bit so we can understand what you want. Jim
Re: [lambda] Segmentation fault in simple lambda program
On 07/29/2009 06:27 AM, Adam Butcher wrote:
Esben Mose Hansen writes:
I am completely new to gcc hacking, just
dying to get lambda into gcc 4.5 :)
Me too on both counts!
Great! Please feel free to ask me any questions you have directly. Do
you have copyright assignments on file yet? I'll go ahead and merge the
current trunk into the branch.
Looking at the implementation in gcc/cp/{class.c,parser.c,semantics.c} it seems
that, in implicit capture mode,
references to enclosing scope identifiers are retrospectively added to the
lambda class on first use in the lambda
body. This made me worry about the class structure changing as you progress
through the parse of the lambda body.
I.e. at the start of the body nothing is captured -- since nothing is
referenced. As you meet enclosing scope
references, each is added as a capture member to the lambda class. Is this
okay or has something already decided on
the size and structure of the class?
That should be OK; recent changes to the specification
(http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2859.pdf) have
clarified that parsing the lambda body doesn't depend on the current
contents of the class: we parse the body, noting things that we need to
capture, then later rewrite the body to access captured variables
through the class.
I figured (almost certainly naively and incorrectly) that it ought to be similar
to the difference between:
struct X
{
int i;
void init_i() { i = 1; }
};
and
struct X
{
void init_i() { i = 1; }
int i;
};
Not exactly; in the X example we don't parse the body of init_i until
after the closing brace of X. For a lambda we parse the body
immediately, then build up the class appropriately, then rewrite the
body of the function.
+/* relayout again -- to allow for implicit
+ * parameters to have been added to the capture if it was a
+ * 'default capture' -- note that this would not be necessary if
+ * the stack-pointer variant was implemented -- since the layout
+ * would be known.
+ * Relayingout here might have nasty effect if one were to query
+ * sizeof *this from within the body -- would that even be
+ * possible -- *this would refer to the lambda or the enclosing
+ * class instance -- if there was one.???
+ *
+ * NOTE: I think this is a redefinition error; I'm just faking that
+ * it isn't by clearing the size node... need to use stack pointer
+ * method. But that will likely bring its own issues -- not with
+ * class layout though.
+ */
+TYPE_SIZE (type) = NULL_TREE;
+finish_struct_1 (type);
Something like this definitely seems necessary; for a lambda with
implicit capture, we can't know the size of the class until we're done
with the body.
The way 'default reference capture' is implemented on the lambda branch seems
to be kind of reactive. I would expect
that inheriting the stack somehow (maybe using just a stack pointer) would be
better but without more investigation I
don't know if that is possible or how one would go about doing it.
That should be possible, but seems more complicated than just capturing
the variables individually. We'd need to add some new generic tree
codes meaning "give me the address of this stack frame" and "give me the
address of this variable in this stack frame" for the front end to use
in rewriting the lambda body.
Jason
Re: extern variable
Hi Jim,
that seems to be a promising solution.
If I keep the prefix "_" for a global variable , there is a problem in
accessing it in gdb...let me explain you with an example
Eg: file1.c
int a = 10;
int main()
{
int b =10;
int c;
c = add( a , b);
return 0;
}
file2.c
int add( int x, int y)
{
return x+y ;
}
> mycompiler-gcc -g file1.c file2.c
> mycompiler-gdb a.out
>> when i print "a" in file1.c , i am able to see value 10;
>> when i print "a" int file2.c, it prints , no symbol defined.
Instead I can access it with " print _a"
Thats the problem; guess i am clear this time.
prefixing registers is out of scope for me , as people got used to
register names r0, r1..
Regards,
Sumanth G
Jim Wilson wrote:
On Mon, 2009-08-03 at 09:44 +0530, sumanth wrote:
How can i make sure my tool chain knows the difference between
global variable r0 and register r0.
The simple solution is to either add a prefix to variable names, or to
add a prefix to register names. In ELF, the convention is to not add a
prefix to variables names, we add a prefix to register names instead if
we need one, e.g. %eax on i386, or $4 on mips.
You can of course choose to add a prefix to variable names. It just
isn't the convention. See for instance how the arm-elf port works when
you use the -fleading-underscore option.
A less simple solution is to have an assembler syntax that avoids
ambiguity between register names and variable names. If for instance
you have a move instruction that can accept either a register or a
variable as source, then you have an ambiguity. You could instead have
a load instruction for reading memory, and a move instruction for
reading registers, and then you don't have an ambiguity anymore. You
can also do things with addressing modes and relocation operators to
reduce ambiguities.
Jim
Re: MELT tutorial on the wiki
Tom Tromey wrote:
Basile> Thanks for the bug report. In fact, melt_generated_dir should be the
Basile> same as melt_source_dir
Basile> I just committed rev 150330 of MELT branch to fix that. Tom, could you
Basile> be patient & kind enough to try again! Many thanks!
Thanks, that worked.
Now to actually try MELT... exciting.
There are still missing stuff in MELT. In particular, not every GIMPLE
feature is currently interfaced, because my way of coding is to
progressively add stuff inside MELT to deal with a particular question
(or even a test case).
Tom, and anyone other brave & kind enough to try MELT, knowing well GCC
internals, feel free to add more code inside MELT. Anyone with write
access to GCC subversion, good knowledge & good will can add more code
inside MELT (I explicitly invite brave people to enhance MELT).
This means essentially copy-pasting code (notably inside file
gcc/melt/ana-base.melt). But please add a few comments in the code (if
you patch it) and also in Changelog.MELT.
I'm leaving on holidays within two days.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: In pt.c, find_parameter_packs_r, should TYPE_P(t) assure TYPE_CONTEXT(t)?
On 08/03/2009 08:32 AM, Larry Evans wrote: While trying to track down the cause of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092 I encountered what may be an error. In pt.c around line 2493, there's this: if (TYPE_P (t) ) cp_walk_tree (&TYPE_CONTEXT (t), &find_parameter_packs_r, ppd, ppd->visited); However, gdb shows TYPE_CONTEXT(t) is the constant, 0, during compile of src.cpp: That's not a problem; if the tree passed to walk_tree_1 is null, it just returns. Jason
Re: extern variable
On Tue, 2009-08-04 at 00:06 +0530, sumanth wrote: > > mycompiler-gcc -g file1.c file2.c > > mycompiler-gdb a.out > >> when i print "a" in file1.c , i am able to see value 10; > >> when i print "a" int file2.c, it prints , no symbol defined. > Instead I can access it with " print _a" This sounds odd, as there is no variable a or _a in file2.c, and if you can see a variable in one file you should be able to see if with the same name in another file. Anyways, I think I already answered this with my first message when I pointed you at ASM_OUTPUT_* and ASM_GENERATE_INTERNAL_LABEL etc. If you compile with -g -S, and look at the assembly language, you will see that "_a" is being used in the debug info someplace for the variable name where "a" should be used instead. "_a" is correct for the variable address, but not the variable name. So you will have to step through your gcc port to figure out why the "_a" is incorrectly printed, and most likely it is a bug in one of the macros I have mentioned. Take a look at a port that handles this correctly to see what they do differently to make this work. Jim
[gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx
Current trunk (revision 150381) fails to bootstrap with the following configuration: [pedro.lama...@larissa trunk-obj]$ ../trunk/configure --prefix=/opt/gcc-4.5 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ --enable-build-with-cxx --with-tune=generic --with-arch=i586 --build=i586-redhat-linux giving the following error: g++ -I../../trunk/libcpp -I. -I../../trunk/libcpp/../include -I../../trunk/libcpp/include -g -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -I../../trunk/libcpp -I. -I../../trunk/libcpp/../include -I../../trunk/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../trunk/libcpp/charset.c In file included from ../../trunk/libcpp/system.h:342, from ../../trunk/libcpp/charset.c:23: ../../trunk/libcpp/../include/libiberty.h:106: error: new declaration ‘char* basename(const char*)’ /usr/include/string.h:601: error: ambiguates old declaration ‘const char* basename(const char*)’ Am I missing something? -- P.
[cxx0x-lambdas] Bootstrap fails
Revision 150382 of the cxx0x-lambdas-branch fails to bootstrap with the following error: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengtype \ build/gengtype.o build/gengtype-lex.o build/gengtype-parse.o build/errors.o ../build-i586-redhat-linux/libiberty/libiberty.a /bin/sh ../../cxx0x-lambda/gcc/../move-if-change tmp-gi.list gtyp-input.list echo timestamp > s-gtyp-input build/gengtype ../../cxx0x-lambda/gcc gtyp-input.list ../../cxx0x-lambda/gcc/cp/cp-tree.h:571: parse error: GTY must be specified before identifier make[3]: ** [s-gtype] Erro 1 when configured like this: [pedro.lama...@larissa cxx0x-lambda-obj]$ ../cxx0x-lambda/configure --prefix=/opt/gcc-lambda --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ --with-tune=generic --with-arch=i586 --build=i586-redhat-linux on a Fedora 11 system. -- P.
Tree aliasing
I was improving tree aliasing for pointers by adding support a+1 and a not aliasing. But I ran into a bug in the aliasing where: /* If both references are through the same type, they do not alias if the accesses do not overlap. This does extra disambiguation for mixed/pointer accesses but requires strict aliasing. */ if (same_type_for_tbaa (TREE_TYPE (TREE_TYPE (ptr1)), TREE_TYPE (TREE_TYPE (ptr2))) == 1) return ranges_overlap_p (offset1, max_size1, offset2, max_size2); Would return false even. I can't see how this can be true if one pointer is defined as an offset as the other and the offset1 or offset2 are non zero. Can someone explain why this is true? Even nonaliasing_component_refs_p looks to have the same issue if the types are the same, they could be an extra offset from each other, even though the compiler cannot figure that out. I am thinking of when storing the pointer in an array and then accessing that pointer. gcc.dg/20030324-1.c is the testcase where I am running into this bug too. Thanks, Andrew Pinski
Re: [lambda] Segmentation fault in simple lambda program
On 08/03/2009 09:36 PM, Adam Butcher wrote:
Thanks. I haven't any copyright assignments on file -- this is my first
dabbling with gcc and I've been doing it
mostly to experiment with C++ lambda support and non-standard extensions such
as polymorphic lambda support.
OK. We'll need an assignment in order to incorporate your changes into
GCC. If you want to assign all present and future changes to the
compiler, you could use the form
http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future
Cool. I've been working in my own repository which I rebased earlier today
from trunk (r150148). I've attached the
rebase including the fix for generating correct copying of lambda classes
(re-laying out after parsing body).
Hmm, having the new changes folded into the old changes is kind of
inconvenient, but I suppose I can deal. It's moot anyway until your
assignment is on file.
Incidentally, comments like
/*
*
*
*/
aren't customary in GCC sources; that's just something John did that
we'll need to clean up before the code goes into the trunk. There are
other formatting irregularities, some of which I've corrected.
It also
fixes return type deduction which didn't work after updating to 4.5 as
build_lang_decl no longer accepts DECL_RESULT
(I replaced it with build_decl directly which seemed to work fine). There were
a few other things like placement of
GTY (()) and replacing preservation of skip_evaluation with preservation of
cp_unevaluated_operand and
c_inhibit_evaluation_warnings (which seems to have been what's occurred in
other places).
Oops, and I checked in my merge without even testing that it would
build...guess I'd better fix it.
Experimenting with a working version and seeing it's issues will be useful to
me. To others to maybe. With concepts
gone from C++0x and being reworked for C++15(?) maybe support for polymorphic
lambdas could be reintroduced? -- though
I'm sure its much too late for that and that its likely been around the buoy
many times. From what I have read I got
the idea that the Callable concept was the primary reason for polymorphic
lambdas not being accepted.
I don't know what the reasoning was there, but people have been somewhat
conservative about what usages of lambdas are allowed for fear of
unforseen implementation issues. Certainly having a working
implementation would go a lot toward convincing people to allow it, even
if it doesn't make it into C++0x.
Implied template typename arguments via auto are not currently supported. The
syntax parses but I haven't yet
synthesized the template arguments and therefore not replaced the auto's with
them so it doesn't compile.
Since templates work so differently from normal functions, I'm a little
uncomfortable with the idea of templates that don't involve any template
syntax, just the use of auto in the parameter list. But I'm open to
giving it a try, at least in the lambda context. Maybe outside of
lambda it could be used with a small template introducer...
I'd welcome feedback on the syntax and semantics and of course any fundamental
things I've missed by coming up with
such a syntax!
From a grammar point of view I've just expanded lambda-parameter-declaration
to start with:
lambda-template-param-decl [opt]
where lambda-template-param-decl is:
< template-parameter-list>
Makes sense. I suppose to specify explicit template arguments users
would have to write
lambdaob.operator()(fn-arg)
so we'd really expect them to be only deduced.
# unspecified typename inferred by use of auto in function parameter list
[=] (auto* x, YY y) { return x->Func( y, a, b ); };
# is translated into
[=] (X* x, YY y) { return x->Func( y, a, b );
};
A mixed declaration like that seems rather ugly to me; I'd hope that
people would use either explicit template args or auto in a particular
lambda, not both. But I suppose that's not reason enough to forbid it.
Jason
Re: [lambda] Segmentation fault in simple lambda program
Jason Merrill wrote: Experimenting with a working version and seeing it's issues will be useful to me. To others to maybe. With concepts gone from C++0x and being reworked for C++15(?) maybe support for polymorphic lambdas could be reintroduced? -- though I'm sure its much too late for that and that its likely been around the buoy many times. From what I have read I got the idea that the Callable concept was the primary reason for polymorphic lambdas not being accepted. I don't know what the reasoning was there, but people have been somewhat conservative about what usages of lambdas are allowed for fear of unforseen implementation issues. Certainly having a working implementation would go a lot toward convincing people to allow it, even if it doesn't make it into C++0x. There were several issues with polymorphic lambdas in the presence of concepts that concerned many on the committee. I've come to accept that it's too late to re-introduce polymorphic lambdas into C++0x (now C++1x), but there's no stopping GCC from implementing it as an extension. Implied template typename arguments via auto are not currently supported. The syntax parses but I haven't yet synthesized the template arguments and therefore not replaced the auto's with them so it doesn't compile. Since templates work so differently from normal functions, I'm a little uncomfortable with the idea of templates that don't involve any template syntax, just the use of auto in the parameter list. But I'm open to giving it a try, at least in the lambda context. Maybe outside of lambda it could be used with a small template introducer... Just my opinion, but I don't think there should be any special template syntax. The whole point of argument deduction was terseness. It doesn't have to be implemented using templates, so I don't equate it with templates. - John
Re: [lambda] Segmentation fault in simple lambda program
I haven't been following GCC, so I need to thank Jason for forwarding
this issue to me.
I just read through the messages on the list, and had some more comments:
+/* relayout again -- to allow for implicit
+ * parameters to have been added to the capture if it was a
+ * 'default capture' -- note that this would not be necessary if
+ * the stack-pointer variant was implemented -- since the layout
+ * would be known.
+ * Relayingout here might have nasty effect if one were to query
+ * sizeof *this from within the body -- would that even be
+ * possible -- *this would refer to the lambda or the enclosing
+ * class instance -- if there was one.???
+ *
+ * NOTE: I think this is a redefinition error; I'm just faking that
+ * it isn't by clearing the size node... need to use stack pointer
+ * method. But that will likely bring its own issues -- not with
+ * class layout though.
+ */
+TYPE_SIZE (type) = NULL_TREE;
+finish_struct_1 (type);
Relaying out the class after the lambda body was parsed is something I
had attempted to do, but possibly failed at. It will absolutely need to
be done.
The way 'default reference capture' is implemented on the lambda branch seems
to be kind of reactive. I would expect
that inheriting the stack somehow (maybe using just a stack pointer) would be
better but without more investigation I
don't know if that is possible or how one would go about doing it.
This won't be suitable in the general case, because of the copy default
capture [=]. Implicit captures will have to be reactive.
/*
* Rather than looping through the identifiers used in the scope of
* the lambda and synthesizing individual captures of them, it would
* be better to ref the stack frame as transparently as possible...
* e.g. given just three ints i, j and k in scope:
* Instead of transforming:
*
*[&] { i = 1; j = 2; k = 3; };
*
* into
*
*[&i,&j,&k] { i = 1; j = 2; k = 3; };
*
* and thus storing three pointers to int, transform it into:
*
*[sp=enclosing-stack-pointer] { var-from-stack(i,sp) = 1;
* var-from-stack(j,sp) = 2;
* var-from-stack(k,sp) = 3; };
*
* and only store one pointer.
This is preferred for reference default captures, but I was not familiar
with stack pointer mechanics in GCC. I just wanted to get something
working first that could be improved later.
* I don't know if its possible but it may be possible to 'append'
* the lambda's stack to the existing scope rather than creating a
* new constrained scope -- from a logical point of view.
Again, this is not suitable to the general case because a lambda can
outlast its enclosing scope.
My motivation for investigating is that I consider constraining lambdas to be
monomorphic significantly reduces their
usefulness. I'm sure there are many good reasons why the committee decided
that it was the way to go.
I don't think it handicaps lambdas as much as some may believe, but
still wanted polymorphic lambdas as well. There were just too many
issues with deduction. When I last left the discussion, the biggest
issue in my opinion was concept map dropping. The workaround made the
deduction algorithm intimidatingly complex.
The following program generates the expected code and runs correctly.
auto f = [&] (T n, T const& m, U u) { i = ++n; j =
u(++n); k = ++n; };
This is exciting. The main thing I failed to add was dependent type
support, so I want to check this out. (I need to register a new ssh key)
- John
Re: How to set the alignment
2009/8/3 Jim Wilson :
> On 08/03/2009 02:14 AM, Mohamed Shafi wrote:
>>
>> short - 2 bytes
>> i am not able to implement the alignment for short.
>> The following is are the macros that i used for this
>> #define PARM_BOUNDARY 8
>> #define STACK_BOUNDARY 64
>
> You haven't explained what the actual problem is. Is there a problem with
> global variables? Is the variable initialized or uninitialized? If it is
> uninitialized, is it common? If this a local variable? Is this a function
> argument or parameter? Is this a named or unnamed (stdarg) argument or
> parameter? Etc. It always helps to include a testcase.
>
> You should also mention what gcc is currently emitting, why it is wrong, and
> what the output should be instead.
>
> All this talk about stack and parm boundary suggests that it might be an
> issue with function arguments, in which case you will probably have to
> describe the calling conventions a bit so we can understand what you want.
>
This is the test case that i tried
short funs (int a, int b, char w,short e,short r)
{
return e+r;
}
The target is 32bit . The first two parameters are passed in registers
and the rest in stack. For the parameters that are passed in stack the
alignment is that of the data type. The stack pointer is 8 byte
aligned. char is 1 byte, int is 4 byte and short is 2 byte. The code
that is getting generated is give below (-O0 -fomit-frame-pointer)
funs:
add 16,sp
mov d0,(sp-16)
mov d1,(sp-12)
movh (sp-19),d0
movh d0,(sp-8)
movh (sp-21),d0
movh d0,(sp-6)
movh (sp-8),d1
movh (sp-6),d0
add d1,d0,d0
sub16,sp
ret
From the above code you can see that some of the half word access is
not aligned on a 2byte boundary.
So where am i going wrong.
Hope this info is enough
Regards,
Shafi
Re: order of -D and -U is significant
On 08/03/2009 03:52 PM, Unruh, Erwin wrote: 2) Is this a bug? I think it's a bug in the specification. User-specified CFLAGS are always passed last in the Makefiles (at least for Automake, but it is a good practice in general) so that the user can override options like -D, -U, -O, -g, -f, -m. The specified behavior would make this impossible. Paolo
