Hi,
I fixed the symbolic link. It's http://mirror-fpt-telecom.fpt.net/gcc
Thanks your notice.
VTMinh
From: Gerald Pfeifer [ger...@pfeifer.com]
Sent: Monday, November 29, 2010 2:12 AM
To: Minh Vu Tong
Cc: gcc@gcc.gnu.org
Subject: ftp.net mirror of gcc.gnu.
On 1 December 2010 02:45, Russell Whitaker wrote:
>
> Minor build bug: The cpp sanity check fails because it is looking for cpp in
> /lib instead of /usr/bin
Like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950 ?
In that case it was because there was no C++ compiler installed when
building gcc.
Hi, team
Question 1:
std(N3000=09-0190) 8.3.5/6 says that:
A cv-qualifier-seq shall only be part of the function type for a
non-static member function, the function type to which a pointer to
member refers, or the top-level function type of a function typedef
declaration.
const void func();
ca
> I don't understand what makes you say this. Partial conversions have
> much lower chance of breaking things when the macro is set up in
> complicated ways, and you also trivially avoid performance regressions at
> non-converted call site.
But what's the point in doing this during stage3? This
On 1 December 2010 10:28, zhang qingshan wrote:
> Hi, team
This sort of question should be sent the mailing list gcc-h...@gcc.gnu.org,
not the mailing list g...@gcc.gnu.org. gcc@gcc.gnu.org is for the
development of gcc itself. Please take any future questions about using
gcc to gcc-help. Thank
Quoting Laurent GUERBY :
On Wed, 2010-12-01 at 00:32 -0500, Joern Rennecke wrote:
bootstrapped & regtested on x86_64-pc-linux-gnu
cross-tested on x86_64-pc-linux-gnu for the following targets:
ppc-darwin
alpha-linux-gnu hppa-linux-gnu mips-elf sh-elf arc-elf ia64-elf sparc-elf
arm-eabi iq2000-e
On Wed, 1 Dec 2010, Joern Rennecke wrote:
> Once all target macros are eliminated from a frontend file, the way to
> avoid regressions is to eliminate all direct and indirect includes of
> tm.h. And once we have archived that for all frontend files, we can poison
> the include guards of tm.h and
On Tue, Nov 30, 2010 at 08:04:06PM +0100, Joakim Tjernlund wrote:
> Why is not
> const char cstr[] = "mystr";
> const int myint = 3;
> added to a read only section?
> Especially since
> const int myarr[]={1,2,3};
> is placed in .rodata.
>
> hmm, -G 0 does place these in .rodata but why do I
Nathan Froyd wrote on 2010/12/01 18:33:23:
>
> On Tue, Nov 30, 2010 at 08:04:06PM +0100, Joakim Tjernlund wrote:
> > Why is not
> > const char cstr[] = "mystr";
> > const int myint = 3;
> > added to a read only section?
> > Especially since
> > const int myarr[]={1,2,3};
> > is placed in .ro
Hi,
Here is a proposal to update LTO plugin interface. Any comments?
Thanks.
--
H.J.
---
Goal: We should preserve the same linker command line order as if
there are no IR.
Problem:
a. LTO may generate extra symbol references which aren't in IR.
b. It was worked around with -pa
On Wed, 1 Dec 2010 10:18:58 -0800
"H.J. Lu" wrote:
> Here is a proposal to update LTO plugin interface.
How should we parse the above sentence?
Is it about an interface to plugin inside binutils to support LTO?
Is it about an interface for GCC plugins to help them be more LTO friendly?
Is i
On Wed, Dec 1, 2010 at 10:28 AM, Basile Starynkevitch
wrote:
> On Wed, 1 Dec 2010 10:18:58 -0800
> "H.J. Lu" wrote:
>
>> Here is a proposal to update LTO plugin interface.
>
> How should we parse the above sentence?
>
> Is it about an interface to plugin inside binutils to support LTO?
>
> Is it
Hi,
Compiling C++ on the head targeting
arm-rtems4.11, I get this error. It doesn't
occur on m68k-rtems4.11. I don't know about
the other targets yet.
Any suggestions on what is causing this
and how to resolve it?
libtool: compile: /users/joel/test-gcc/b-gcc1-arm/./gcc/xgcc
-shared-libgcc
"H.J. Lu" writes:
> b. Compiler plugin controls what linker uses to generate the final
> executable:
> i. The linker command line order should be the same, with or
> without LTO.
> c. Add a cmdline bit field to
> struct ld_plugin_input_file
> {
> c
On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> b. Compiler plugin controls what linker uses to generate the final
>> executable:
>> i. The linker command line order should be the same, with or
>> without LTO.
>> c. Add a cmdline bit f
> On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor wrote:
> > "H.J. Lu" writes:
> >
> >> b. Compiler plugin controls what linker uses to generate the final
> >> executable:
> >> i. The linker command line order should be the same, with or
> >> without LTO.
> >> c. Add
2010/12/1 Jan Hubicka :
>> On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor wrote:
>> > "H.J. Lu" writes:
>> >
>> >> b. Compiler plugin controls what linker uses to generate the final
>> >> executable:
>> >> i. The linker command line order should be the same, with
>> >> or
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> b. Compiler plugin controls what linker uses to generate the final
>>> executable:
>>> i. The linker command line order should be the same, with or
>>> without LTO.
>>>
On Nov 29, 2010, at 9:51 PM, Vladimir Makarov wrote:
> On 11/29/2010 08:52 PM, Paul Koning wrote:
>> I'm doing some experiments to get to know GCC better, and something is
>> puzzling me.
>>
>> I have defined an md file with DFA and costs describing the fact that loads
>> take a while (as do s
On Wed, Dec 1, 2010 at 11:12 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
b. Compiler plugin controls what linker uses to generate the final
executable:
i. The linker c
Nathan Froyd wrote on 2010/12/01 18:33:23:
>
> On Tue, Nov 30, 2010 at 08:04:06PM +0100, Joakim Tjernlund wrote:
> > Why is not
> > const char cstr[] = "mystr";
> > const int myint = 3;
> > added to a read only section?
> > Especially since
> > const int myarr[]={1,2,3};
> > is placed in .ro
In message <4cf69533.10...@oarcorp.com>
Joel Sherrill wrote:
> Hi,
>
> Compiling C++ on the head targeting
> arm-rtems4.11, I get this error. It doesn't
> occur on m68k-rtems4.11. I don't know about
> the other targets yet.
>
> Any suggestions on what is causing this
> and how to re
On 12/01/2010 02:16 PM, John Tytgat wrote:
In message<4cf69533.10...@oarcorp.com>
Joel Sherrill wrote:
Hi,
Compiling C++ on the head targeting
arm-rtems4.11, I get this error. It doesn't
occur on m68k-rtems4.11. I don't know about
the other targets yet.
Any suggestions on what i
"H.J. Lu" writes:
> We don't want to put all unclaimed files passed to plugin back to linker.
> On Linux,
>
> [...@gnu-6 gcc-lto]$ cat /usr/lib/libc.so
> /* GNU ld script
>Use the shared library, but some functions are only in
>the static library, so try that secondarily. */
> OUTPUT_FOR
On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> We don't want to put all unclaimed files passed to plugin back to linker.
>> On Linux,
>>
>> [...@gnu-6 gcc-lto]$ cat /usr/lib/libc.so
>> /* GNU ld script
>> Use the shared library, but some functions are only in
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
>
>> Are you planning to have the plugin claim all files, even linker
>> scripts, and then pass only the command line files back to the linker?
>>
>
> Plugin will keep the same claim strategy. For those aren't claimed
On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
>>
>>> Are you planning to have the plugin claim all files, even linker
>>> scripts, and then pass only the command line files back to the linker?
>>>
>>
>>
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
>>>
Are you planning to have the plugin claim all files, even linker
scripts, and then pass only the command line files ba
On Wed, Dec 1, 2010 at 10:28 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
> Are you planning to have the plugin claim all files, eve
On Wed, Dec 1, 2010 at 1:28 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
> Are you planning to have the plugin claim all files, even
On Wed, Dec 1, 2010 at 1:33 PM, Richard Guenther
wrote:
> On Wed, Dec 1, 2010 at 10:28 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor wrote:
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
>>
Arnaud Lacombe writes:
> On Fri, Nov 19, 2010 at 11:58 PM, Arnaud Lacombe wrote:
>> sysinfo.go:2874:13: error: use of undefined type 'func___sighandler_t'
>>
> gen-sysinfo.go has :
>
> // type ___sighandler_t func*(int32)
That is not valid Go, so this looks like a bug in godump.c. What does
th
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 1:28 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>> For linker script, archive, DSO and object file without IR,
>>> *claimed will return 0 and plugin will save and pass it back to
>>> linker later in if it is specified at command line.
>>
>> I d
> If we get into extending linker plugin interface, it would be great if we
> would
> do somehting about COMDAT. We now have RESOLVED and RESOLVED_IRONLY, while
> the
> problem is that all non-hidden COMDAT symbols get RESOLVED that pretty much
> fixes them in the output library.
>
> I would pro
On Wed, 1 Dec 2010, Vu Tong Minh wrote:
> I fixed the symbolic link. It's http://mirror-fpt-telecom.fpt.net/gcc
Excellent, thanks a lot!
Gerald
>> That is what "Discard all previous inputs" in stage 2 linking is for.
>
> But what does that mean? Are you saying that the linker interface to
> the plugin should change to work that way? If we do that, then we
> should change other aspects of the plugin interface as well. It could
> probably
On Nov 30, 2010, at 3:12 PM, Joe Buck wrote:
> On Tue, Nov 30, 2010 at 01:49:23PM -0800, Gabriel Dos Reis wrote:
>> The existing GCC behaviour is a bit more perverse than the
>> C malloc() case as in
>>
>> new T[n]
>>
>> there is no multiplication that could be credited to careless progra
Hi Diego! Sorry to have missed this talk at the GCC Summit, this work
looks interesting.
> We have created a new branch for the incremental parsing work
> that Lawrence and I described at the last GCC Summit
> (http://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=IncrementalCompile
On Wed, Dec 1, 2010 at 3:06 PM, Cary Coutant wrote:
>>> That is what "Discard all previous inputs" in stage 2 linking is for.
>>
>> But what does that mean? Are you saying that the linker interface to
>> the plugin should change to work that way? If we do that, then we
>> should change other asp
>> The only aspect of link
>> order that isn't maintained is the physical order of the sections in
>> memory.
>
> That is exactly the problem my proposal tries to address.
Really? That's not at all what PR 12248 is about. The physical order
of the sections (meaning the order of contributions withi
On 12/1/10, Benjamin Kosnik wrote:
> Hi Diego! Sorry to have missed this talk at the GCC Summit, this work
> looks interesting.
>
>> We have created a new branch for the incremental parsing work
>> that Lawrence and I described at the last GCC Summit
>> (http://gcc.gnu.org/wiki/summit2010?action=A
> I'm also not sure what you mean by "resolved IRONLY except that it is
> externally visible to the dynamic linker." If we're building a shared
> library, and the symbol is exported, it's not going to be IRONLY, and
> I don't see how it would be valid to optimize it out. If we're
Well, the typical
"H.J. Lu" writes:
> __udivdi3 is just an example. It can also happen to memcpy, or
> any library calls generated by GCC. I am enclosing a testcase for memcpy.
I believe we can solve that specific problem much more efficiently than
requiring a complete link of all the input files. We currently
>> I'm also not sure what you mean by "resolved IRONLY except that it is
>> externally visible to the dynamic linker." If we're building a shared
>> library, and the symbol is exported, it's not going to be IRONLY, and
>> I don't see how it would be valid to optimize it out. If we're
>
> Well, the
> >> I'm also not sure what you mean by "resolved IRONLY except that it is
> >> externally visible to the dynamic linker." If we're building a shared
> >> library, and the symbol is exported, it's not going to be IRONLY, and
> >> I don't see how it would be valid to optimize it out. If we're
> >
>
On Wed, Dec 1, 2010 at 4:48 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> __udivdi3 is just an example. It can also happen to memcpy, or
>> any library calls generated by GCC. I am enclosing a testcase for memcpy.
>
> I believe we can solve that specific problem much more efficiently than
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 4:48 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> __udivdi3 is just an example. It can also happen to memcpy, or
>>> any library calls generated by GCC. I am enclosing a testcase for memcpy.
>>
>> I believe we can solve that specific proble
For the rtl passes, architecture target macros are not much of an issue
with regards to executable code modularity: since the rtl passes are
deeply interwoven with the insn-*.c files, we might as well compile one
specialized copy of the rtl passes for each target architecture.
Another argument ag
On Wed, Dec 1, 2010 at 5:53 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 4:48 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
__udivdi3 is just an example. It can also happen to memcpy, or
any library calls generated by GCC. I am enclosing a testc
Joern Rennecke writes:
> For the rtl passes, architecture target macros are not much of an issue
> with regards to executable code modularity: since the rtl passes are
> deeply interwoven with the insn-*.c files, we might as well compile one
> specialized copy of the rtl passes for each target ar
I think we want to move *away* from inline functions in headers and
towards link-time inlining, in the interests of modularity: if one
component of GCC cannot see the internals of another component at compile
time, it cannot use them but must use the actual interface of that
component, but inli
On Wed, Dec 1, 2010 at 5:36 PM, Chris Lattner wrote:
>
> On Nov 30, 2010, at 3:12 PM, Joe Buck wrote:
>
>> On Tue, Nov 30, 2010 at 01:49:23PM -0800, Gabriel Dos Reis wrote:
>>> The existing GCC behaviour is a bit more perverse than the
>>> C malloc() case as in
>>>
>>> new T[n]
>>>
>>> there
On 01/12/2010 23:06, Cary Coutant wrote:
>> My suspicion is that the LTO plugin can only introduce a small bounded
>> set of new symbol references, namely those which we assume can be
>> satisified from -lc or -lgcc. Is that true?
>
> Exactly.
Potentially also gcov, ssp, mudflap?
> The plug
On 02/12/2010 04:28, Dave Korn wrote:
> I was going to test something like the attached.
Oops, there was a typo in that:
> @@ -637,7 +639,9 @@ proper position among the other output files. */
> -plugin %(linker_plugin_file) \
> -plugin-opt=%(lto_wrapper) \
> -plugin-opt=-fres
On 02/12/2010 00:12, Cary Coutant wrote:
> Think about it -- any failure to bind to an interposed copy of memcpy
> (or any other library call generated by gcc) is indistinguishable from
> the compiler choosing to generate the code inline.
Indeed, replacing library functions is a tricky business
* Chris Lattner:
> On overflow it just forces the size passed in to operator new to
> -1ULL, which throws bad_alloc.
This is also what my patch tries to implement.
56 matches
Mail list logo
