indirect call in RTL dump files
http://gcc.fyxm.net/summit/2004/GCC%20Call%20Graph.pdf
For the RTL representation, there are two type of function call instructions
as I understand.
1) direct call---this type of calls are shown with something like
(call (mem:QI (symbol_ref:SI ("bar") [flags 0x3] bar>) [0 S1 A8])
And the corresponding source code is something like "bar();" in C.
2) indirect call (explained in 3.1 in the above paper)
Can someone help me explain this a bit? --what the corresponding code is in
C, and what causes it to happen? What does the RTL code look like?
Thanks,
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: indirect call in RTL dump files
On May 6, 2006, at 10:06 AM, sean yang wrote:
2) indirect call (explained in 3.1 in the above paper)
Can someone help me explain this a bit? --what the corresponding
code is in C, and what causes it to happen? What does the RTL code
look like?
void f(void (*x)(void))
{
x();
}
-- Pinski
gcc-4.2-20060506 is now available
Snapshot gcc-4.2-20060506 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060506/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 113581 You'll find: gcc-4.2-20060506.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060506.tar.bz2 C front end and core compiler gcc-ada-4.2-20060506.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060506.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060506.tar.bz2 C++ front end and runtime gcc-java-4.2-20060506.tar.bz2 Java front end and runtime gcc-objc-4.2-20060506.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060506.tar.bz2The GCC testsuite Diffs from 4.2-20060429 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Re: indirect call in RTL dump files
From: Andrew Pinski <[EMAIL PROTECTED]>
To: "sean yang" <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: Re: indirect call in RTL dump files
Date: Sat, 6 May 2006 10:10:16 -0700
On May 6, 2006, at 10:06 AM, sean yang wrote:
2) indirect call (explained in 3.1 in the above paper)
Can someone help me explain this a bit? --what the corresponding code is
in C, and what causes it to happen? What does the RTL code look like?
void f(void (*x)(void))
{
x();
}
Thanks very much. Is this (callback) the only case for indirect call?
-- Pinski
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Status of SEE and Autovectorization patches?
I see lots of failures running the testsuite on x86-64 now: one example: FAIL: gcc.c-torture/compile/2120-2.c -O3 -fomit-frame-pointer (test for excess error s) Excess errors: /cvs/gcc-svn/trunk/gcc/testsuite/gcc.c-torture/compile/2120-2.c:11: internal compiler error: RTL check: expected code 'subreg', have 'mem' in see_get_extension_data, at see.c:7 37 This leads to 541 failures for the gcc testsuite (other testsuites show similar problems): === gcc Summary for unix === # of expected passes38421 # of unexpected failures541 # of unexpected successes 2 # of expected failures 121 # of unresolved testcases 338 # of untested testcases 28 # of unsupported tests 377 Configured with: /cvs/gcc-svn/trunk/configure --prefix=/opt/gcc/4.2-devel --enable-checking=yes,rtl --enable-threads=posix --enable-clocale=gnu --enable-__cxa_atexit --enable-shared --enable-languages=c,c++,ada,treelang,java,fortran,objc --with-system-zlib x86_64-suse-linux-gnu This really has to be fixed, IMHO the optimization does not seem to be ready for stage 3, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgp3QEXDrtsnl.pgp Description: PGP signature
Re: Google SoC Project proposal: Wcoercion option
On May 4, 2006, at 4:44 PM, [EMAIL PROTECTED] wrote:
struct C : A, B { /* ... */ };
I am sorry to say that I don't understand the definition of struct C.
C is derived from A and B. Only valid of course in C++.
pl1gcc version 0.0.11 released
May 2006 This is the eleventh code drop of the GCC front-end for the PL/I programming language. PL/I for GCC is released under the terms of the GNU Public License; version 2. Version 0.0.11 includes a new infrastructure for the preprocessor. It has been more than a year since the previous release of pl1gcc, but development has picked up again. And remember you are always welcome to join the project, we need really help at all levels of development. The v0.0.11 release marks another important step forward towards a fully functioning PL/I compiler: the preprocessor. The current implementation supports just a few statement, but thanks to the tools flex and bison, it is straightforward to add the missing preprocessor statements. Expect a few new ones to be added with each new release, just like the PL/I parser has been developed. Currently there is still no code generation taking place, so don't run out and uninstall your production PL/I compiler just yet :-) But read ahead for some good news. It would still be a great help for us if you try the compiler on some of your own source code, or if you could construct a PL/I program that really tests the corners of the grammar. Basically a program that does all what the syntax allows. As inspiration, have a look at the test program written Paul Karagianis http://www.multicians.org/proc-proc.html but I am sure you can create a much worse PL/I program, which we would like to see. And if you release it under GPL it can be added to the pl1gcc hall of fame, so just go ahead and do the coding. Please inform us about any syntax errors that might occur so we can check if the error is in the pl1gcc parser, and not in your code. Changes in v0.0.11: * New preprocessor infrastructure using bison and flex. * Added new compiler option -pp-only: preprocessor scanning only. * Added installation instructions when using Eclipse as development platform. * Added better windows/Cygwin installation instructions, thanks to John Wood. * Refactoring of code to make the code more modular. * Synchronized with gcc version 4.2 Changed syntax in v0.0.11: * Allow DECLARE statements to be empty. * Allow scale for datatype COMPLEX. * Some ENVIRONMENT elements can have a variable as parameter. * Allow subscripts and initial on ALLOCATE statement. * Allow B1 for bit constants * %DECLARE varname FIXED/CHAR * %REPLACE varname BY value * %INCLUDE filename * %INCLUDE environmentvariable ( filename ) For a complete changelog look in the README file. What is pl1gcc? The pl1gcc project is an attempt to create a native PL/I compiler using the GNU Compiler Collection. The project is looking for more people to join the development and testing. If you want to help speed up the development of a free PL/I compiler please do contact us and join the fun. Looking ahead. Since two exciting code donations has been done, real code generation is just within reach. A big thank to Patrick and Hugh for releasing their hard work under the GPL license. The contributions are: * Object Oriented Extension generator by Patrick Senti. * PL/I compiler for Windows by Hugh Moran. If you happen to have some PL/I code lying around and you don't know what on earth you should do with it, consider releasing it under the terms of GPLv2, and send it to the pl1gcc project. We will be happy to host the source code for you. Who knows, it might even be possible to see that old code live again once code generation takes place. For releasing your code under the GPL license look at http://www.gnu.org/licenses/gpl-howto.html for the exact details. If you do try the compiler on some of your own code, please let us know how it goes. Further, if you know of a PL/I project you would like to see supported by the pl1gcc effort, please get in touch with us. The code does not have to be covered by GPL. For more information, comments, feedback and download, please visit http://pl1gcc.sourceforge.net If you are interested in how the development is progressing, follow the discussions on the development mailing list: pl1gcc-development (-at-) lists.sourceforge.net Finally, remember to have some fun. The GCC PL/I Team. Web links mentioned: http://www.multicians.org/proc-proc.html http://www.gnu.org/licenses/gpl-howto.html http://pl1gcc.sourceforge.net
VLA/VM [*] bug fixes for C
I'll entertain pointers to VLA/VM and [*] bugs for C, please send me
pointers to reports in bugzilla.
Thanks.
I know about http://gcc.gnu.org/PR25802
I also would like to know what people think the standard (c99) says
about:
void foo4(int o[*][4]) { }
void foo5(int o[4][*]) { }
void foo6(int (*o)(int p[*])) { }
Things I don't need reports for, are things fixed by the below patch.
Doing diffs in .:
--- ./c-decl.c.~1~ 2006-05-04 15:52:47.0 -0700
+++ ./c-decl.c 2006-05-05 19:34:04.0 -0700
@@ -3007,14 +3007,14 @@ quals_from_declspecs (const struct c_dec
return quals;
}
-/* Construct an array declarator. EXPR is the expression inside [], or
- NULL_TREE. QUALS are the type qualifiers inside the [] (to be applied
- to the pointer to which a parameter array is converted). STATIC_P is
- true if "static" is inside the [], false otherwise. VLA_UNSPEC_P
- is true if the array is [*], a VLA of unspecified length which is
- nevertheless a complete type (not currently implemented by GCC),
- false otherwise. The field for the contained declarator is left to be
- filled in by set_array_declarator_inner. */
+/* Construct an array declarator. EXPR is the expression inside [],
+ or NULL_TREE. QUALS are the type qualifiers inside the [] (to be
+ applied to the pointer to which a parameter array is converted).
+ STATIC_P is true if "static" is inside the [], false otherwise.
+ VLA_UNSPEC_P is true if the array is [*], a VLA of unspecified
+ length which is nevertheless a complete type, false otherwise. The
+ field for the contained declarator is left to be filled in by
+ set_array_declarator_inner. */
struct c_declarator *
build_array_declarator (tree expr, struct c_declspecs *quals, bool static_p,
@@ -3046,7 +3046,15 @@ build_array_declarator (tree expr, struc
pedwarn ("ISO C90 does not support %<[*]%> array declarators");
}
if (vla_unspec_p)
-warning (0, "GCC does not yet properly implement %<[*]%> array
declarators");
+{
+ if (!current_scope->parm_flag)
+ {
+ /* C99 6.7.5.2p */
+ error ("%<[*]%> not allowed in other than function prototype scope");
+ declarator->u.array.vla_unspec_p = false;
+ return NULL;
+ }
+}
return declarator;
}
@@ -3858,20 +3866,21 @@ grokdeclarator (const struct c_declarato
int type_quals = TYPE_UNQUALIFIED;
const char *name, *orig_name;
tree typedef_type = 0;
- int funcdef_flag = 0;
+ bool funcdef_flag = false;
bool funcdef_syntax = false;
int size_varies = 0;
tree decl_attr = declspecs->decl_attr;
int array_ptr_quals = TYPE_UNQUALIFIED;
tree array_ptr_attrs = NULL_TREE;
int array_parm_static = 0;
+ bool array_parm_vla_unspec_p = false;
tree returned_attrs = NULL_TREE;
bool bitfield = width != NULL;
tree element_type;
struct c_arg_info *arg_info = 0;
if (decl_context == FUNCDEF)
-funcdef_flag = 1, decl_context = NORMAL;
+funcdef_flag = true, decl_context = NORMAL;
/* Look inside a declarator for the name being declared
and get it as a string, for an error message. */
@@ -4137,7 +4146,8 @@ grokdeclarator (const struct c_declarato
array_ptr_quals = declarator->u.array.quals;
array_ptr_attrs = declarator->u.array.attrs;
array_parm_static = declarator->u.array.static_p;
-
+ array_parm_vla_unspec_p = declarator->u.array.vla_unspec_p;
+
declarator = declarator->declarator;
/* Check for some types that there cannot be arrays of. */
@@ -4262,6 +4272,14 @@ grokdeclarator (const struct c_declarato
identical to GCC's zero-length array extension. */
itype = build_range_type (sizetype, size_zero_node, NULL_TREE);
}
+ else if (decl_context == PARM)
+ {
+ if (array_parm_vla_unspec_p)
+ {
+ itype = build_range_type (sizetype, size_zero_node,
NULL_TREE);
+ size_varies = 1;
+ }
+ }
/* Complain about arrays of incomplete types. */
if (!COMPLETE_TYPE_P (type))
@@ -4272,6 +4290,9 @@ grokdeclarator (const struct c_declarato
else
type = build_array_type (type, itype);
+ if (size_varies && pedantic && decl_context == FIELD)
+ error ("not an ordinary identifier, structure and unions are not
ordinary");
+
if (type != error_mark_node)
{
if (size_varies)
@@ -4285,6 +4306,11 @@ grokdeclarator (const struct c_declarato
TYPE_SIZE (type) = bitsize_zero_node;
TYPE_SIZE_UNIT (type) = size_zero_node;
}
+ if (array_parm_vla_unspec_p)
+ {
+ /* The type is complete. C99 6.7.5.2p4 */
+ TYPE_SIZE (type) = bitsize_zero_node
Re: Documentation of vector intrinsics / SSE2
Martin Reinecke <[EMAIL PROTECTED]> writes: > I'm trying to learn about GCC's support for vector arithmetic and found > the section "Using vector instructions through built-in functions", which > answers a lot of questions, but unfortunately does not address things > like gathering scalar values into a vector type or reading scalars > out of such a variable, which I think is quite important for everyone > who wants to use this nice extension. At present it has to be done through a union type: a union of the vector type and an array of the appropriate length and element type. > More X86-specific, the section "X86 Built-in Functions" documents > builtins for MMX, 3DNow, SSE, SSE3, but appears to omit the vector > intrinsics for SSE2 like, e.g., __builtin_ia32_sqrtpd(). The x86 built-in functions is now completely out of date. The preferred approach now is to use the Intel documented intrinsics functions declared in mmintrin.h and friends. Ian
Re: VLA/VM [*] bug fixes for C
On Sat, 6 May 2006, Mike Stump wrote:
> I'll entertain pointers to VLA/VM and [*] bugs for C, please send me pointers
> to reports in bugzilla.
>
> Thanks.
>
> I know about http://gcc.gnu.org/PR25802
Bugs 19771, 7948, 18740 (in general, look at the bugs on which bug 16989
depends). The question of when exactly an array size expression is
evaluated requires careful thought and design to ensure it is always done
at the right time, the other issues should be easier to resolve.
> I also would like to know what people think the standard (c99) says about:
>
> void foo4(int o[*][4]) { }
> void foo5(int o[4][*]) { }
Invalid.
> void foo6(int (*o)(int p[*])) { }
Valid.
Function prototype scope is defined in 6.2.1#4.
More examples:
void foo(int a, int b[*][*], int c[static sizeof(*b)]);
is valid code, though what size is relevant for the [static] is more
obscure. sizeof a [*] array returns an indeterminate nonconstant value of
type size_t, which can be used in expressions just like other values of
type size_t.
void foo(int x[sizeof(int (*)[*])]);
should probably be considered invalid, as should
void foo(int [*]);
([*] being used in a type that's not a declaration). (I'm not aware of
anything to contradict Nick Maclaren's interpretation
here.)
The example I gave in WG14 reflector message 10731 ought probably to be
invalid or at least undefined behavior at runtime - the latter is probably
the best interpretation for now, since I haven't written or submitted a DR
for that case. To quote my message:
Consider the code
int a, b, c, d, e, f;
void *p1(void), *p2(void), *p3(void);
int c1(void), c2(void);
int d1(void), d2(void), d3(void);
int z1(void), z2(void), z3(void);
int
h(void)
{
int r = (c1()
? (z1(), (int (*(*(*)[d1()])[])[])p1())
: (c2()
? (z2(), (int (*(*(*)[])[d2()])[])p2())
: (z3(), (int (*(*(*)[])[])[d3()])p3())
)
)[a][b][c][d][e][f];
return r;
}
The outer conditional expression has a type which may informally be
described as "pointer to arrays [d1()] of pointers to arrays [d2()] of
pointers to arrays [d3()] of ints", by the composite type rules applied
to
conditional expressions. But when the expression is executed, all
three
dimensions are needed to evaluate the [a][b][c][d][e][f] array
reference,
but only one of the dimensions appears in an expression which should be
evaluated according to the rules for evaluation of conditional
expressions. Furthermore, the return value of d2() may depend on the
prior calls to c2() and z2() in that part of the conditional
expression,
so if c1() returns nonzero it might not suffice simply to evaluate d2()
and d3() as well as d1(); c2(), z2() and z3() would also need to be
evaluated.
Which functions should be called when in the evaluation of the above
expression? Or, should such constructs be disallowed and how would we
define what the invalid constructs are?
(Much the same issue arises with compound literals of VM type as does
with
casts to VM type.)
See also my DRs 311, 312, 313 (which deal with rather simpler cases).
There's also a pre-DR I haven't submitted to WG14,
.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
re: GCC 4.0.1 compilation errors
Ginil wrote: code that compiled easily with gcc-3.2.1 would not compile with gcc-4.0.1. ... The major errors are with template, name lookup but there are also certain errors with finding definitions from header files which are included and are in include path. Your code is probably not C++ standard compliant; the new gcc is stricter. I maintain a collection of links about this at http://kegel.com/gcc/gcc4.html including an excellent pair of documents from someone who built all of Debian with gcc-4.1. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: VLA/VM [*] bug fixes for C
Joseph S. Myers wrote:-
> for that case. To quote my message:
>
> Consider the code
>
> int a, b, c, d, e, f;
> void *p1(void), *p2(void), *p3(void);
> int c1(void), c2(void);
> int d1(void), d2(void), d3(void);
> int z1(void), z2(void), z3(void);
>
> int
> h(void)
> {
> int r = (c1()
> ? (z1(), (int (*(*(*)[d1()])[])[])p1())
> : (c2()
> ? (z2(), (int (*(*(*)[])[d2()])[])p2())
> : (z3(), (int (*(*(*)[])[])[d3()])p3())
>)
> )[a][b][c][d][e][f];
> return r;
> }
>
> The outer conditional expression has a type which may informally be
> described as "pointer to arrays [d1()] of pointers to arrays [d2()] of
> pointers to arrays [d3()] of ints", by the composite type rules applied
> to
> conditional expressions. But when the expression is executed, all
> three
> dimensions are needed to evaluate the [a][b][c][d][e][f] array
> reference,
> but only one of the dimensions appears in an expression which should be
> evaluated according to the rules for evaluation of conditional
> expressions. Furthermore, the return value of d2() may depend on the
> prior calls to c2() and z2() in that part of the conditional
> expression,
> so if c1() returns nonzero it might not suffice simply to evaluate d2()
> and d3() as well as d1(); c2(), z2() and z3() would also need to be
> evaluated.
My front end, and Comeau's oneline compiler, both give a similar
message:
"/tmp/foo.c", line 10: error: expression must point to a complete type
int r = (c1()
^
which seems reasonable based on my understanding of composite types
of VLA types: that either satisfies the requirements of, and therefore
can be taken to be, the composite type.
Neil.
