Re: A pass that worked in gcc-4.6.2 fails in gcc-4.7.2
On Sun, Feb 3, 2013 at 7:26 AM, Sudakshina Das wrote:
> Hello,
>
> Now I am trying to convert the same pass into a dynamic plugin. Since
> I was having trouble doing so, I tried adding a simple dynamic plugin
> which would just dump the cfg using gimple_dump_cfg. But even in this
> simple plugin I faced the same problem, as explained below.
>
> When I build my plugin using ../install/bin/g++ it would not give any
> errors. But when I used gcc instead of g++, it gave the following
> error during runtime :
>
> cc1: error: cannot load plugin ./plugin.so
> ./plugin.so: undefined symbol: decl_assembler_name
> make: *** [test] Error 1
>
> However, this symbol decl_assembler_name (a function) and is not
> present anywhere in my plugin. It is declared in tree.c so and is not
> static, so I even tried including tree.h and declaring the function as
> extern.
>
> I don't know what else to do!!
You have to compile the plugin with a C++ compiler, as GCC 4.7 is now
built as a C++ program.
Richard.
> Sudakshina
>
>
>
>
> On Sat, Jan 26, 2013 at 1:16 AM, Sudakshina Das
> wrote:
>>
>> On Fri, Jan 25, 2013 at 9:27 PM, Richard Biener
>> wrote:
>> > On Fri, Jan 25, 2013 at 3:57 PM, Sudakshina Das
>> > wrote:
>> >> On Fri, Jan 25, 2013 at 8:02 PM, Richard Biener
>> >> wrote:
>> >>> On Fri, Jan 25, 2013 at 3:05 PM, Sudakshina Das
>> >>> wrote:
>> On Fri, Jan 25, 2013 at 9:46 AM, Sudakshina Das
>> wrote:
>> >
>> > On Thu, Jan 24, 2013 at 5:15 PM, Richard Biener
>> > wrote:
>> > >
>> > > On Thu, Jan 24, 2013 at 7:06 AM, Sudakshina Das
>> > > wrote:
>> > > > Dear all,
>> > > >
>> > > > I am currently updating a pass that was made for gcc-4.6.*, so
>> > > > that it
>> > > > works for gcc.4.7.2.
>> > > >
>> > > > In the pass for gcc-4.6.*, a code fragment from
>> > > > tree-ssa-structalias.c
>> > > > was picked up and used.
>> > > > Given below is the fragment taken form create_function_info_for
>> > > > () .
>> > > > This fragment was used to create variable information for the
>> > > > function
>> > > > and it was picked up to perform a similar operation in the added
>> > > > pass
>> > > > as well.
>> > > >
>> > > > But in gcc-4.7.2 some changes are introduced in the fragment.
>> > > > The code
>> > > > given below shows the changes that have been introduced in
>> > > > create_function_info_for () of tree-ssa-structalias.c in
>> > > > gcc-4.7.2
>> > > > along with the original code in the comments.
>> > > >
>> > > > /* Add one representative for all further args. */
>> > > > if (is_varargs)
>> > > > {
>> > > > varinfo_t argvi;
>> > > > const char *newname;
>> > > > char *tempname;
>> > > > tree decl;
>> > > >
>> > > > asprintf (&tempname, "%s.varargs", name);
>> > > > newname = ggc_strdup (tempname);
>> > > > free (tempname);
>> > > >
>> > > > /* We need sth that can be pointed to for va_start. */
>> > > >
>> > > > / CHANGED CODE in GCC-4.7.2 ***/
>> > > > decl = build_fake_var_decl (ptr_type_node);
>> > > >
>> > > > / ORIGINAL CODE in GCC-4.6.2 ***
>> > > > /* decl = create_tmp_var_raw (ptr_type_node, name);
>> > > > get_var_ann (decl);
>> > > > */
>> > > >
>> > > > argvi = new_var_info (decl, newname);
>> > > > argvi->offset = fi_parm_base + num_args;
>> > > > argvi->size = ~0;
>> > > > argvi->is_full_var = true;
>> > > > argvi->is_heap_var = true;
>> > > > argvi->fullsize = vi->fullsize;
>> > > > gcc_assert (prev_vi->offset < argvi->offset);
>> > > > prev_vi->next = argvi;
>> > > > prev_vi = argvi;
>> > > > }
>> > > >
>> > > > return vi;
>> > > >
>> > > >
>> > > > So I made the same changes in the pass where this fragment was
>> > > > used.
>> > > > But after making the changes the pass is now giving an "internal
>> > > > compiler error" and a "segmentation fault" at runtime.
>> > > >
>> > > > After debugging I could narrow it down to the function
>> > > > build_fake_var_decl() and to be specific at the memory
>> > > > allocation
>> > > > statement highlighted below.
>> > > >
>> > > >
>> > > > tree
>> > > > build_fake_var_decl (tree type)
>> > > > {
>> > > > / My debugging showed that the control
>> > > > came
>> > > > here */
>> > > > tree decl = (tree) XOBNEW (&fake_var_decl_obstack, struct
>> > > > tree_var_decl);
>> > > > / But did not come here
>> > > > **/
>> > > > memset (decl, 0, sizeof (struct tree_var_decl));
>> > > > TREE_SET_COD
coverage license information
Hi, I'd like to add coverage support to Xen. I imported some headers from Linux kernel which mainly came from gcov-io.h and the structures used internally by GCC. Our problem is currently about the license. In gcov-io.h is stated that license is mainly GPL2 which the exception that linking the "library" with other files does not cause these files to be GPL2. Now however I'm not linking to any library but just using the structure declaration inside the header to produce a blob that is currently converted into GCC files by an external utility (Xen has not file system so we extract coverage information). It's not a problem to use these headers/structure from Xen (which is GPL2) but we'd like to have these defines in our public include headers. The license however of these headers is quite open and allow to be used for instance in commercial programs. How the license would affect these programs? Another question we have is the stability of these structures. Can we just check the version field of gcov_info to make sure that the internal structure is not changed or is it expected that even this field would change (for instance position or size inside the structure) ? Regards, Frediano
DRIVER
I NEED A DRIVER FOR MY WIFE
Re: coverage license information
On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio wrote: > > I imported some headers from Linux kernel which mainly came from > gcov-io.h and the structures used internally by GCC. > > Our problem is currently about the license. In gcov-io.h is stated that > license is mainly GPL2 which the exception that linking the "library" > with other files does not cause these files to be GPL2. Now however I'm > not linking to any library but just using the structure declaration > inside the header to produce a blob that is currently converted into GCC > files by an external utility (Xen has not file system so we extract > coverage information). > > It's not a problem to use these headers/structure from Xen (which is > GPL2) but we'd like to have these defines in our public include headers. > The license however of these headers is quite open and allow to be used > for instance in commercial programs. How the license would affect these > programs? > > Another question we have is the stability of these structures. Can we > just check the version field of gcov_info to make sure that the internal > structure is not changed or is it expected that even this field would > change (for instance position or size inside the structure) ? You neglected to say which version of GCC you are using. In current GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime Library Exception 3.1 (http://www.gnu.org/licenses/gcc-exception-3.1.html). I don't fully grasp the situation in which a user of xen would want to #include this header file. But if a program does #include the header file, then in the strictest possible reading that program would be covered by GPLv3 plus the GCC Runtime Library Exception. That would impose certain requirements on the program, basically that if it is compiled by a version of GCC with a proprietary extension, the program may not be distributed in binary form. Those requirements already apply to essentially any program compiled by a current version of GCC. Inciuding the header file gcov-io.h should not add any additional requirements. Hope this helps. This is of course not legal advice, but you are unlikely to get good legal advice in this area. Ian
Re: [Xen-devel] coverage license information
>>> On 04.02.13 at 17:46, Ian Lance Taylor wrote: > On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio > wrote: >> >> I imported some headers from Linux kernel which mainly came from >> gcov-io.h and the structures used internally by GCC. >> >> Our problem is currently about the license. In gcov-io.h is stated that >> license is mainly GPL2 which the exception that linking the "library" >> with other files does not cause these files to be GPL2. Now however I'm >> not linking to any library but just using the structure declaration >> inside the header to produce a blob that is currently converted into GCC >> files by an external utility (Xen has not file system so we extract >> coverage information). >> >> It's not a problem to use these headers/structure from Xen (which is >> GPL2) but we'd like to have these defines in our public include headers. >> The license however of these headers is quite open and allow to be used >> for instance in commercial programs. How the license would affect these >> programs? >> >> Another question we have is the stability of these structures. Can we >> just check the version field of gcov_info to make sure that the internal >> structure is not changed or is it expected that even this field would >> change (for instance position or size inside the structure) ? > > You neglected to say which version of GCC you are using. In current > GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime > Library Exception 3.1 > (http://www.gnu.org/licenses/gcc-exception-3.1.html). > > I don't fully grasp the situation in which a user of xen would want to > #include this header file. But if a program does #include the header > file, then in the strictest possible reading that program would be > covered by GPLv3 plus the GCC Runtime Library Exception. That would > impose certain requirements on the program, basically that if it is > compiled by a version of GCC with a proprietary extension, the program > may not be distributed in binary form. You probably meant "binary only form" here? Jan > Those requirements already > apply to essentially any program compiled by a current version of GCC. > Inciuding the header file gcov-io.h should not add any additional > requirements. > > Hope this helps. This is of course not legal advice, but you are > unlikely to get good legal advice in this area. > > Ian > > ___ > Xen-devel mailing list > xen-de...@lists.xen.org > http://lists.xen.org/xen-devel
Re: System V Application Binary Interface 0.99.5
On Sun, Feb 3, 2013 at 12:09 PM, Jan Hubicka wrote: >> On 02/01/2013 12:38 AM, Jan Hubicka wrote: >> > Doing the extensions at caller side always is however IMO a preformance >> > bug in >> > GCC. We can definitly drop them at -Os, for non-PRS targets and for calls >> > within compilation unit where we know that GCC is not really producing >> > code like in Michael's testcase. >> >> Well we can, yeah, at the cost of breaking interworking with LLVM. >> Do we care? ;-) > > Yes, we (at least I) care ;) > The bug ought to be fixed at LLVM side, is there PR filled in? For time being > we can optimize local calls. I remember that in the past I ran over > benchmarks > where these extra casts was making us to lose compared to other compilers, so > it > is not 100% uninteresting detail. > There are a couple bugs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44490 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44532 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 -- H.J.
Re: [Xen-devel] coverage license information
On Mon, Feb 4, 2013 at 9:05 AM, Jan Beulich wrote: On 04.02.13 at 17:46, Ian Lance Taylor wrote: >> On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio >> wrote: >>> >>> I imported some headers from Linux kernel which mainly came from >>> gcov-io.h and the structures used internally by GCC. >>> >>> Our problem is currently about the license. In gcov-io.h is stated that >>> license is mainly GPL2 which the exception that linking the "library" >>> with other files does not cause these files to be GPL2. Now however I'm >>> not linking to any library but just using the structure declaration >>> inside the header to produce a blob that is currently converted into GCC >>> files by an external utility (Xen has not file system so we extract >>> coverage information). >>> >>> It's not a problem to use these headers/structure from Xen (which is >>> GPL2) but we'd like to have these defines in our public include headers. >>> The license however of these headers is quite open and allow to be used >>> for instance in commercial programs. How the license would affect these >>> programs? >>> >>> Another question we have is the stability of these structures. Can we >>> just check the version field of gcov_info to make sure that the internal >>> structure is not changed or is it expected that even this field would >>> change (for instance position or size inside the structure) ? >> >> You neglected to say which version of GCC you are using. In current >> GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime >> Library Exception 3.1 >> (http://www.gnu.org/licenses/gcc-exception-3.1.html). >> >> I don't fully grasp the situation in which a user of xen would want to >> #include this header file. But if a program does #include the header >> file, then in the strictest possible reading that program would be >> covered by GPLv3 plus the GCC Runtime Library Exception. That would >> impose certain requirements on the program, basically that if it is >> compiled by a version of GCC with a proprietary extension, the program >> may not be distributed in binary form. > > You probably meant "binary only form" here? Yes. Thanks. It is (of course) OK to distribute in binary form if sources are also included, or made available. Ian
Error in gcc.gnu. org/install/configure.html webpage
Hi there, When reading through http://gcc.gnu.org/install/configure.html configuration options, I spotted an inconsistency regarding Graphite loop optimization: " --with-ppl=pathname --with-ppl-include=pathname --with-ppl-lib=pathname --with-cloog=pathname --with-cloog-include=pathname --with-cloog-lib=pathname If you do not have ISL and the CLooG libraries installed in a standard location and you want to build GCC, you can explicitly specify the directory where they are installed (`--with-isl=islinstalldir', `--with-cloog=clooginstalldir'). The --with-isl=islinstalldir option is shorthand for --with-isl-lib=islinstalldir/lib and --with-isl-include=islinstalldir/include. Likewise the --with-cloog=clooginstalldir option is shorthand for --with-cloog-lib=clooginstalldir/lib and --with-cloog-include=clooginstalldir/include. If these shorthand assumptions are not correct, you can use the explicit include and lib options directly. " The listed option is —with-ppl, but the description refers to —with-isl instead. This is rather tricky. Hope you can fix this! Many thanks for your great work, Z.W.
Re: coverage license information
Il 04/02/2013 17:46, Ian Lance Taylor ha scritto: > On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio > wrote: >> >> I imported some headers from Linux kernel which mainly came from >> gcov-io.h and the structures used internally by GCC. >> >> Our problem is currently about the license. In gcov-io.h is stated that >> license is mainly GPL2 which the exception that linking the "library" >> with other files does not cause these files to be GPL2. Now however I'm >> not linking to any library but just using the structure declaration >> inside the header to produce a blob that is currently converted into GCC >> files by an external utility (Xen has not file system so we extract >> coverage information). >> >> It's not a problem to use these headers/structure from Xen (which is >> GPL2) but we'd like to have these defines in our public include headers. >> The license however of these headers is quite open and allow to be used >> for instance in commercial programs. How the license would affect these >> programs? >> >> Another question we have is the stability of these structures. Can we >> just check the version field of gcov_info to make sure that the internal >> structure is not changed or is it expected that even this field would >> change (for instance position or size inside the structure) ? > > You neglected to say which version of GCC you are using. In current > GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime > Library Exception 3.1 > (http://www.gnu.org/licenses/gcc-exception-3.1.html). Would it make sense to release the header file under a permissive license or even public domain? The information there is just ABI, it's dubious that it is copyrightable at all. If two colleagues of Frediano's did a clean-room reverse engineering, the result would really be indistiguishable from the original. Paolo
Re: coverage license information
On Mon, Feb 4, 2013 at 12:56 PM, Paolo Bonzini wrote: > > Would it make sense to release the header file under a permissive > license or even public domain? > > The information there is just ABI, it's dubious that it is copyrightable > at all. If two colleagues of Frediano's did a clean-room reverse > engineering, the result would really be indistiguishable from the original. I agree that the information in gcov-io.h is almost certainly uncopyrightable. But since it's under the GCC Runtime Library Exception, which applies to approximately every program compiled by GCC, I don't think it makes much difference one way or another. I'm not opposed to asking the FSF to relicense the file, I just don't think it matters. Ian
