On Tue, 03 Apr 2012 13:51:56 -0700
Ian Lance Taylor wrote:
> Paweł Sikora writes:
>
> > On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
> >>
> >> Concurrently with this, Lawrence and Ian are working on the C++ coding
> >> guidelines. The draft is stored at http://gcc.gnu.org/wiki/C
Ian Lance Taylor writes:
>> What is the earliest release of G++ that will allow GCC to bootstrap?
>
> Another thing that is worth testing. Right now I would anticipate that
> even fairly old releases of G++ can bootstrap GCC. However, we will
> need to decide what old release we want to ensure w
David Edelsohn writes:
> Do you expect GCC to be able to bootstrap starting from a vendor C++
> compiler or will this require G++?
In principle it should be possible to start from a vendor C++ compiler.
Of course we will have to test in order to see.
> What is the earliest release of G++ that w
On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo wrote:
>
> We would like to start the process to make GCC 4.8 build in C++ mode by
> default.
>
> The mechanics of the change are simple enough. I volunteer to test changing
> the default on all primary targets (assuming I can get them from the GCC
>
Pedro Alves writes:
>> OK, you've all made clear you have your sensible reasons to have the '.info'
>
> ...
>> it available only though the new, undocumented option named (literally)
>> "hack!info-in-builddir". I hope this is acceptable to you.
> ...
>> *undocumented* option '!hack!info-in-buildd
Hi,
We are organizing a micro-conference on scaling both upwards (many
cores) and downwards (low footprint, energy efficiency) that targets
all layers of the software stack. Our intent is to bring together
application, libraries and kernel developers to discuss the scalability
issues they currentl
On 04/03/2012 09:04 PM, Stefano Lattarini wrote:
> OK, you've all made clear you have your sensible reasons to have the '.info'
...
> it available only though the new, undocumented option named (literally)
> "hack!info-in-builddir". I hope this is acceptable to you.
...
> *undocumented* option '
On Tuesday 03 of April 2012 13:51:56 Ian Lance Taylor wrote:
> Paweł Sikora writes:
>
> > On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
> >>
> >> Concurrently with this, Lawrence and Ian are working on the C++ coding
> >> guidelines. The draft is stored at http://gcc.gnu.org/wiki/C
Stefano Lattarini writes:
> But since I'm not yet ready to publish this new feature, I intend to make
> it available only though the new, undocumented option named (literally)
> "hack!info-in-builddir". I hope this is acceptable to you.
Sure, works for me.
Thanks.
Ian
Paweł Sikora writes:
> On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
>>
>> Concurrently with this, Lawrence and Ian are working on the C++ coding
>> guidelines. The draft is stored at http://gcc.gnu.org/wiki/CppConventions.
>
> what about using http://astyle.sourceforge.net/astyle.
> "Stefano" == Stefano Lattarini writes:
Stefano> On a second though, by double-checking the existing code, I
Stefano> couldn't see how the 'cygnus' option could possibly influence
Stefano> the location of the generated info files -- and it turned out
Stefano> it didn't! Despite what was doc
On 04/03/2012 10:05 PM, Stefano Lattarini wrote:
> On 04/03/2012 10:04 PM, Stefano Lattarini wrote:
>> OK, you've all made clear you have your sensible reasons to have the '.info'
>> files generated in the builddir in your use cases. Since the actual change
>> required by automake to allow this is
On 04/03/2012 10:04 PM, Stefano Lattarini wrote:
> OK, you've all made clear you have your sensible reasons to have the '.info'
> files generated in the builddir in your use cases. Since the actual change
> required by automake to allow this is very small and safe, I'm ready to do
> it (see attach
OK, you've all made clear you have your sensible reasons to have the '.info'
files generated in the builddir in your use cases. Since the actual change
required by automake to allow this is very small and safe, I'm ready to do
it (see attached patch, which I will push in a couple of days to 'maste
On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
>
> Concurrently with this, Lawrence and Ian are working on the C++ coding
> guidelines. The draft is stored at http://gcc.gnu.org/wiki/CppConventions.
what about using http://astyle.sourceforge.net/astyle.html for code checkers?
what ab
On 4/04/2012, at 6:28 AM, Fu, Chao-Ying wrote:
> Andrew Pinski wrote:
>> The point is mips*-*-* is big endian and mipsel*-*-* is little endian.
>> And doing adding a target which says mips-linux-android which is
>> little-endian is just backwards. Is there anyway to fix the target
>> triplet to b
Andrew Pinski wrote:
> The point is mips*-*-* is big endian and mipsel*-*-* is little endian.
> And doing adding a target which says mips-linux-android which is
> little-endian is just backwards. Is there anyway to fix the target
> triplet to be mipsel-linux-android including inside the official
Le 3 avr. 2012 à 18:02, David Malcolm a écrit :
> On Tue, 2012-04-03 at 15:23 +0200, Richard Guenther wrote:
>> On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther
>> wrote:
>>> On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm wrote:
I wrote a script and ported my proposed API for GCC plugins f
On Tue, Apr 3, 2012 at 10:45 AM, Fu, Chao-Ying wrote:
> Andrew Pinski wrote:
>
>> 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-*-* i
Hi Richard,
Could you please provide some more instructions on how you got your 2.95 build
using GCC 3?
I just tried using GCC 3.4.6 (from
http://packages.ubuntu.com/hardy/amd64/gcc-3.4-base/download) and build from
source using this command:
CC=../gcc-3.4/bin/gcc-3.4 CFLAGS=-D_FORTIFY_SOURCE=0
Andrew Pinski wrote:
> 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 try
We would like to start the process to make GCC 4.8 build in C++ mode by
default.
The mechanics of the change are simple enough. I volunteer to test
changing the default on all primary targets (assuming I can get them
from the GCC build farm).
Concurrently with this, Lawrence and Ian are w
Hi,
Recently I found a test program got wrongly reloaded, as reported in PR52804.
As the comment, I think reload_reg_reaches_end_p in reload1.c should
handle case:
The first reload type is RELOAD_FOR_INPADDR_ADDRESS;
the second reload type is RELOAD_FOR_INPADDR_ADDRESS and the reload
register is sa
On Tue, 2012-04-03 at 15:23 +0200, Richard Guenther wrote:
> On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther
> wrote:
> > On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm wrote:
> >> I wrote a script and ported my proposed API for GCC plugins from my
> >> CamelCase naming convention to an undersco
On Tue, 2012-04-03 at 12:03 +0200, Richard Guenther wrote:
> On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm wrote:
> > 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 pla
On 03/04/12 15:04, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>
> Hmmm, you're right, I didn't notice those. You said that on your system
> QImode is 16 bits. These modes are being used to efficiently load
> 16-bit, 32-bit, and 64-bit values, in order to handle DW_EH_PE_udata2
> and f
"Paulo J. Matos" writes:
> On 30/03/12 05:11, Ian Lance Taylor wrote:
>
>> There really shouldn't be anything in the exception support that uses
>> SImode. That would be a bug. And I don't see anything that uses
>> SImode. What are you looking at? What I see is things that use mode
>> __unwin
Hi,
Alexander Monakov skribis:
> The code has been merged into graphite branch; it can be obtained via:
>
> svn co svn://gcc.gnu.org/svn/gcc/branches/graphite
Excellent, thanks!
Ludo’.
On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther
wrote:
> On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm wrote:
>> 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
On 30/03/12 05:11, Ian Lance Taylor wrote:
"Paulo J. Matos" writes:
I am porting my backend to GCC47 and have been jumping through some
hurdles. libgcc is trying to compile unwind*.c files which I can't
remember being there for GCC46.
They were there. In 4.6 they were in the gcc subdirector
On Tue, Apr 3, 2012 at 12:21 PM, Andrew Haley wrote:
> On 04/02/2012 06:29 PM, Roman Suvorov wrote:
>> Hello everyone,
>> Not sure if this is the right place to ask this question, feel free to point
>> me in the right direction.
>
> Redirect to gcc-help.
>
>> I'm looking into the evolution of Lin
On 04/02/2012 06:29 PM, Roman Suvorov wrote:
> Hello everyone,
> Not sure if this is the right place to ask this question, feel free to point
> me in the right direction.
Redirect to gcc-help.
> I'm looking into the evolution of Linux kernel and this requires me
> to build some ancient releases
On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm wrote:
> 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 f
2012/4/3 Jiangning Liu :
>
> 在 2012-4-2 下午4:37，"Richard Guenther" 写道：
>
>
>>
>> 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;
>> >
>> >
Quoting Stefano Lattarini :
By looking at the 'handle_texinfo_helper' function in the automake script,
I suspect adding a new Automake option 'info-in-builddir' (say) and an
handful of lines to the automake script might be enough to give you an easy
way to force the '.info' files to be generated
35 matches
Mail list logo
