headers
Jacky Lau | 1 Apr 2012 07:05
Picon

[proposal] make gcc5 become the base of GNU operating system

There are two trends in the computer industry:
1) there are a variety of CPU architectures exist in any one area. For
example, in the server area, there are power, sparc, mips, x86, and
even arm, in the mobile internet device area, there are arm, x86, and
even mips.
2) new programming language is emerging, and some became popular. For
example, scala, google go, as well as a variety of domain-specific
language (DSL).

So I think that the next-generation operating system architecture will
be a micro-kernel that contains a language virtual machine, plus a
variety of system components which was writen by different languages.
Components outside the kernel in form of bytecode and executed by the
in-kernel JIT VM. In this type of operating system, developers can
select the most suitable language to develop the various components.
Developer can even develop a new general-purpose programming language
or domain-specific language if he can't find a suitable language. For
example, a device driver language for writing device driver.

In this architecture, compiler technology has become the
infrastructure. This is what gcc good at. Therefore, we should
consider make gcc5 become the base of the real Gnu-isNot-Unix
operating system. First we should define the VM and bytecode and then
write the the JIT VM, followed by make the core of gcc as libraries,
and provides them to compiler. IMHO, the micro-kernel is not
necessarily l4, the operating system interface may not be posix,
driver can be writen by using a DSL.

This operating system sounds like Inferno, or Jxos/JNode, or
Singularity/Midori. Indeed, I think that this operating system can
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maxim Kuvyrkov | 1 Apr 2012 21:57

Re: [GCC Steering Committee] Android sub-port reviewer

On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote:

> I volunteer as the reviewer for Android sub-port.
> 
> Android/Bionic support is an extension over Linux port and is being gradually added for more and more
architectures.  I wrote the original Android GCC support for ARM (under a watchful design eye of Joseph
Myers), and know how the bits fit together.
> 
> As adding Android support to a new architecture requires changes to that architecture, the architecture
maintainer will have the power of veto for the Android-related changes.

One of the members of SC raised a good point about whether architecture maintainers would prefer to handle
the Android patches themselves.  My intention is to spare you the additional headache of dealing with
Android, but, well, maybe you like it :-).

Richard E.,
Jan,
Richard S.,

Do you want to handle Android changes by yourself or do you want to delegate?

Thank you,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
Permalink | Reply | 14 comments |
headers
Diego Novillo | 1 Apr 2012 22:41
Picon
Favicon

Re: Plugins always enabled in GCC 4.8?

On 3/31/12 1:51 PM, Basile Starynkevitch wrote:

> If we want to aim towards a more modular GCC made of several shared libraries, it seems
> that we are requiring the host system to have dynamic libraries (which is not a big deal
> today; all the major OSes running on developers desktop or laptop have them).

I don't follow.  Modularity does not require shared libraries.

> In that case, I think that we should always --enable-plugin at configure time, hence
> making that configure switch useless (since always on).

Plugins are auto-detected on systems that support it and always enabled.

> Likewise, I also hope that next GCC will be only C++ compilable (and that we remove the
> ability to compile it with C)

This will only happen if someone does the work.  Hope produces no patches.

> More generally, I would like a description, or a list of host systems for GCC. What kind
> of system services [e.g. dlopen, time, ...] to we require GCC to access to?

The plugin support detection already asks these questions to the host 
system.

Diego.
Permalink | Reply | 7 comments |
headers
gccadmin | 2 Apr 2012 00:43
Picon
Favicon

gcc-4.8-20120401 is now available

Snapshot gcc-4.8-20120401 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120401/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 186057

You'll find:

 gcc-4.8-20120401.tar.bz2             Complete GCC

  MD5=18c32b5773a538f4ba36c330ee83c242
  SHA1=ed9a05207fb77bee0478117578ed64d34d35bc57

Diffs from 4.8-20120325 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.8
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.
Permalink | Reply | 0 comments |
headers
Basile Starynkevitch | 2 Apr 2012 07:37

Re: Plugins always enabled in GCC 4.8?

On Sun, 01 Apr 2012 16:41:09 -0400
Diego Novillo <dnovillo <at> google.com> wrote:

> On 3/31/12 1:51 PM, Basile Starynkevitch wrote:
> 
> > If we want to aim towards a more modular GCC made of several shared libraries, it seems
> > that we are requiring the host system to have dynamic libraries (which is not a big deal
> > today; all the major OSes running on developers desktop or laptop have them).
> 
> I don't follow.  Modularity does not require shared libraries.

Indeed, but when GCC is made of several shared libraries, it would be modular, since each
such shared library would be defined by a module.

(I mean that modules are a design thing existing at the source level, and each shared
library would implement one module; look into GTK/Gnome to feel what I mean: Pango,
Glib, Gio, Atk, .... are modules there and have libpango.so, libglib.so, libgio.so,
libatk.so ... at runtime..).

> 
> > In that case, I think that we should always --enable-plugin at configure time, hence
> > making that configure switch useless (since always on).
> 
> Plugins are auto-detected on systems that support it and always enabled.

I've heard that some Linux distributions (perhaps some version of RedHat?) explicitly
configure with --disable-plugin

> 
> > More generally, I would like a description, or a list of host systems for GCC. What kind
(Continue reading)

Permalink | Reply | 6 comments |
headers
Richard Guenther | 2 Apr 2012 10:36
Picon

Re: Why can't copy renaming capture this assignment?

On Sat, Mar 31, 2012 at 6:23 AM, Jiangning Liu <jiangning.liu <at> arm.com> wrote:
> Hi,
>
> For this small case,
>
> char garr[100];
> void f(void)
> {
>        unsigned short h, s;
>
>        s = 20;
>
>        for (h = 1; h < (s-1); h++)
>        {
>                garr[h] = 0;
>        }
> }
>
> After copyrename3, we have the following dump,
>
> f ()
> {
>  short unsigned int h;
>  int D.4066;
>
> <bb 2>:
>  D.4066_14 = 1;
>  if (D.4066_14 <= 18)
>    goto <bb 3>;
>  else
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Guenther | 2 Apr 2012 10:44
Picon

Re: Plugins always enabled in GCC 4.8?

On Mon, Apr 2, 2012 at 7:37 AM, Basile Starynkevitch
<basile <at> starynkevitch.net> wrote:
> On Sun, 01 Apr 2012 16:41:09 -0400
> Diego Novillo <dnovillo <at> google.com> wrote:
>
>> On 3/31/12 1:51 PM, Basile Starynkevitch wrote:
>>
>> > If we want to aim towards a more modular GCC made of several shared libraries, it seems
>> > that we are requiring the host system to have dynamic libraries (which is not a big deal
>> > today; all the major OSes running on developers desktop or laptop have them).
>>
>> I don't follow.  Modularity does not require shared libraries.
>
>
> Indeed, but when GCC is made of several shared libraries, it would be modular, since each
> such shared library would be defined by a module.
>
> (I mean that modules are a design thing existing at the source level, and each shared
> library would implement one module; look into GTK/Gnome to feel what I mean: Pango,
> Glib, Gio, Atk, .... are modules there and have libpango.so, libglib.so, libgio.so,
> libatk.so ... at runtime..).
>
>>
>> > In that case, I think that we should always --enable-plugin at configure time, hence
>> > making that configure switch useless (since always on).
>>
>> Plugins are auto-detected on systems that support it and always enabled.
>
> I've heard that some Linux distributions (perhaps some version of RedHat?) explicitly
> configure with --disable-plugin
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Haley | 2 Apr 2012 10:58
Picon
Favicon

Re: GCC 4.7.0 as a AVR cross compiler

On 03/30/2012 05:46 PM, stuart wrote:
> I can not seem to get gcc 4.7.0 to compile; it will not complete the
> configuration stage complaining about missing packages (GMP, MPFR and
> MPC). 

Go into the top-level source directory in the unpacked gcc sources
and run this script:

./contrib/download_prerequisites

Andrew.
Permalink | Reply | 0 comments |
headers
Basile Starynkevitch | 2 Apr 2012 11:33

Re: Plugins always enabled in GCC 4.8?

On Mon, Apr 02, 2012 at 10:44:41AM +0200, Richard Guenther wrote:
> On Mon, Apr 2, 2012 at 7:37 AM, Basile Starynkevitch
> <basile <at> starynkevitch.net> wrote:
> > On Sun, 01 Apr 2012 16:41:09 -0400
> > Diego Novillo <dnovillo <at> google.com> wrote:
> >
> >> On 3/31/12 1:51 PM, Basile Starynkevitch wrote:

> > I've heard that some Linux distributions (perhaps some version of RedHat?) explicitly
> > configure with --disable-plugin
> 
> SUSE does.  And until we get a real plugin API we will continue to do so.

I suppose that internally at SUSE you have a well defined criteria of what a
real plugin API should be.

Unfortunately, I (Basile) have no precise idea of what such a criteria
should be.

(it probably could be related to what I believe "being modular" means, but
AFAIU "being modular" have different meanings to different persons on this
gcc <at>  list, and there is no consensus here).

As a plugin developer, I call "plugin API" whatever is "available" as
callable from plugins, so for me the plugin API is just the set of headers
under $(gcc -print-file-name=plugin/include), which I agree is not very sexy
today, but is the only things plugin developers can have today.

So it seems that "real plugin API" has no consensual definition yet.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Hubicka | 2 Apr 2012 11:50
Picon

Re: [GCC Steering Committee] Android sub-port reviewer

> On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote:
> 
> > I volunteer as the reviewer for Android sub-port.
> > 
> > Android/Bionic support is an extension over Linux port and is being gradually added for more and more
architectures.  I wrote the original Android GCC support for ARM (under a watchful design eye of Joseph
Myers), and know how the bits fit together.
> > 
> > As adding Android support to a new architecture requires changes to that architecture, the
architecture maintainer will have the power of veto for the Android-related changes.
> 
> One of the members of SC raised a good point about whether architecture maintainers would prefer to handle
the Android patches themselves.  My intention is to spare you the additional headache of dealing with
Android, but, well, maybe you like it :-).
> 
> Richard E.,
> Jan,
> Richard S.,
> 
> Do you want to handle Android changes by yourself or do you want to delegate?

I am happy with the idea of having Android manintainer.  The configure bits are
kind of independent of the actual architecture support anyway.

Honza
> 
> Thank you,
> 
> --
> Maxim Kuvyrkov
(Continue reading)

Permalink | Reply | 0 comments |

Gmane