On Wed, Apr 15, 2009 at 7:11 AM, Dave Korn
wrote:
> H.J. Lu wrote:
>> On Wed, Apr 15, 2009 at 6:49 AM, Dave Korn
>> wrote:
>>> Jakub Jelinek wrote:
>>>> GCC 4.4.0 release candidate 1 is now available at:
>>>>
>>>> ftp://gcc.gnu.org/pu
n pseudo-ops inserted in the assembly. I'm AFK for a few hours now but
> will pursue this later tonight.
>
If your COMMON doesn't support alignment, you may need to use .bss with
.align.
--
H.J.
A-64 binary tar ball for RedHat
EL 4.
5. binutils-2.19.51.0.4.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
04/20/2009
for that be in the tprintlog
> function after it's done with it?
>
> In any case none of those combinations seem to affect the output.
>
va_list points to stack memory. Are you passing pointer to stack memory
from one thread to another? How is this behavior defined?
--
H.J.
89
to remove the empty g++.dg/warn/pr35652.C and gcc.dg/pr35652.c.
--
H.J.
by revision 146817, which has triggered a few bugs.
--
H.J.
inaries to others.
I have been using:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00132.html
--
H.J.
&& kind > gnu_v3_complete_object_allocating_ctor)
try to check? It looks like a typo to me.
--
H.J.
binutils-2.19.51.0.6.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
04/29/2009
a Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
06/01/2009
EL 4.
5. binutils-2.19.51.0.8.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
06/03/2009
-32 binary tar ball for RedHat
EL 4.
4. binutils-2.19.51.0.9.ia64.tar.bz2. IA-64 binary tar ball for RedHat
EL 4.
5. binutils-2.19.51.0.9.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/deve
Hi,
Hopeful, this release has all IFUNC bugs fixed.
Thanks.
H.J.
This is the beta release of binutils 2.19.51.0.10 for Linux, which is
based on binutils 2009 0618 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to
to include it in -Wall. You fixed 3 warnings in
gcc and I fixed 1 in binutils. If you have thousands of packages in C,
-Wall may generate hundreds of warnings. It will make gcc 4.5.0
unusable to those people.
--
H.J.
sitive errors may not be feasible on top of many other real
issues in gcc and packages.
--
H.J.
>>> Similar behavior seems to be present in 4.3.3.
>>>
>>> Does anybody have some insight? Should I file
>>> a bug report?
>>>
>>
>> I can't reproduce this with "GCC: (GNU) 4.3.3 20081110 (prerelease)"
>>
>> .L8:
>> movzwl (%ecx), %eax
>> addl $1, %ebx
>> addl $2, %ecx
>> movw %ax, (%edx)
>> addl $2, %edx
>> cmpl %ebx, 16(%ebp)
>> jg .L8
>>
>> I think you should upgrade.
>>
>> Andrew.
>>
>
> OK, try this then:
>
> void
> c(char *d, volatile char *s)
> {
> int i;
> for ( i=0; i<32; i++ )
> d[i]=s[i];
> }
>
>
> (gcc --version: gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3)
^
That may be too old. Gcc 4.3.4 revision 148680
generates:
.L5:
leaq(%rsi,%rdx), %rax
movzbl (%rax), %eax
movb%al, (%rdi,%rdx)
addq$1, %rdx
cmpq$32, %rdx
jne .L5
--
H.J.
Main changes from binutils 2.19.51.0.10:
Fix strip on static executable with STT_GNU_IFUNC symbol. PR 10337.
Add STB_GNU_UNIQU support.
H.J.
---
This is the beta release of binutils 2.19.51.0.11 for Linux, which is
based on binutils 2009 0627 in CVS on sourceware.org plus various
changes. It
can be
> closed already. For #4, it should be a matter of testing the
> branch with:
>
I have been testing LTO on Linux/ia32 and Linux/x86-64.
I had to disable LTO test on Linux/ia64 since it miscompiled
several Java testcases into infinite loops. I can try to find out
which checkin caused this if needed.
--
H.J.
> to have no problem with it.
>
Can't resist. So in theory, someone can sue LLVM and win. If it is the
case, I may
not want to use LLVM as my system compiler.
--
H.J.
the link of genmodes fails because
> genmodes.o and errors.o are in 32 bit mode and libiberty is in 64 bit mode.
>
I am using
# CC="gcc -m32" CXX="g++ -m32" ./configure
to bootstrap 32bit gcc on 64bit Linux.
--
H.J.
On Wed, May 5, 2010 at 12:41 PM, Basile Starynkevitch
wrote:
> On 05/05/2010 07:42 PM, H.J. Lu wrote:
>>
>> On Wed, May 5, 2010 at 10:18 AM, Steve Ellcey wrote:
>>>
>>> I was wondering if anyone has built GCC using a CFLAGS (and CXXFLAGS)
>>> setting
&g
Hi,
I created a branch for 256bit vectorizer, branches/vect256/. Richard
and I will work on it to extend vectorizer to 256bit.
Jason, can you include it in git mirror? We can drop the ix86 branch
in git since there are several branches under branches/ix86.
Thanks.
--
H.J.
On Tue, May 11, 2010 at 7:49 AM, Jason Merrill wrote:
> On 05/11/2010 10:30 AM, H.J. Lu wrote:
>>
>> I created a branch for 256bit vectorizer, branches/vect256/. Richard
>> and I will work on it to extend vectorizer to 256bit.
>>
>> Jason, can you include it in
On Tue, May 11, 2010 at 9:40 AM, Jason Merrill wrote:
> On 05/11/2010 11:21 AM, H.J. Lu wrote:
>>
>> On Tue, May 11, 2010 at 7:49 AM, Jason Merrill wrote:
>
>>> git config --add remote.origin.fetch
>>> refs/remotes/vect256:refs/remotes/origin/vect256
>&
.tar.bz2. X64_64 binary tar ball for RedHat
EL 5.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
05/27/2010
599 {*call_0} (nil)
(nil))
Since vzeroupper will change xmm0/ymm0, the value saved on stack is wrong.
Is that a way to tell IRA not to move an instruction?
Thanks.
--
H.J.
On Fri, May 28, 2010 at 3:03 PM, Jeff Law wrote:
> On 05/28/10 10:38, H.J. Lu wrote:
>>
>> Hi,
>>
>> I want to generate vzeroupper when I know upper 128bits aren't used. I
>> can't find
>> a way to mark an pattern which zeros upper 128b
On Fri, May 28, 2010 at 9:08 PM, Vladimir N. Makarov
wrote:
> On 05/28/2010 12:38 PM, H.J. Lu wrote:
>>
>> Hi,
>>
>> I want to generate vzeroupper when I know upper 128bits aren't used. I
>> can't find
>> a way to mark an pattern which zeros u
PDF file to describe how vzeroupper is added. But
the PDF attachment was rejected by the gcc mailing list. Please send
me an email if you want it.
Thanks.
--
H.J.
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov wrote:
> H.J. Lu wrote:
>>
>> Hi,
>>
>> I am working on generating vzeroupper to avoid AVX->SSE transition
>> penalty.
>>
>> I have generated vzeroupper on function return as well as function
>&
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov wrote:
> H.J. Lu wrote:
>>
>> Hi,
>>
>> I am working on generating vzeroupper to avoid AVX->SSE transition
>> penalty.
>>
>> I have generated vzeroupper on function return as well as function
>&
it is an excellent tool to create and share patches. Maybe we should
have an open gcc git mirror with gitweb and every contributor can create
his/her own branches and publish them.
--
H.J.
On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
wrote:
> On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law wrote:
>> On 06/10/10 13:52, H.J. Lu wrote:
>>> On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
>>> wrote:
>>>> Cross-posting Reza's call for fe
oaches to solve alignment problem.
>>
>> a) Let the assembler performs the alignments and padding needed
>> to adhere with the new machine dispatching rules and avoid an extra
>> pass in GCC.
>> b) Add a new pass to mimic what assembler does before generating
>> the assembly listing in GCC and insert the required alignments.
>>
>> I appreciate your comments on the proposed implementation procedure
>> and the choices a or b above.
I don't this should be done in assembler. Assembler should just assemble
the assembly input.
--
H.J.
On Thu, Jun 10, 2010 at 3:09 PM, Quentin Neill
wrote:
> On Thu, Jun 10, 2010 at 4:08 PM, H.J. Lu wrote:
>> On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
>> wrote:
>>> On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law wrote:
>>>> On 06/10/10 13:52, H.J. Lu wrote:
&g
out the structure (block starts, ends,
> instruction sets) using macros/assertions/tokens if needed.
>
> Another option would be to expose some subset of the assembler
> functionality as a plugin to GCC (similar to how gold is used) to
> extract the instruction sizes. Any comments on that approach?
>
I would suggest generating object code directly, totally bypassing
assembler. Many compilers do it. But it is a HUGE effort.
--
H.J.
arn every time that using LTO (or any
> other option) may lead to miscompilation than find out later that my
> program is behaving strange. A warning is a limitation I can live
> with. Wrong results from perfectly valid programs, not so nice.
>
What about issue an error during the final link when linker plugin
is required for correctness, but not used?
--
H.J.
On Fri, Jun 11, 2010 at 3:42 PM, Quentin Neill
wrote:
> On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu wrote:
>> [snip]
>> x86 assembler isn't an optimizing assembler. -mtune only does
>> instruction selection. What you are proposing sounds like an optimizing
>>
On Sat, Jun 12, 2010 at 8:15 AM, H.J. Lu wrote:
> On Fri, Jun 11, 2010 at 3:42 PM, Quentin Neill
> wrote:
>> On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu wrote:
>>> [snip]
>>> x86 assembler isn't an optimizing assembler. -mtune only does
>>> instructi
;__gnu_cxx::__pool, true>::_S_get_pool()' can
> not be used when making a shared object; recompile with -fPIC
>
This is caused by one of:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02571.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01990.html
--
H.J.
On Fri, Jun 25, 2010 at 11:38 AM, H.J. Lu wrote:
> On Fri, Jun 25, 2010 at 7:50 AM, Paolo Carlini
> wrote:
>> Hi,
>>
>> everything was fine until this morning, now upon make-check in the v3
>> dir, during the final link for testsuite_shared.so, ld spills:
>>
binary tar ball for RedHat
EL 5.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
07/09/2010
> Sounds good to me. Anybody want to add this to the GNU tools?
>
Not very interesting to Linux. We don't use hardware capability filters.
However, it is nice to mark a binary which ISAs it uses. But it should
be specified in the psABI.
--
H.J.
On Tue, Jul 13, 2010 at 6:39 AM, H.J. Lu wrote:
> On Tue, Jul 13, 2010 at 4:26 AM, Ian Lance Taylor wrote:
>> Rainer Orth writes:
>>
>>> Ian Lance Taylor writes:
>>>
>>>> Unfortunately, as far as I know, no such solution was ever adopted for
>
oc'd or (recently) free'd
==23110==
inv_dee_main.f: In function ‘inv_dee_main’:
inv_dee_main.f:1:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
==23110==
--
H.J.
x86 targets by
configuring GCC with the @option{--enable-frame-pointer} configure
option.
--
isn't very accurate. Any suggestions?
Thanks.
--
H.J.
---
2010-08-09 H.J. Lu
* config.gcc: Handle --enable-frame-pointer.
* configure.ac: Add --enable-frame-pointer.
. binutils-2.20.51.0.11.tar.bz2. Source code.
2. binutils-2.20.51.0.11.i686.tar.bz2. IA-32 binary tar ball for RedHat
EL 5.
3. binutils-2.20.51.0.11.ia64.tar.bz2. IA-64 binary tar ball for RedHat
EL 5.
4. binutils-2.20.51.0.11.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 5.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
08/10/2010
Hi,
Sometime I have to do
int x = 0;
to silence gcc from uninitialized warnings when I know it is
unnecessary. Is that a good idea to add
int x __attribute__ ((uninitialized));
to tell compiler that it is OK for "x" to be uninitialized?
--
H.J.
On Fri, Aug 20, 2010 at 1:57 PM, Bernd Schmidt wrote:
> On 08/20/2010 10:51 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> Sometime I have to do
>>>
>>> int x = 0;
>>>
>>> to silence gcc from uninitialized w
formance. Could
> someone please help figure this out?
>
Can you try gcc 4.5.1?
--
H.J.
ack
>
Please try:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=21697
The real problem is that a hack for make dependency in libdecnumber is
included in config/dfp.m4 which breaks many targets.
--
H.J.
show any changes on the i386 side that
> look like adjustments along these lines. Is this something ia64-specific?
> Any pointers, suggestions?
>
> I'm sure Anton will be happy to test any patches that one of us may come
> up with.
>
> Gerald
>
You need to include config/ia64/t-ia64 in libgcc.
--
H.J.
On Sat, Sep 18, 2010 at 6:33 AM, Jonathan Wakely wrote:
> HJ has just identified the commit that caused the problem - I should
> have waited a few more minutes before sending my RFH :-)
>
> Thanks, HJ
>
I should find the fix on trunk in about an hour.
--
H.J.
On Sat, Sep 18, 2010 at 6:35 AM, H.J. Lu wrote:
> On Sat, Sep 18, 2010 at 6:33 AM, Jonathan Wakely
> wrote:
>> HJ has just identified the commit that caused the problem - I should
>> have waited a few more minutes before sending my RFH :-)
>>
>> Thanks, HJ
>>
dary and
generate 16byte outgoing stack boundary.
>
> MAX_STACK_BOUNDARY
> -- default to I_S_B.
>
> and delete many of the x86 backend options that fiddle
> stuff that users ought not be fiddling. Like forcing
> the use of DRAP register.
>
-mdrap is mainly for testing purpose and used in testsuite.
It has caught many bugs. Removing it means regressions
may become latent.
--
H.J.
On Mon, Oct 4, 2010 at 11:27 AM, Richard Henderson wrote:
> On 10/02/2010 04:03 PM, H.J. Lu wrote:
>>> MIN_STACK_BOUNDARY
>>> (undocumented; local to i386 atm)
>>> -- appears to be the ABI specified stack boundary, i.e.
>>> the minimum that must be in p
On Tue, Oct 5, 2010 at 8:57 AM, Richard Henderson wrote:
> On 10/04/2010 04:24 PM, H.J. Lu wrote:
>> As I remembered, -mforce-drap exposed issues with register allocator.
>> ix86_force_drap is only referenced in one place in i386.c. I'd like to keep
>> it. I don'
On Tue, Oct 5, 2010 at 8:57 AM, Richard Henderson wrote:
> On 10/04/2010 04:24 PM, H.J. Lu wrote:
>> As I remembered, -mforce-drap exposed issues with register allocator.
>> ix86_force_drap is only referenced in one place in i386.c. I'd like to keep
>> it. I don'
04 040000 8eba3de7802f571601cb7092cfd546609f24086f
> c8b21579e48331ae0fa528fb89a228ea94211691 M gcc
>
It could be:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45865
--
H.J.
On Wed, Oct 13, 2010 at 1:05 PM, Sebastian
wrote:
> Hi,
> can gcc show the size of the stackframe of functions, so you can, given
GCC 4.6.0 has -fstack-usage.
--
H.J.
ar ball for RedHat
EL 5.
4. binutils-2.20.51.0.12.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 5.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
10/22/2010
heck" with default options, or do you
> specify compiler options which should result in linking
> non-default c++ libraries?
I use
# make check RUNTESTFLAGS="--target_board 'unix{-m32,}'"
to test both 32bit/64bit on Intel64.
H.J.
Does Go depend on split stack? There are at least 2 split stack bugs
open for x86 target.
H.J.
something in gcc/go/config-lang.in?
>
> I have now done this on the gccgo branch. If language X's
> config-lang.in sets the shell variable lang_requires_boot_language, then
> if X is enabled all those languages are built during stage 1.
>
Don't we have boot_language for this purpose?
--
H.J.
On Fri, Oct 29, 2010 at 4:39 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor wrote:
>>> Paolo Bonzini writes:
>>>
>>>> On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
>>>>&g
.
My zlib changes are on hjl/zlib branch at
http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary
Any comments?
Thanks.
--
H.J.
On Sat, Oct 30, 2010 at 2:37 PM, Frank Ch. Eigler wrote:
> "H.J. Lu" writes:
>
>> [...] By default, the in-tree zlib is used. If you configure
>> binutis using --with-system-zlib, system zlib will be used. [...]
>
> Can you summarize what modern plat
On Sun, Oct 31, 2010 at 11:42 AM, Ian Lance Taylor wrote:
> f...@redhat.com (Frank Ch. Eigler) writes:
>
>> "H.J. Lu" writes:
>>
>>> [...] By default, the in-tree zlib is used. If you configure
>>> binutis using --with-system-zlib, system zlib wil
selecting between doubleword and quadword vectors via
> a target specific commandline option. Idealy you wouldn't need this at all,
> but I don;t believe the vectorizer is capable of handling this.
x86 supports either 128bit (SSE) or 256bit (AVX) vectors. It works OK.
--
H.J.
n my autotesters for Linux/ia32 and
Linux/x86-64.
--
H.J.
em-zlib --with-demangler-in-ld --enab
le-shared --enable-threads=posix --enable-haifa --prefix=/usr/gcc-4.6.0 --with-
local-prefix=/usr/local --with-fpmath=sse --with-plugin-ld=ld.gold --enable-gold
--with-fpmath=sse
--
H.J.
FYI, GCC trunk revision 166285 passes SPEC CPU 2000/2006.
It is the first time in a month.
--
H.J.
but the PR still remains assigned to unassig...@gcc.gnu.org,
> which doesn't seem to make sense to me. Am I doing something wrong
> here? If not, it would be extremely helpful to restore the old 2.x
> behaviour.
>
I noticed that if I upload a patch, I have the option to take the bug.
--
H.J.
e that
> there are cases where the combine pass will combine instructions across
> an unspec_volatile, so in that sense an unspec_volatile is not a
> scheduling barrier. (The combine pass will not attempt to combine the
> unspec_volatile instruction itself.)
>
IRA may move instructions across an unspec_volatile,
--
H.J.
es for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
11/12/2010
On Sat, Nov 13, 2010 at 2:27 AM, Paolo Bonzini wrote:
> On 11/12/2010 03:25 PM, H.J. Lu wrote:
>>
>> IRA may move instructions across an unspec_volatile,
>
> Do you have a testcase?
>
x86 has
;; Clear the upper 128bits of AVX registers, equivalent to a NOP
;; if the
On Sat, Nov 13, 2010 at 6:56 AM, Paolo Bonzini wrote:
> On 11/13/2010 03:34 PM, H.J. Lu wrote:
>>
>> On Sat, Nov 13, 2010 at 2:27 AM, Paolo Bonzini wrote:
>>>
>>> On 11/12/2010 03:25 PM, H.J. Lu wrote:
>>>>
>>>> IRA may move instructions
On Sat, Nov 13, 2010 at 8:01 AM, Paolo Bonzini wrote:
> On 11/13/2010 04:28 PM, H.J. Lu wrote:
>>
>> VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
>
> IIUC it's a noop as GCC uses it. You could use it in 256-bit mode and it
> would be
On Sat, Nov 13, 2010 at 8:20 AM, Paolo Bonzini wrote:
> On 11/13/2010 05:10 PM, H.J. Lu wrote:
>>
>> On Sat, Nov 13, 2010 at 8:01 AM, Paolo Bonzini wrote:
>>>
>>> On 11/13/2010 04:28 PM, H.J. Lu wrote:
>>>>
>>>> VZEROUPPER is
need alternate source for eon. I use:
252.eon=default=default=default:
CXXPORTABILITY = -DHAS_ERRLIST
EXTRA_CXXFLAGS=-ffast-math -mpc64
EXTRA_LDFLAGS = -ffast-math -mpc64
srcalt=gcc43
176.gcc=default=default=default:
CPORTABILITY = -Dalloca=_alloca
--
H.J.
ough.
>
> HJ, could you please run a binary search? Thanks a lot in advance,
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42670#c8
--
H.J.
of the Java testers catches you, you still have an obligation to fix the
>> problem. All we're changing is whether you build Java by default;
>> nothing else.
>
> I made it pretty clear that as long as the autotesters build java, and I
> get emails when something breaks, and you have the obligation to fix
> whatever broke, I have no objection.
>
> Andrew.
>
FYI, this testsuite regression is only seen in libjava:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515
--
H.J.
Hi,
Given a basic block BB, is there a way to tell if it will reach EXIT_BLOCK_PTR?
Thanks.
--
H.J.
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
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 insi
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
>> wi
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:
>> >>
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 generat
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
>&g
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
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:
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:
>>>
nerate the division inline, or call a different specialized version.
> All of these routines are outside the user's namespace, and we should
> be able to optimize without regard for what the user's libraries might
> contain.
>
__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.
--
H.J.
bug-2.tar.bz2
Description: BZip2 compressed data
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 spec
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
On Thu, Dec 2, 2010 at 6:52 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 5:53 PM, Ian Lance Taylor wrote:
>>
>>> Or I'll rephrase: are there any cases for which using -pass-through for
>>> the set of librarie
On Thu, Dec 2, 2010 at 9:00 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> I am not saying we should go with 2 stage linking. Just for clarification.
>> In 2 stage linking, the first stage only does symbol resolution. The complete
>> linking starts at
On Thu, Dec 2, 2010 at 9:20 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Thu, Dec 2, 2010 at 9:00 AM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
>>>> I am not saying we should go with 2 stage linking. Just for cla
On Thu, Dec 2, 2010 at 9:41 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> How do you deal with -lm:
>
> I believe we have agreed that LTO can only introduce new symbol
> references that are satisfied by -lc and -lgcc. Under those conditions,
Have you loo
On Thu, Dec 2, 2010 at 10:37 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Thu, Dec 2, 2010 at 9:41 AM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
>>>> How do you deal with -lm:
>>>
>>> I belie
601 - 700 of 1206 matches
Mail list logo
