Libgcc and its license

2012-10-10 Thread Gabor Loki 
Hi everyone,

I have a question about GCC licensing related to libgcc.

I asked Nick Clifton who did a license change in the past (Thu Apr 9
15:00:19 2009 UTC - r145841) about how he did that commit, changing
GPLv2 licenses to GPLv3 with GCC Runtime Exception. And he suggested me
to ask the GCC steering committee about any kind of licensing issue.

I am wondering on this change now, because we would like to use libgcc
with GPLv3 with GCC Runtime Exception.

Theoretically libgcc should has the GPLv3 with Runtime Exception
license, but the evidences say something else. My research shows that
libgcc uses different licenses, for example: GPLv2, LGPLv2.1 and GPLv3
*without* Runtime Exception.

I did the following in my research:
1) list which object files are included in libgcc.a
2) repeat all the compilation commands related to the previous list in
the proper environment. The only thing which I have added to the
compilation command is an extra "-E" option to preprocess every sources.
3) create a unique list of all source and header files from the
preprocessed files.
4) at final all source, header and generated files are checked for their
licenses.

So, at the end I found several files do not have the GPLv3 with Runtime
Exception license.

For example:
1) fixed-bit.c is used in several objects creation.
  - this file includes tm.h
  - tm.h includes options.h
  - and options.h includes flag-types.h which has GPLv3 license
*without* Runtime Exceptions

2) from fixed-bit.c again
  - tm.h includes newlib-stdint.h which has GPLv3 license *without*
Runtime Exceptions as well.

3) from fixed-bit.c
  - tconfig.h includes ansidecl.h with GPLv2 license.

I saw similar issues for filenames.h, longlong.h files as well. It looks
like all the files contain meaningful information for libgcc. So, they
cannot be skipped from the build process.

In additional this issue can be confirmed on different targets. I tried
x86, ARM and PPC with different environment. So, I assume this should be
more or less a general issue, independent from configs, libraries and
environment. BTW, there are several target specific files which has the
same issue (do not have GPLv3 w RE). For example: some parts of the
arm.h file are included in almost all object files for libgcc.a, and
arm.h has GPLv3 *without* RE.

I suppose all of the header files should have the GPLv3 with GCC Runtime
Exception license, because libgcc should have GPLv3 w RE. Am I right?

If so, how this change should be done? I know changing licenses is not
an easy task. The copyright/license holders should agree to this change,
shouldn't they?

So, what is your opinion about this? Is it possible to have such a
libgcc.a which has only the GPLv3 with GCC Runtime Exception license?

Thanks for any help you can give me on this topic!

Regards,
--Gabor


-- 
Gábor Lóki
research assistant

Department of Software Engineering, University of Szeged
Dugonics tér 13., H-6720 Szeged, Hungary
Phone: +36-62-546726
Fax: +36-62-546723
l...@inf.u-szeged.hu

thumb2 support

2012-10-10 Thread Grant 
Hello, I'm working with the BeagleBone and gcc-4.5.4 on Gentoo.  If I
try to compile the 3.6 kernel with CONFIG_THUMB2_KERNEL, I get:

arch/arm/boot/compressed/head.S:127: Error: selected processor does
not support requested special purpose register -- `mrs r2,cpsr'
arch/arm/boot/compressed/head.S:134: Error: selected processor does
not support requested special purpose register -- `mrs r2,cpsr'
arch/arm/boot/compressed/head.S:136: Error: selected processor does
not support requested special purpose register -- `msr cpsr_c,r2'

This post indicates that mainline gcc does not currently support thumb2:

https://groups.google.com/d/msg/beagleboard/P52fgMDzp8A/vupzuh71vdYJ

However, this indicates that thumb2 has been supported since 4.3:

http://gcc.gnu.org/gcc-4.3/changes.html

Can anyone clear this up?

- Grant

Re: thumb2 support

2012-10-10 Thread Ian Lance Taylor 
On Wed, Oct 10, 2012 at 4:42 AM, Grant  wrote:
> Hello, I'm working with the BeagleBone and gcc-4.5.4 on Gentoo.  If I
> try to compile the 3.6 kernel with CONFIG_THUMB2_KERNEL, I get:
>
> arch/arm/boot/compressed/head.S:127: Error: selected processor does
> not support requested special purpose register -- `mrs r2,cpsr'
> arch/arm/boot/compressed/head.S:134: Error: selected processor does
> not support requested special purpose register -- `mrs r2,cpsr'
> arch/arm/boot/compressed/head.S:136: Error: selected processor does
> not support requested special purpose register -- `msr cpsr_c,r2'
>
> This post indicates that mainline gcc does not currently support thumb2:
>
> https://groups.google.com/d/msg/beagleboard/P52fgMDzp8A/vupzuh71vdYJ
>
> However, this indicates that thumb2 has been supported since 4.3:
>
> http://gcc.gnu.org/gcc-4.3/changes.html
>
> Can anyone clear this up?

The errors are coming from an assembler file that is not part of the
GCC sources.  Are those instructions valid for Thumb2?  I don't know.
If they are valid, then the issue is with the assembler, which is not
part of GCC; check the version of the GNU binutils that you have
installed.  If those instructions are not valid, then you need to
change your source.

Ian

Ann: MELT plugin 0.9.7 for GCC 4.6, 4.7 and future 4.8

2012-10-10 Thread Basile Starynkevitch 

Dear All,

It is my pleasure to announce the MELT plugin 0.9.7 release for GCC 4.6, 4.7 
and future 4.8

You can download its source gnuzipped archive from
   http://gcc-melt.org/melt-0.9.7-plugin-for-gcc-4.6-or-4.7-or-4.8.tar.gz
this is a gnu-zipped source tar file of 5193713 bytes of 
md5sum 9873b7cb1363c3638457fe775a402aa9 extracted from the MELT branch of GCC 
svn rev. 192291 on october 10th 2012.

(there have been 4 release candidates before, but you should better use this 
release).



MELT is a high-level domain specific language to extend the GCC compiler. 
See http://gcc-melt.org/ for more. It is a free software implementation 
(GPLv3+ licensed, FSF copyrighted) of a plugin for GCC 4.6, 4.7 & 4.8 developped
on GNU/Linux/Debian/AMD64.

In addition of those wanting to extend GCC with a MELT extension, this release 
should
also interest many people interested in GCC, since it also provides a probe to 
show 
(interactively, with a graphical interface) some of the internal 
representations 
(Tree, Gimple, Gimple/SSA, ) at a given source location. For such a use you 
only 
need to compile with gcc -fplugin=melt -fplugin-arg-melt-mode=probe

This 0.9.7 MELT plugin release brings a lot of new features and bug fixes.




NEWS for 0.9.7 MELT plugin for GCC 4.6 & 4.7 & future 4.8
[[october, 10th, 2012]]

   Language improvement
   

 When creating an instance with definstance or instance, the
 translator checks that fields are filled with values. Previous
 versions of MELT could crash in that case.

 (CHEADER ...) constructs are working as documented.

 The Parma Polyhedra Library is removed from MELT.

 String values know their length, so safe access to some byte inside
 is possible.

   Added a lot of cmatchers (and implicit primitives) like
tree_boolean_false_node, tree_boolean_true_node,
tree_boolean_type_node, tree_char_type_node,
tree_const_ptr_type_node, tree_double_type_node,
tree_float_type_node, tree_int128_integer_type_node,
tree_int128_unsigned_type_node, tree_integer_minus_one_node,
tree_integer_one_node, tree_integer_type_node,
tree_integer_zero_node, tree_long_double_type_node,
tree_long_integer_type_node, tree_long_long_integer_type_node,
tree_long_long_unsigned_type_node,
tree_long_unsigned_type_node, tree_null_pointer_node,
tree_ptr_type_node, tree_short_integer_type_node,
tree_short_unsigned_type_node, tree_signed_char_type_node,
tree_size_type_node, tree_unsigned_char_type_node,
tree_unsigned_type_node, tree_void_type_node
   to access the very built-in trees known to GCC.
   Added more tree & gimple related matchers and primitives.

 Less spurious warnings when building MELT.


   Runtime improvements
   

  Add a runtime expression evaluation function
  TRANSLATE_RUN_MELT_EXPRESSIONS with a mode eval for initial
  evaluation of a sequence of expressions, and a mode repl for
  read-eval-print-loop, and a mode eval for evaluating and printing a
  given expression. Try e.g. 
 gcc -c -fplugin=melt  -fplugin-arg-melt-mode=eval \
-fplugin-arg-melt-arg='(list discr_tree class_sexpr)' \
empty.c

  The repl mode reads sequences of MELT expressions from stdin, each sequence 
should end 
  by two consecutive newlines.


  Advanced users could register their own finalized client data using
  the melt_payload_register_descriptor C function.

  The building procedure has been revamped. Advanced users could
  define their GCCMELT_BUILD_NOTIFICATION environment variable to
  e.g. a script meltbuild-notification like

  #! /bin/bash
  # first arg title, second arg message
  if [ "$DISPLAY" = ":0.0" -a -n "$DESKTOP_SESSION" -a $(which notify-send) 
]; then
 notify-send -t 3500 -i info "MELT BUILD: $1" "$2"
  else
 logger -t meltbuild -p user.info "$1=" "$2"
  fi

  and they will have a nice bubble notification under most Linux
  desktops of the major steps of the build. The building procedure is
  now quicker than before.

  Advanved MELT users can set their MELTGCC_NO_CHECK_RUNTIME to
  disable checking of the MELT runtime. This is notably needed when
  the MELT plugin is compiled for a cross compiler.

  Advanced MELT users willing to debug with gdb could set the
  melt_alptr_1 and melt_objhash_1 in their gdb debugger to track
  allocation or changes of MELT values or objects.

  The -fmelt-debugging=all option works as expected in the MELT branch
  and so does -fplugin-arg-melt-debugging=all in the MELT plugin.


Numerous bug fixes. The probe has been improved, and also shows some
Gimple/SSA. Consider using Alexandre Lissy's replacement (Python/Qt
based) of the probe.



##

Thanks to Alexandre Lissy, Emmanuel Haucourt, Jeremie Salvucci for their help 
and contributions.


Bug reports and feature requests are welcome on gcc-m

Re: Libgcc and its license

2012-10-10 Thread Joseph S. Myers 
On Wed, 10 Oct 2012, Gabor Loki wrote:

> 2) repeat all the compilation commands related to the previous list in
> the proper environment. The only thing which I have added to the
> compilation command is an extra "-E" option to preprocess every sources.
> 3) create a unique list of all source and header files from the
> preprocessed files.
> 4) at final all source, header and generated files are checked for their
> licenses.

The fact that a header is read by the compiler at some point in generating 
a .o file does not necessarily mean that object file is a work based on 
that header; that is a legal question depending on how the object code 
relates to that header.  Where the objects do use information from 
host-side tm.h, that information is generally factual (e.g. information 
about the sizes of types for that architecture) rather than copyrightable 
expression.  And there is probably no legal difference between getting 
such information via #include of a header shared with the host-side 
compiler, and getting it from predefined macros that the host-side 
compiler defines based on headers included when the host-side compiler is 
built.

Similarly, just because a userspace program for GNU/Linux ends up 
including headers from the Linux kernel does not make that userspace 
program GPLv2.

> I suppose all of the header files should have the GPLv3 with GCC Runtime
> Exception license, because libgcc should have GPLv3 w RE. Am I right?

The libgcc build should move towards working entirely in the toplevel 
libgcc/ directory, with configuration information coming from headers in 
libgcc/config rather than from headers shared with the host.  Please see 
 for information that 
may be out of date (it doesn't seem to reflect how various of Rainer's 
patches went in for 4.7), but includes an indicative list of relevant 
target macros and how they might be addressed.

Once the libgcc build is cleanly separated from that of the compiler, any 
residual uses of the Runtime Exception in the host-side gcc/ headers, that 
may have been put there in attempts to address conceptions such as you 
describe about licenses of headers, should be removed.

-- 
Joseph S. Myers
jos...@codesourcery.com

Fully flow and context sensitive points-to analysis in GCC 4.6.0

2012-10-10 Thread Uday P. Khedker 


We have designed and implemented a fully flow and context sensitive points-to 
analysis in gcc-4.6.0. For simplicity, we have made a dynamic plugin available 
at http://www.cse.iitb.ac.in/grc/index.php?page=l-fcpa. This page also provides 
an overview of the method, and links to the paper, slides, and instructions on 
how to use the plugin. Our method questions the conventional wisdom that 
precise flow and context sensitive pointer information is prohibitively large 
and hence we cannot hope to compute it efficiently. We show that the actual 
usable information is rather small and sparse and hence an increase in 
precision actually improves the efficiency too, rather than worsen it.

Needless to say, precise pointer information is critical for the effectiveness 
of almost all analyses and optimizations in any compiler. Now that we have some 
ray of hope of precise points-to analysis in GCC, we would like to invite 
collaboration from like minded people. There is a lot of work that needs to be 
done further; some details of future work are available on the given URL and we 
will be happy to provide more information to the interested people.

Looking forward to hearing from people who would like to contribute to this 
important project.

Thanks and regards,

Uday Khedker.
--
Dr. Uday Khedker
Professor
Department of Computer Science & Engg.
IIT Bombay, Powai, Mumbai 400 076, India.
Email   :   u...@cse.iitb.ac.in
Homepage:   http://www.cse.iitb.ac.in/~uday
Phone   :   
Office -91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct)
Res.   -91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct)




--
--
Dr. Uday Khedker
Professor
Department of Computer Science & Engg.
IIT Bombay, Powai, Mumbai 400 076, India.
Email   :   u...@cse.iitb.ac.in
Homepage:   http://www.cse.iitb.ac.in/~uday
Phone   :   
Office -91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct)
Res.   -91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct)

Broken Math Resource Link on Your Site - Follow-up

2012-10-10 Thread Alexandra Sawyer 

Hi Administrator,

I wanted to follow up with you and make sure you had received my email I sent a 
little bit ago regarding the broken link on your site.

If you are still updating your website, I have a similar resource that you can 
replace the broken link with if you are interested. Let me know!

Best regards,
Alexandra Sawyer

Re: Libgcc and its license

2012-10-10 Thread Robert Dewar 

On 10/10/2012 10:48 AM, Joseph S. Myers wrote:

On Wed, 10 Oct 2012, Gabor Loki wrote:


2) repeat all the compilation commands related to the previous list in
the proper environment. The only thing which I have added to the
compilation command is an extra "-E" option to preprocess every sources.
3) create a unique list of all source and header files from the
preprocessed files.
4) at final all source, header and generated files are checked for their
licenses.


The fact that a header is read by the compiler at some point in generating
a .o file does not necessarily mean that object file is a work based on
that header; that is a legal question depending on how the object code
relates to that header.


Well legally the status of a file is not in anyway affected by what
the header of the file says, but we should indeed try to make sure
that all headers properly reflect the intent.

Re: Broken Math Resource Link on Your Site - Follow-up

2012-10-10 Thread Jonathan Wakely 
On Oct 10, 2012 7:10 PM, "Alexandra Sawyer" wrote:
>
> Hi Administrator,
>
> I wanted to follow up with you and make sure you had received my email I sent 
> a little bit ago regarding the broken link on your site.
>
> If you are still updating your website, I have a similar resource that you 
> can replace the broken link with if you are interested. Let me know!
>
> Best regards,
> Alexandra Sawyer
>

Hi,

The link you referred to is in an archived email sent to a GCC mailing
list. The contents of mails sent to the list are not really the
responsibility of the GCC project and editing archived posts to fix
broken links is not an option.

If your alternative resource is useful then hopefully interested
parties will be able to find it via a web search anyway.

Re: Broken Math Resource Link on Your Site - Follow-up

2012-10-10 Thread Florian Weimer 
* Jonathan Wakely:

> The link you referred to is in an archived email sent to a GCC mailing
> list. The contents of mails sent to the list are not really the
> responsibility of the GCC project and editing archived posts to fix
> broken links is not an option.

Alexandra (probably not her real name) works for a search engine
spammer.  They just want us to link to them, in the hope that this
will improve their ranking.

Re: Libgcc and its license

2012-10-10 Thread Joseph S. Myers 
On Wed, 10 Oct 2012, Robert Dewar wrote:

> On 10/10/2012 10:48 AM, Joseph S. Myers wrote:
> > On Wed, 10 Oct 2012, Gabor Loki wrote:
> > 
> > > 2) repeat all the compilation commands related to the previous list in
> > > the proper environment. The only thing which I have added to the
> > > compilation command is an extra "-E" option to preprocess every sources.
> > > 3) create a unique list of all source and header files from the
> > > preprocessed files.
> > > 4) at final all source, header and generated files are checked for their
> > > licenses.
> > 
> > The fact that a header is read by the compiler at some point in generating
> > a .o file does not necessarily mean that object file is a work based on
> > that header; that is a legal question depending on how the object code
> > relates to that header.
> 
> Well legally the status of a file is not in anyway affected by what
> the header of the file says, but we should indeed try to make sure
> that all headers properly reflect the intent.

I'm not talking about the relation between the headings textually located 
in a source file and the license of that source file.  I'm talking about 
the relation between the license of a .o file and the license of .h files 
#included at several levels of indirection from the .c source that was 
compiled to that .o file (in particular, headers included within tm.h, but 
most or all of the content of which is irrelevant for code being built for 
the target).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Broken Math Resource Link on Your Site - Follow-up

2012-10-10 Thread Jonathan Wakely 
On 10 October 2012 21:03, Florian Weimer wrote:
> * Jonathan Wakely:
>
>> The link you referred to is in an archived email sent to a GCC mailing
>> list. The contents of mails sent to the list are not really the
>> responsibility of the GCC project and editing archived posts to fix
>> broken links is not an option.
>
> Alexandra (probably not her real name) works for a search engine
> spammer.  They just want us to link to them, in the hope that this
> will improve their ranking.

Yes, I figured as much, but at least by replying to say "it aint gonna
happen" she might stop trying.  The follow up mail after the first was
ignored shows a little more effort than most link-farmers bother with,
so maybe there's enough intelligence at the other end to take "no" for
an answer.

Re: Libgcc and its license

2012-10-10 Thread Robert Dewar 

On 10/10/2012 4:16 PM, Joseph S. Myers wrote:


I'm not talking about the relation between the headings textually located
in a source file and the license of that source file.  I'm talking about
the relation between the license of a .o file and the license of .h files
#included at several levels of indirection from the .c source that was
compiled to that .o file (in particular, headers included within tm.h, but
most or all of the content of which is irrelevant for code being built for
the target).


Right, I understand, but that gets messy quickly!

Re: Libgcc and its license

2012-10-10 Thread Georg-Johann Lay 

Joseph S. Myers a écrit:

On Wed, 10 Oct 2012, Robert Dewar wrote:

On 10/10/2012 10:48 AM, Joseph S. Myers wrote:

On Wed, 10 Oct 2012, Gabor Loki wrote:


2) repeat all the compilation commands related to the previous list in
the proper environment. The only thing which I have added to the
compilation command is an extra "-E" option to preprocess every sources.
3) create a unique list of all source and header files from the
preprocessed files.
4) at final all source, header and generated files are checked for their
licenses.

The fact that a header is read by the compiler at some point in generating
a .o file does not necessarily mean that object file is a work based on
that header; that is a legal question depending on how the object code
relates to that header.


At least this is the concept of the FSF:

Making a source file a derivative work of the header needs the header to

   "take a substantial amount of code (coming from inline functions or
   macros with substantial bodies) to do that."  (rms)

http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html

This is a quote from an answer to a related question, namely if
including a GPL header turns the module into a derivative work, i.e.
if the module source must be released under the GPL.

I'd say the situation with the runtime library exception is similar.
However, nothing specific can be found on that topic.

From the above quote I depict that the FSF is cool with such includes,
but lawyers from companies that compiler their closed source with GCC 
and link against libgcc are always concerned about that one line of

code might infect their whole software with the GPL and they have to
publish all their code under the GPL.

The idea of the GPL + RLE is clearly not to introduce such restrictions
or "infection".

Johann


Well legally the status of a file is not in anyway affected by what
the header of the file says, but we should indeed try to make sure
that all headers properly reflect the intent.


I'm not talking about the relation between the headings textually located 
in a source file and the license of that source file.  I'm talking about 
the relation between the license of a .o file and the license of .h files 
#included at several levels of indirection from the .c source that was 
compiled to that .o file (in particular, headers included within tm.h, but 
most or all of the content of which is irrelevant for code being built for 
the target).

Коллекционные монeты

2012-10-10 Thread Магазин старинных Mонет 
Сайт: http://www.emmanuelbc.net/templates/ber.php
E-mail: inku...@gmail.com
Тел.:  7-911-924-47-78

Normalizing the bitmap APIs.

2012-10-10 Thread Lawrence Crowl 
As part of our effort to make programming in GCC easier, we would like
to improve the interface to bitmaps.

There are three bitmap types, each with disparate operations and
function names.  This disparity causes problems
* when changing a variable from one type to another,
* when moving one's attention from one type to another.
We would like to change the existing function names to be more uniform.

The most complicated operations
are those that produce a bitwise result
for one or more binary bitwise operations.
These do work as if written with one of the following forms:

  d = a OP b
  d = a OP b with reporting of a change to d
  a OP= b
  a OP= b with reporting of a change to a

  d = a OP (b OP c)
  d = a OP (b OP c) with reporting of a change to d
  a OP= (b OP c)
  a OP= (b OP c) with reporting of a change to a

where OP is one of

  OP  TAG  operation description
   &  and  intersection
   |  ior  union
   ^  xor  inequivalence
   -  dif  set difference (reverse relative complement) (a&~b)
   /  rdf  reverse set difference (relative complement) (~a&b)

One approach is to add operators for the bitmap operations.
Unfortunately, the straightforward way to do that would introduce
temporary variables where none exist now, which would result in a net
loss of performance.  For example,
  bitmap_a_and_b (dest, a, b);
written as
  dest = a & b;
would result in code that is effectively
  tmp = a & b;
  dest = tmp;
and would require allocation and copying of tmp.

We can avoid this run-time expense by using expression templates
http://en.wikipedia.org/wiki/Expression_templates.  However, that
change would require substantial implementation work and substantial
compile-time effort to untangle the templates.

Also, unfortunately, with C++2003 as the implementation language and
the existing use of unions in critical data structures like trees,
the overloading of assignment operators would either be prohibited or
require a significantly clumsier syntax than one would like.

Instead, I propose a more modest change, preserving the existing call
syntax, but normalizing it so that function names are predictable and
general.  By overloading these operations on the type of the bitmap,
we can use a single name for a single action, regardless of type.
Doing so eases the task of changing types, as may be desiriable to
obtain a different performance profile.

For the operations above, I suggest names as follows:

  assign_TAG (d = a OP b)
  assign_TAG_changed
  TAG_assign (a OP= b)
  TAG_assign_changed

  assign_TAG_TAG (d = a OP (b OP c))
  assign_TAG_TAG_changed
  TAG_assign_TAG (a OP= (b OP c))
  TAG_assign_TAG_changed

For example, sbitmap_a_or_b_cg (d, a, b)
becomes assign_ior_changed (d, a, b);
and bitmap_ior_and_compl_into (a, b, c)
becomes ior_assign_dif (a, b, c).

It is not surprising that some expressions using change-returning
functions do not use the function result.  However, it appears that
some such functions never have their result used.  I would propose
using void versions everwhere that the result is not used.  These can
be implemented with the non-void versions easily enough.

Testing for a change also applies to the single bit clear and set
routines for bitmap, but not ebitmap or sbitmap.  It would probably
be prudent to make names for both variants, and implement the testing
version only when needed.  The non-testing version can be implemented
via the testing version in the short term.

Other operations are simpler in structure, but still need common
names.  I propose the following:

  clear (bitmap) -> void
  clear_range (bitmap, unsigned, unsigned) -> void
  assign_not (bitmap, const_bitmap) -> void
  has_intersection (const_bitmap, const_bitmap) -> bool
  is_subset_of (const_bitmap, const_bitmap) -> bool
  cardinality (const_bitmap) -> unsigned
  cardinality_of_range (const_bitmap, unsigned, unsigned) -> unsigned
  is_empty (const_bitmap) -> bool
  is_singleton (const_bitmap) -> bool
  first_set_bit (const_bitmap) -> unsigned
  last_set_bit (const_bitmap) -> unsigned
  test_bit (const_bitmap, unsigned) -> bool

I propose to leave the allocation, iteration, vector, debug/dump/print
and functions alone for the time being.

Comments?

-- 
Lawrence Crowl

Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0

2012-10-10 Thread David Edelsohn 
On Wed, Oct 10, 2012 at 1:56 PM, Uday P. Khedker  wrote:
>
> We have designed and implemented a fully flow and context sensitive
> points-to analysis in gcc-4.6.0. For simplicity, we have made a dynamic
> plugin available at http://www.cse.iitb.ac.in/grc/index.php?page=l-fcpa.
> This page also provides an overview of the method, and links to the paper,
> slides, and instructions on how to use the plugin. Our method questions the
> conventional wisdom that precise flow and context sensitive pointer
> information is prohibitively large and hence we cannot hope to compute it
> efficiently. We show that the actual usable information is rather small and
> sparse and hence an increase in precision actually improves the efficiency
> too, rather than worsen it.
>
> Needless to say, precise pointer information is critical for the
> effectiveness of almost all analyses and optimizations in any compiler. Now
> that we have some ray of hope of precise points-to analysis in GCC, we would
> like to invite collaboration from like minded people. There is a lot of work
> that needs to be done further; some details of future work are available on
> the given URL and we will be happy to provide more information to the
> interested people.

Uday,

This is great progress.

If I understand the experiments, your implementtion has very small
cost to perform the analysis, at least for the SPEC benchmarks you are
testing.  Have you connected the analysis to any optimizations?  Is
there any improvement in performance on SPEC CPU or other
applications?

You ask for collaboration, but it's not clear what state the
infrastructure is in, how complete it is, and what more needs to be
done.

Thanks, David

Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0

2012-10-10 Thread Uday P. Khedker 

Hi David,


This is great progress.


Thanks.
 

If I understand the experiments, your implementtion has very small
cost to perform the analysis, at least for the SPEC benchmarks you are
testing.  Have you connected the analysis to any optimizations?  Is
there any improvement in performance on SPEC CPU or other
applications?


Unfortunately we could not do this as it requires changing the way the pointer 
information
is made available to other passes. Right now, it is encoded in the TREE nodes of
variables which make is same at all program points. In other words, GCC, by 
definition
assumes flow insensitive information. Supporting flow sensitivity implies being 
able
to provide different information for the same pointer at different program 
points.

We are investigating how this can be done and this is one of the most important 
future
works on which we seek collaboration. Unless we are able to do this, we will 
not be able
to take advantage of the analysis.



You ask for collaboration, but it's not clear what state the
infrastructure is in, how complete it is, and what more needs to be
done.


The infrastructure is in a reasonably complete state except that
 
(a) It is not directly useful to other analyses and optimizations for the

reasons described above.
(b) It uses rather naive and inefficient data structures in which sets are
stored as linked lists and set operations are implemented using linear
searches.
(c) Some corner cases related identifying pointers need to be fixed.
(d) It handles heap locations rather conservatively.

We seek collaborations on (a) and (b). We have designed APIs to hide the data 
structures
and now these are good student projects. Some details can be found at
http://www.cse.iitb.ac.in/grc/gcc-workshop-12/index.php?page=projects#Projects_with_Concrete_and_Detailed.

We are carrying out research on (d) and have some ideas on what needs to be 
done but it will
be some time before the infrastructure is enhanced to include it. We are 
committed to doing it.

Thanks and regards,

Uday.

Re: thumb2 support

2012-10-10 Thread Grant 
>> Hello, I'm working with the BeagleBone and gcc-4.5.4 on Gentoo.  If I
>> try to compile the 3.6 kernel with CONFIG_THUMB2_KERNEL, I get:
>>
>> arch/arm/boot/compressed/head.S:127: Error: selected processor does
>> not support requested special purpose register -- `mrs r2,cpsr'
>> arch/arm/boot/compressed/head.S:134: Error: selected processor does
>> not support requested special purpose register -- `mrs r2,cpsr'
>> arch/arm/boot/compressed/head.S:136: Error: selected processor does
>> not support requested special purpose register -- `msr cpsr_c,r2'
>>
>> This post indicates that mainline gcc does not currently support thumb2:
>>
>> https://groups.google.com/d/msg/beagleboard/P52fgMDzp8A/vupzuh71vdYJ
>>
>> However, this indicates that thumb2 has been supported since 4.3:
>>
>> http://gcc.gnu.org/gcc-4.3/changes.html
>>
>> Can anyone clear this up?
>
> The errors are coming from an assembler file that is not part of the
> GCC sources.  Are those instructions valid for Thumb2?  I don't know.
> If they are valid, then the issue is with the assembler, which is not
> part of GCC; check the version of the GNU binutils that you have
> installed.  If those instructions are not valid, then you need to
> change your source.

Thanks Ian.  I'm using binutils-2.22-r1.  Do you happen to know which
version of binutils should support thumb2?

- Grant

Re: thumb2 support

2012-10-10 Thread Ian Lance Taylor 
On Wed, Oct 10, 2012 at 9:58 PM, Grant  wrote:
>>> Hello, I'm working with the BeagleBone and gcc-4.5.4 on Gentoo.  If I
>>> try to compile the 3.6 kernel with CONFIG_THUMB2_KERNEL, I get:
>>>
>>> arch/arm/boot/compressed/head.S:127: Error: selected processor does
>>> not support requested special purpose register -- `mrs r2,cpsr'
>>> arch/arm/boot/compressed/head.S:134: Error: selected processor does
>>> not support requested special purpose register -- `mrs r2,cpsr'
>>> arch/arm/boot/compressed/head.S:136: Error: selected processor does
>>> not support requested special purpose register -- `msr cpsr_c,r2'
>>>
>>> This post indicates that mainline gcc does not currently support thumb2:
>>>
>>> https://groups.google.com/d/msg/beagleboard/P52fgMDzp8A/vupzuh71vdYJ
>>>
>>> However, this indicates that thumb2 has been supported since 4.3:
>>>
>>> http://gcc.gnu.org/gcc-4.3/changes.html
>>>
>>> Can anyone clear this up?
>>
>> The errors are coming from an assembler file that is not part of the
>> GCC sources.  Are those instructions valid for Thumb2?  I don't know.
>> If they are valid, then the issue is with the assembler, which is not
>> part of GCC; check the version of the GNU binutils that you have
>> installed.  If those instructions are not valid, then you need to
>> change your source.
>
> Thanks Ian.  I'm using binutils-2.22-r1.  Do you happen to know which
> version of binutils should support thumb2?

That version should support thumb2.

If those instructions are valid for thumb2, make sure the assembler is
being invoked with the appropriate options.  The error message says
"selected processor does not support" implying that you need to select
a different processor, probably via the assembler's -march option.

Ian

Maintenance shutdown of ftp.tsukuba.wide.ad.jp

2012-10-10 Thread Kohei Takahashi 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

ftp.tsukuba.wide.ad.jp will maintenance shutdown due to electrical
equipment inspection from October 27, 2012 00:00 JST (UTC+0900) to
October 29, 2012 00:00 JST (UTC+0900).

Thank you for your understanding.

- -- 
Kohei Takahashi
WIDE Project Tsukuba NOC
fl...@tsukuba.wide.ad.jp
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJQdlh2AAoJEIFgvc+dw1m2xAwP+gI4HwynU6+aV/uWPFlXynkV
7uVWfzSL4405icssriA482QvF4Dk0PnYfKkLx9bosnk3evnvUqWAiHs8S+DZSE1M
EuUELE3KIpXunllcK8LYAwQx/gdQeYPgRqyz3W8aKDa5w2JWZgi9Def3nG9fDO/z
VKU7B9QkQO4RSo6yfmiHhJq5P5VcUeq17EKo4mToGE7gCXLO3jafKQ6k6GFLDrqI
sTQGiabKWebfJKiKsRjI886k9d5mBVZsfj4nDELaxKT9cUxP6H4YMXXKdIQ2FZ1F
kuaC2h/g/GiU6l3/jdzmRLOH1LJ1bz4ZZYPYbwtL4b1kRRipVBCjGPM28ielZ8sQ
NfO/csWwZrXk10HzXSy7FLGxb+FEMj0lSPot7LDGO0KaA1s7a4+jugn7O7/ayY9n
uOSWHpzEEbq/YqzWEWT8xvVRFfnmsN1DMn2rabVTAEBJrXbQZs1yv9JzLOLlfe0q
3AKekFX/E1b26ACFmkvW5kDLcvVHthlmg5Hw2U2obE5re0//+MXYABeXpp/hbAMo
bsRJIrcDPz8SUoFWXgK01grU7oBXgdlzNxiheqDepw+t0uwwDqXAoEFZnG8/ZSgA
DXkv07Twf0M/fapDH2l3yI73dmwjLGPOa1toervxZzK6DIBfDpSC0mzO1F+5i/Zk
48lBEoQHcNHkrkO4M8wV
=O7qY
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature