On Sat, Mar 31, 2012 at 6:23 AM, Jiangning Liu 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
On Mon, Apr 2, 2012 at 7:37 AM, Basile Starynkevitch
wrote:
> On Sun, 01 Apr 2012 16:41:09 -0400
> Diego Novillo 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 requi
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_
On Mon, Apr 02, 2012 at 10:44:41AM +0200, Richard Guenther wrote:
> On Mon, Apr 2, 2012 at 7:37 AM, Basile Starynkevitch
> wrote:
> > On Sun, 01 Apr 2012 16:41:09 -0400
> > Diego Novillo wrote:
> >
> >> On 3/31/12 1:51 PM, Basile Starynkevitch wrote:
> > I've heard that some Linux distributions
> 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 (unde
Hello All,
It is my pleasure to announce the MELT plugin 0.9.5 release candidate 2 for GCC
4.6 or 4.7.
NEWS for 0.9.5rc2 MELT plugin for GCC 4.6 & 4.7
[[April 2nd 2012]] release candidate 2
Alternative infix syntax is abandoned
On Mon, Apr 02, 2012 at 12:30:51PM +0200, Basile Starynkevitch wrote:
> Hello All,
>
> It is my pleasure to announce the MELT plugin 0.9.5 release candidate 2 for
> GCC 4.6 or 4.7.
MELT is a high-level domain specific language to extend GCC
> ###
On Mon, Apr 2, 2012 at 12:37 AM, Basile Starynkevitch
wrote:
> On Sun, 01 Apr 2012 16:41:09 -0400
> Diego Novillo 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 requ
On Mon, Apr 02, 2012 at 05:40:37AM -0500, Gabriel Dos Reis wrote:
> On Mon, Apr 2, 2012 at 12:37 AM, Basile Starynkevitch
> wrote:
> > On Sun, 01 Apr 2012 16:41:09 -0400
> > Diego Novillo wrote:
> >
> >> On 3/31/12 1:51 PM, Basile Starynkevitch wrote:
> >>
> >> > If we want to aim towards a more
On Mon, Apr 2, 2012 at 6:17 AM, Basile Starynkevitch
wrote:
>> You appear to be moving in directions that may give pause to
>> those who championed better separation of concerns in GCC.
>
>
> I am not sure to understand that last sentence (I had to read it 4 times,
> with different ways of unders
On Mon, Apr 2, 2012 at 2:38 PM, Gabriel Dos Reis
wrote:
> On Mon, Apr 2, 2012 at 6:17 AM, Basile Starynkevitch
> wrote:
>
>>> You appear to be moving in directions that may give pause to
>>> those who championed better separation of concerns in GCC.
>>
>>
>> I am not sure to understand that last
Quoting Basile Starynkevitch :
I also am in favor of having a software linked dynamically with shared
libraries, for a very pragramtical reason: If a software has shared
libraries, then modifying one such library in its implementation (not its
interface) is very often easier for the developer, w
Hello,
The GRAPHITE-OpenCL work published a couple of years ago looks
interesting [0].
What’s the status of the code? Is it accessible on-line?
Thanks in advance,
Ludo’.
[0]
http://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=belevantsev.pdf
Hi,
On Fri, 30 Mar 2012, Jan Hubicka wrote:
> > Motion across hardreg sets/uses are not restricted. And I would not expect
> > an optimizing compiler to do that (it's your own fault to use hardregs in
> > complex C code).
>
> Well, the syscall sequence is an example of somehting that should be
On Mon, Apr 02, 2012 at 04:07:59PM +0200, Michael Matz wrote:
> On Fri, 30 Mar 2012, Jan Hubicka wrote:
>
> > > Motion across hardreg sets/uses are not restricted. And I would not
> > > expect
> > > an optimizing compiler to do that (it's your own fault to use hardregs in
> > > complex C code).
> "Stefano" == Stefano Lattarini writes:
Stefano> Note there's nothing I'm planning to do, nor I should do, in
Stefano> this regard: the two setups described above are both already
Stefano> supported by the current automake implementation (but the last
Stefano> one is not encouraged, even tho
Hello,
On Mon, 2 Apr 2012, Ludovic Courtès wrote:
> Hello,
>
> The GRAPHITE-OpenCL work published a couple of years ago looks
> interesting [0].
>
> What’s the status of the code? Is it accessible on-line?
The code has been merged into graphite branch; it can be obtained via:
svn co svn://gc
On 04/02/2012 04:25 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini writes:
>
> Stefano> Note there's nothing I'm planning to do, nor I should do, in
> Stefano> this regard: the two setups described above are both already
> Stefano> supported by the current automake implementation (bu
Hi,
On Fri, 30 Mar 2012, Gabriel Dos Reis wrote:
> On Fri, Mar 30, 2012 at 7:45 PM, David Malcolm wrote:
>
> > Here's another proposal then: actually use GObject introspection -
> > provide a GObject-based API to GCC.
> >
> > In this approach, GCC would gain a dependency on glib and gobject, an
> "Stefano" == Stefano Lattarini writes:
Stefano> True, and that was even stated in the manual; the whole point
Stefano> of ditching support for cygnus trees is that by now those two
Stefano> big users are basically not making any real use of the 'cygnus'
Stefano> option anymore. To quote my
On 04/02/2012 05:16 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini writes:
>
> Stefano> True, and that was even stated in the manual; the whole point
> Stefano> of ditching support for cygnus trees is that by now those two
> Stefano> big users are basically not making any real use of
Hi,
On Mon, 2 Apr 2012, Jakub Jelinek wrote:
> > inline int syscall1(int number, long arg1) {
> > register int ax __asm__("eax");
> > register long di __asm__("rdi");
> > ax = number;
> > di = arg1;
> > __asm__ volatile ("syscall");
> > }
> >
> > _then_ we would probably get miscompila
On 01/04/12 20:57, Maxim Kuvyrkov wrote:
> 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
>
I wrote a script and ported my proposed API for GCC plugins from my
CamelCase naming convention to an underscore_based_convention (and
manually fixed up things in a few places also).
The result compiles and passes the full test suite for the Python
plugin; that said, I'm still breaking the encapsu
Hello everyone,
Not sure if this is the right place to ask this question, feel free to point me
in the right direction.
I'm looking into the evolution of Linux kernel and this requires me to build
some ancient releases (as old as 2.4.0) from source using GCC. I have gcc
4.4.3-4ubuntu5 installed
Maxim Kuvyrkov writes:
> 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 sup
> "Stefano" == Stefano Lattarini writes:
Stefano> Sorry if I sound dense, but what exactly is the feature you are
Stefano> talking about here?
I was under the impression that it would no longer be possible to build
info files in the build tree. But, I see that, according to the
Automake man
On 04/02/2012 09:36 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini writes:
>
> Stefano> Sorry if I sound dense, but what exactly is the feature you are
> Stefano> talking about here?
>
> I was under the impression that it would no longer be possible to build
> info files in the buil
Bump!
Let me renew my interest in contributing through GSoC with post-compilation
feedback (This was not an early april joke). Do you think it could lead to an
acceptable GSoC proposal? (mentor interested?)
@Tomasz:
On the interaction side I totally agree that communication between compiler and
p
> "Stefano" == Stefano Lattarini writes:
Stefano> It should still be possible, with the right hack (which is
Stefano> tested in the testsuite, and required by other packages
Stefano> anyway). The baseline is: if you don't want your '.info' files
Stefano> to be distributed, then it should be
On 04/02/2012 10:19 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini writes:
>
> Stefano> It should still be possible, with the right hack (which is
> Stefano> tested in the testsuite, and required by other packages
> Stefano> anyway). The baseline is: if you don't want your '.info' f
Richard Sandiford wrote:
> Sent: Monday, April 02, 2012 11:45 AM
> To: Maxim Kuvyrkov
> Cc: Richard Earnshaw; Jan Hubicka; gcc@gcc.gnu.org
> Subject: Re: [GCC Steering Committee] Android sub-port reviewer
>
> Maxim Kuvyrkov writes:
> > On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote:
> >
> >> I v
Stefano Lattarini writes:
>> Anyway the real use in the src tree is different, IIUC.
>> Info files are built in the build tree by developers, but put in the
>> source tree for distribution.
>>
> In such a setup, what is the issue with having the '.info' files built
> in the srcdir? It's not like
On Mon, Apr 2, 2012 at 1:55 PM, Fu, Chao-Ying wrote:
> It basically sets the MIPS target to little-endian MIPS32 for
> mips-linux-android.
That seems broken because mips-*-* is big-endian and mipsel-*-* is
little-endian. Is any way of fixing that before even trying to
submitting the patch? Be
34 matches
Mail list logo
