About nested Designated Initializers
Hi all,
From info gcc I know it accepts a series of `.FIELDNAME' and `[INDEX]'
designators,
like
struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
But in my case, I have a struct with array of int as members,
struct mbox {
int x[20];
int y[20];
};
and want to declare a mbox variable with partially initialized, like
struct mbox mbox = { .x = { 1, 2 }, .y[19] = 3, };
During compiling, I see warnings, and the compiled program doesn't
work like what I think,
slfe.c:823: warning: braces around scalar initializer
slfe.c:823: warning: (near initialization for `mbox.s[2]')
slfe.c:825: warning: passing arg 1 of `hexdump' from incompatible pointer type
Then I use a hexdump on this var, found it's working like
struct mbox mbox = { .x = { 1, 2 }, .y = 3, };
I wonder if this is gcc bug, or if gcc doesn't support this kind of
designated initializer,
But if this is supported,
struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
Why can't we support this?
struct mbox mbox = { .x = { 1, 2 }, .y[19] = 3, };
Or someone knows which standard (like C99?) has related spec?
Thanks,
5.20 Designated Initializers
Standard C89 requires the elements of an initializer to appear in a
fixed order, the same as the order of the elements in the array or
structure being initialized.
You can also write a series of `.FIELDNAME' and `[INDEX]' designators
before an `=' to specify a nested subobject to initialize; the list is
taken relative to the subobject corresponding to the closest
surrounding brace pair. For example, with the `struct point'
declaration above:
struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
--
Cheng Renquan (程任全)
Re: About nested Designated Initializers
On Tue, Jul 19, 2011 at 2:56 PM, Cheng Renquan wrote:
> Hi all,
>
> From info gcc I know it accepts a series of `.FIELDNAME' and `[INDEX]'
> designators,
> like
>
> struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
>
>
> But in my case, I have a struct with array of int as members,
>
> struct mbox {
> int x[20];
> int y[20];
> };
>
> and want to declare a mbox variable with partially initialized, like
>
> struct mbox mbox = { .x = { 1, 2 }, .y[19] = 3, };
Sorry, my above example is not good, it compiles and works ok;
What's really not working is this example by union:
union mbox {
int w[3];
short s[6];
char c[12];
};
If I declare a union mbox and want to initialize w[0], s[2] and c[6],
union mbox mbox = { .w = { 1, }, .s[2] = 2, .c[6] = 's' };
I want a mbox initialized with these 12 bytes (on little endian):
: 01 00 00 00 02 00 73 00 00 00 00 00
And actually I got these:
: 00 00 00 00 00 00 73 00 00 00 00 00
the hexdump result shows only last .c[6] make effect,
Wonder if this is a bug or not supported? Thanks,
Re: About nested Designated Initializers
On Tue, Jul 19, 2011 at 4:18 PM, Jonathan Wakely wrote:
> This question is more suitable for the gcc-help list, as it is a
> question about using gcc not about developing it.
What I insist to discuss here is I think this may be a gcc's bug,
could be fixed in some future day?
>
> What you want is not supported. The member of the union that is
> initialized will either be the int[3], or the short[6], or the
> char[12]. You cannot initialize some bytes of one member and some
> bytes of another like that.
Do you know why is it not supported? Is there some standard (like
C99?) forbid to
implement it?
Otherwise we could see it as a gcc bug;
>
> Maybe you should just do this instead:
>
> union mbox mbox = { .c[0] = 1, .c[4] = 2, .c[6] = 's' };
Sorry, my above still not a good example, what I mean to initialize is
.w[0] is a real 4 bytes integer, .s[2] is real short, those are not
convenient to write in .c[...];
like this example:
union mbox mbox = { .w[0] = 0x12345678, .s[2] = 0xabcd, .c[6] = 's' };
I tried hexdump again, only last one .c[6] was initialized,
I think to initialize .w[0] / .s[2] / .c[6] have no conflict with each
other, why can't we implement such behavior?
Thanks;
Re: About nested Designated Initializers
On Tue, Jul 19, 2011 at 5:04 PM, Jonathan Wakely wrote:
> This isn't the right list for that either. Questions about using gcc
> should go to gcc-help, bug reports should go to bugzilla.
I know how to use current gcc implementation correctly, I'm thinking
of a new feature in future gcc version, shouldn't we discuss potential
ideas of gcc on this list?
>
>> could be fixed in some future day?
>
> It's not a bug, it's how unions work.
So if not a bug, it should not go to bugzilla?
>
>>> What you want is not supported. The member of the union that is
>>> initialized will either be the int[3], or the short[6], or the
>>> char[12]. You cannot initialize some bytes of one member and some
>>> bytes of another like that.
>>
>> Do you know why is it not supported? Is there some standard (like
>> C99?) forbid to
>> implement it?
>
> C99 doesn't even support .c[6] syntax for initializers, it's a GCC extension.
>
>> Otherwise we could see it as a gcc bug;
>
> I don't think so.
>
>>>
>>> Maybe you should just do this instead:
>>>
>>> union mbox mbox = { .c[0] = 1, .c[4] = 2, .c[6] = 's' };
>>
>> Sorry, my above still not a good example, what I mean to initialize is
>> .w[0] is a real 4 bytes integer, .s[2] is real short, those are not
>> convenient to write in .c[...];
>>
>> like this example:
>>
>> union mbox mbox = { .w[0] = 0x12345678, .s[2] = 0xabcd, .c[6] = 's' };
>>
>> I tried hexdump again, only last one .c[6] was initialized,
>>
>> I think to initialize .w[0] / .s[2] / .c[6] have no conflict with each
>> other, why can't we implement such behavior?
>
> Because only one union member can be initialized, and the union
Who (or what standard) defined that behavior?
Can we implement a new behavior as a new GCC extension when there is
no conflict?
(or futhermore, we could detect potential conflicts and prompt the
user with warnings)
union mbox mbox = { .w[0] = 0x12345678, .s[2] = 0xabcd, .c[6] = 's' };
as same semantic of:
union mbox mbox;
mbox.w[0] = 0x12345678;
mbox.s[2] = 0xabcd;
mbox.c[6] = 's';
It saves #LOC, looks straightforward and cool, isn't it?
From technology perspective, I didn't see any reasons preventing us
from implementing it,
Or at least, if you insist the syntax,
should we at least give some warnings because it didn't work as I
expected before;
(to warn the user that .w and .s initializers doesn't effect?)
union mbox mbox = { .w[0] = 0x12345678, .s[2] = 0xabcd, .c[6] = 's' };
> members are w, s, and c, not w[0] etc.
>
> If you want finer-grained control of sub-objects of the union members
> then set the elements later via assignment, instead of trying to do it
> via initialization.
I know that way in above code already,
--
Cheng Renquan (程任全)
[RFC] dotgen: Generate Graphiviz format .dot dump of functions cfg
From: Dennis, CHENG Renquan
The GCC has default support of dumping gimple cfg in vcg format, but when I
was trying to find a tool to interpret the *.006t.vcg dump file, or to generate
a vector image format, it seemed not easy, the vcgviewer [1] not mature as
Graphviz, and Graph::Easy [2] is a perl CPAN module, but why not add a pass
to generate Graphviz .dot format default? These days it seems Graphviz is more
popular;
[1] http://code.google.com/p/vcgviewer/
[2] http://search.cpan.org/~tels/Graph-Easy/
This is a tentative implementation on dumping ".dot" files directly,
I have tested it with gcc-4.5-20100708 snapshot, it works well [*], however,
a feature of the original vcg not implemented,
1) I don't know how to represent the priority information in a .dot file?
[*] the pass->name is "*cfg2dot", means to translate cfg into a dot file, the
name starting with a star is to conform gcc without dump files, because gcc
default pass dump files implementation would always dump a function name line
with ";; Function ..." that is not understood by Graphviz, so I choose to
implement it with dump_register low-level APIs; however, current gcc doesn't
understand plugin registered passes with name starting with a star, it is
better to apply this patch first;
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00912.html
Comments are always welcomed, please give ideas on how this could be more
useful?
If asked, I can also transform this into a patch on gcc for official inclusion,
just changed it from a plugin registered pass to gcc internal pass;
+/* Generate Graphiviz format .dot dump of functions control flow graph,
+ similar as the gcc internal vcg dump.
+ Copyright (C) 2010 by
+ Author: "Dennis, CHENG Renquan"
---
Makefile| 26
pass-dgen.c | 206 +++
2 files changed, 232 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
new file mode 100644
index 000..453fbeb
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,26 @@
+
+GCC = gcc
+CC = gcc
+
+PLUGIN_FILE = dotgen.so
+PLUGIN_SOURCE_FILES = pass-dgen.c
+PLUGIN_OBJECT_FILES = $(patsubst %.c,%.o,$(PLUGIN_SOURCE_FILES))
+
+GCCPLUGINS_DIR := $(shell $(GCC) -print-file-name=plugin)
+CFLAGS += -I$(GCCPLUGINS_DIR)/include -I$(with_gmp)/include -Wall -O2
+
+all: $(PLUGIN_FILE)
+
+$(PLUGIN_FILE): $(PLUGIN_OBJECT_FILES)
+ $(GCC) -shared -o $@ $^
+
+.PHONY: clean all test
+
+test:
+ @if [ ! -d dump-files ]; then mkdir dump-files; fi
+ $(GCC) -fplugin=./$(PLUGIN_FILE) \
+ -fdump-tree-all -dumpdir dump-files/ \
+ -c test1.c
+
+clean:
+ @-rm -f *~ *.o $(PLUGIN_FILE)
diff --git a/pass-dgen.c b/pass-dgen.c
new file mode 100644
index 000..3bf9634
--- /dev/null
+++ b/pass-dgen.c
@@ -0,0 +1,206 @@
+/* Generate Graphiviz format .dot dump of functions control flow graph,
+ similar as the gcc internal vcg dump.
+ Copyright (C) 2010 by
+ Author: "Dennis, CHENG Renquan"
+
+This software is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+It is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+<http://www.gnu.org/licenses/>. */
+
+#include "gcc-plugin.h"
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "tree.h"
+#include "rtl.h"
+#include "basic-block.h"
+#include "function.h"
+#include "langhooks.h"
+#include "tree-flow.h"
+#include "tree-dump.h"
+#include "tree-pass.h"
+
+int plugin_is_GPL_compatible;
+
+static const char *plugin_name;
+static struct plugin_info _version_help_info =
+{
+ "0.1", /* version */
+ "Dump internal gimple cfg into Graphviz .dot format",
+ /* help */
+};
+
+static void
+gimple_cfg2dot (FILE *file)
+{
+ edge e;
+ edge_iterator ei;
+ basic_block bb;
+ const char *funcname
+= lang_hooks.decl_printable_name (current_function_decl, 2);
+
+ /* Write the file header. */
+ fprintf (file, "// Function %s\n", funcname);
+ fprintf (file, "digraph graph_%s {\n\n", funcname);
+ fprintf (file, " graph [ label=%s, labelloc=top ];\n\n", funcname);
+
+ /* Write blocks and edges. */
+ FOR_EACH_EDGE (e, ei, ENTRY_BLOCK_PTR->succs)
+{
+ fprintf (file, " ENTRY -> %d", e->dest->index);
+
+ /
Re: [RFC] dotgen: Generate Graphiviz format .dot dump of functions cfg
On Mon, Jul 12, 2010 at 1:59 AM, Dennis, CHENG Renquan
wrote:
> From: Dennis, CHENG Renquan
>
> The GCC has default support of dumping gimple cfg in vcg format, but when I
> was trying to find a tool to interpret the *.006t.vcg dump file, or to
> generate
> a vector image format, it seemed not easy, the vcgviewer [1] not mature as
> Graphviz, and Graph::Easy [2] is a perl CPAN module, but why not add a pass
> to generate Graphviz .dot format default? These days it seems Graphviz is more
> popular;
>
> [1] http://code.google.com/p/vcgviewer/
> [2] http://search.cpan.org/~tels/Graph-Easy/
>
> This is a tentative implementation on dumping ".dot" files directly,
I've found the best place to add Graphviz dot format may be the graph.c file,
static const char *const graph_ext[] =
{
/* no_graph */ "",
/* vcg */ ".vcg",
};
maybe I could add one more format ".dot" support, like:
static const char *const graph_ext[] =
{
/* no_graph */ "",
/* vcg */ ".vcg",
/* dot */ ".dot",
};
Someone please recommend a good vcg format manipulate or conversion
program, if you know one, as long as is also free software; to stop my
work on the dot format support; my only incentive is that i cannot
find a good vcg => {ps,svg,png,...} conversion tool;
Thank you;
Re: on how to compile gcc-4.6 correctly?
On Mon, Sep 6, 2010 at 10:51 PM, Kai Ruottu wrote: > This seems to be defined in a header generated during the build > into the $BUILD/gcc : > > [r...@localhost gcc]# grep ggc_alloc_cleared_lang_type *.h > gtype-desc.h:#define ggc_alloc_cleared_lang_type_u() ((union lang_type_u > *)(ggc_internal_cleared_alloc_stat (sizeof (union lang_type_u) > MEM_STAT_INFO))) > > On CentOS 5.5/ia32 the build seemed to succeed for the > 'x86_64-linux-gnu' target, using gcc-4.1.2 as the host > and build compiler. Must check the Fedora 13/x86_64 > host with its gcc-4.4.4 too but I wouldn't expect any > change with it... > > So maybe the Gentoo distro has some problem... No, I've tried compiling gcc-4.6-20100911 on ubuntu 10.04, the same problem also happened; and I also found that macro was defined in a generated header file, in the gcc build directory; renq...@flyer-1-1:~/src/gcc-4.6-build$ grep -RsInw ggc_alloc_cleared_lang_type gcc/ gcc/gtype-desc.h:2451:#define ggc_alloc_cleared_lang_type() ((struct lang_type *)(ggc_internal_cleared_alloc_stat (sizeof (struct lang_type) MEM_STAT_INFO))) this definition just doesn't accept any arguments, but inside gcc/c-decl.c:7028 and 7311: space = ggc_alloc_cleared_lang_type (sizeof (struct lang_type)); lt = ggc_alloc_cleared_lang_type (sizeof (struct lang_type)); both passes 1 argument, so the compiler report error, so the problem is how can you succeed compiling that? renq...@flyer-1-1:~/src/gcc-4.6-build$ (cd gcc/; gcc -c -DIN_GCC_FRONTEND -g -O2 -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 -I. -I. -I../../gcc-4.6-20100911/gcc -I../../gcc-4.6-20100911/gcc/. -I../../gcc-4.6-20100911/gcc/../include -I../../gcc-4.6-20100911/gcc/../libcpp/include -I/opt/gektop/usr/include -I../../gcc-4.6-20100911/gcc/../libdecnumber -I../../gcc-4.6-20100911/gcc/../libdecnumber/bid -I../libdecnumber ../../gcc-4.6-20100911/gcc/c-decl.c) ../../gcc-4.6-20100911/gcc/c-decl.c: In function ‘grokdeclarator’: ../../gcc-4.6-20100911/gcc/c-decl.c:5536: warning: format not a string literal and no format arguments ../../gcc-4.6-20100911/gcc/c-decl.c: In function ‘grokparms’: ../../gcc-4.6-20100911/gcc/c-decl.c:6197: warning: format not a string literal and no format arguments ../../gcc-4.6-20100911/gcc/c-decl.c:7028:64: error: macro "ggc_alloc_cleared_lang_type" passed 1 arguments, but takes just 0 ../../gcc-4.6-20100911/gcc/c-decl.c: In function ‘finish_struct’: ../../gcc-4.6-20100911/gcc/c-decl.c:7028: error: ‘ggc_alloc_cleared_lang_type’ undeclared (first use in this function) ../../gcc-4.6-20100911/gcc/c-decl.c:7028: error: (Each undeclared identifier is reported only once ../../gcc-4.6-20100911/gcc/c-decl.c:7028: error: for each function it appears in.) ../../gcc-4.6-20100911/gcc/c-decl.c:7311:62: error: macro "ggc_alloc_cleared_lang_type" passed 1 arguments, but takes just 0 ../../gcc-4.6-20100911/gcc/c-decl.c: In function ‘finish_enum’: ../../gcc-4.6-20100911/gcc/c-decl.c:7311: error: ‘ggc_alloc_cleared_lang_type’ undeclared (first use in this function) Thanks,
Re: on how to compile gcc-4.6 correctly?
On Mon, Sep 13, 2010 at 8:16 PM, Laurynas Biveinis wrote: > I am the author of how these macros are generated, but somehow I have > missed this thread initially. Could you send me off-list that > gtype-desc.h file? The problematic gtype-desc.h has been sent to Laurynas separately, I was compiling only the gcc-core-4.6-20100911.tar.bz2 tarball, because I only want a c compiler; I searched the macro ggc_alloc_cleared_lang_type through out the source and build directory, only one definition and two usage, with conflict arguments passing: ../path/to/gcc-build$ grep -RsInw ggc_alloc_cleared_lang_type ../gcc-4.6-20100911/ gcc/ ../gcc-4.6-20100911/gcc/c-decl.c:7027: space = ggc_alloc_cleared_lang_type (sizeof (struct lang_type)); ../gcc-4.6-20100911/gcc/c-decl.c:7310: lt = ggc_alloc_cleared_lang_type (sizeof (struct lang_type)); gcc/gtype-desc.h:2451:#define ggc_alloc_cleared_lang_type() ((struct lang_type *)(ggc_internal_cleared_alloc_stat (sizeof (struct lang_type) MEM_STAT_INFO))) and in fact, I'm interested why this Kai Ruottu got a ggc_alloc_cleared_lang_type_u macro with 0 arguments in gtype-desc.h while my gtype-desc.h doesn't have that macro? I'm not sure he could get ggc_alloc_cleared_lang_type macro or not, so how can he succeed his compilation; On Mon, Sep 6, 2010 at 10:51 PM, Kai Ruottu wrote: > This seems to be defined in a header generated during the build > into the $BUILD/gcc : > > [r...@localhost gcc]# grep ggc_alloc_cleared_lang_type *.h > gtype-desc.h:#define ggc_alloc_cleared_lang_type_u() ((union lang_type_u > *)(ggc_internal_cleared_alloc_stat (sizeof (union lang_type_u) > MEM_STAT_INFO))) > > Thanks, > -- > Laurynas > -- Cheng, from Singapore
Re: on how to compile gcc-4.6 correctly?
On Mon, Sep 13, 2010 at 9:32 PM, Laurynas Biveinis
wrote:
> Thanks. I assume that you pass --enable-languages=c to configure?
No, just a very simple configure and make command:
../path/to/gcc-4.6-build$ time { ../gcc-4.6-20100911/configure
--prefix=/usr --disable-nls --with-system-zlib && make --debug=b; } |&
tee build-log
Because the source code is uncompressed from gcc-core-4.6-..., it only
includes the c compiler, I leave the configure to figure out there is
only c compiler source code;
>
> I will investigate this tomorrow and will get back to you.
>
> Regards,
> --
> Laurynas
>
--
Cheng, from Singapore
Re: on how to compile gcc-4.6 correctly?
For anyone could succeed compiling gcc-4.6, could you paste a correct ggc_alloc_cleared_lang_type macro ? just run this grep command under your build directory, gcc-4.6-build$ grep -RsInw ggc_alloc_cleared_lang_type gcc/ gcc/gtype-desc.h:2451:#define ggc_alloc_cleared_lang_type() ((struct lang_type *)(ggc_internal_cleared_alloc_stat (sizeof (struct lang_type) MEM_STAT_INFO))) thanks,
Re: [PATCH] Add missing variable_size GTY annotations (was Re: on how to compile gcc-4.6 correctly?)
On Tue, Sep 14, 2010 at 9:17 PM, Laurynas Biveinis wrote: > I have reproduced it and the patch below fixes the issue, sorry for > breaking things. Dennis, could you see if it works for you? > > When gcc-core tarball is used without other frontends, gengtype does > not get to see that lang_type is in fact variable_size and when the > frontends are present, their variable_size annotations mask the fact > that c-lang.h does not have it. This is something that really should > be diagnosed by gengtype. > > I will apply it to trunk later as obvious. Well, I have tested and verified that patch works well, gcc-core-4.6-20100911 compiled well on my Ubuntu and Gentoo with my default simplified configuration setting; Tested-by: "Dennis, CHENG Renquan" > > gcc/ChangeLog: > > 2010-09-14 Laurynas Biveinis > > * c-lang.h (struct lang_type): Add variable_size GTY option. > > gcc/lto/ChangeLog: > > 2010-09-14 Laurynas Biveinis > > * lto-tree.h (struct lang_type): Add variable_size GTY option.
