On Sat, Mar 5, 2011 at 11:08 AM, H.J. Lu wrote:
> Hi,
>
> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>
> https://sites.google.com/site/x32abi/
>
> The major remaining issues are glibc/gcc testsuite failures,
> kernel core dump and signal handler unwind.
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
03/07/2011
On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
> On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
>> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>>
>> https://sites.google.com/site/x32abi/
>>
>> The major remaining issues are glibc/gcc t
Hi,
Almost all x32 bugs in kernel, glibc and binutils are fixed:
https://sites.google.com/site/x32abi/
There are no unexpected failures in glibc testsuite. I am
working on remaining GCC bugs.
--
H.J.
On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger wrote:
> On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
>> On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
>> > On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
>> >> Many x32 bugs are fixed in k
On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
> On Wednesday, March 16, 2011 00:51:37 H.J. Lu wrote:
>> On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger wrote:
>> > On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
>> >> On Mon, Mar 7, 2011 at
On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
> On Wednesday, March 16, 2011 08:39:57 H.J. Lu wrote:
>> On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
>> > so we get back to my original e-mail:
>> > are you getting a unique host tuple for this ?
On Wed, Mar 16, 2011 at 10:45 PM, Mike Frysinger wrote:
> On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
>> > ok, took long enough, but that answers most things. your usage of "x32-"
>> > prefixe
remote: aborting due to possible repository corruption on the remote side.
>> [...]
>
> This may be because of cpu runtime limits recently tightened on the
> anonymous git daemon, after we found some processes spinning for
> a very long time. I'll relax the limits.
>
GCC git mirror hasn't been updated for more than 30 hours.
--
H.J.
On Sun, Mar 20, 2011 at 10:08 PM, Mike Frysinger wrote:
> On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
>> > in looking at the gcc files, it doesnt seem like there's any defines
>> > setup to decla
On Sun, Mar 20, 2011 at 10:53 PM, Mike Frysinger wrote:
> On Monday, March 21, 2011 01:35:35 H.J. Lu wrote:
>> On Sun, Mar 20, 2011 at 10:08 PM, Mike Frysinger wrote:
>> > On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> >> On Wed, Mar 16, 2011 at 7:57 PM, Mi
On Mon, Mar 21, 2011 at 1:20 AM, Michael Matz wrote:
> Hi,
>
> On Sun, 20 Mar 2011, H.J. Lu wrote:
>
>> I don't think it will help x32 and I think it will make it harder to add
>> x32 support. I still want to see a real usage before I add it.
>
> % cat real
Hi,
I'd like to bump the default alignment of complex float from 4 byte
to 8 byte. ADJUST_ALIGNMENT doesn't work since SC is a stand
mode. Is that OK to update mode_base_align directly?
Thanks.
--
H.J.
On Thu, Mar 31, 2011 at 9:14 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> I'd like to bump the default alignment of complex float from 4 byte
>> to 8 byte. ADJUST_ALIGNMENT doesn't work since SC is a stand
>> mode. Is that OK to update mode_ba
On Fri, Apr 1, 2011 at 4:49 AM, Joseph S. Myers wrote:
> On Thu, 31 Mar 2011, H.J. Lu wrote:
>
>> Hi,
>>
>> I'd like to bump the default alignment of complex float from 4 byte
>> to 8 byte. ADJUST_ALIGNMENT doesn't work since SC is a stand
>> mode.
On Fri, Apr 1, 2011 at 5:14 AM, Joseph S. Myers wrote:
> On Fri, 1 Apr 2011, H.J. Lu wrote:
>
>> On Fri, Apr 1, 2011 at 4:49 AM, Joseph S. Myers
>> wrote:
>> > On Thu, 31 Mar 2011, H.J. Lu wrote:
>> >
>> >> Hi,
>> >>
>> >
I agree.
FWIW, I reported the breakage and identified the cause within 8 hours of
the initial checkin.
--
H.J.
On Mon, Apr 4, 2011 at 7:51 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/04/11 16:20, H.J. Lu wrote:
>> On Mon, Apr 4, 2011 at 2:58 PM, Steven Bosscher
>> wrote:
>>>
>>> My proposal would be: A patch may be reverte
only affects very few people,
reverting it may not be the best course. But breaking trunk for
most of developers for 3 days isn't a very good idea.
--
H.J.
My patch should've been reverted
>> in the meantime.
> It can make a huge difference if the owner has been unable to reproduce
> and is waiting on the reporter to provide enough information to
> reproduce or debug the problem.
In the case of PR 48403, it seems that most of developers see it. Only
very few people weren't affected. I don't think everyone else should stop
and wait for developer to reproduce it.
--
H.J.
On Tue, Apr 5, 2011 at 7:49 AM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/04/11 20:57, H.J. Lu wrote:
>> On Mon, Apr 4, 2011 at 7:51 PM, Jeff Law wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>
ad cases where the autotester got it wrong as well.
>
I think what Steven proposed is for bootstrap failures on more than one
primary platforms. I don't see any harm to unblock GCC development
while offender can work on it off-trunk
BTW, I would recommend git mirror to work on such bugs off-trunk
It is so convenient.
--
H.J.
pers to
> potentially break the tree for an entire weekend.
>
Also please avoid checking in such patches before leaving on vacation :-(.
Yes, it did happen at the end of 2010.
--
H.J.
often not one bad patch, it's two bad patches going in
> that overlap. Tracking down the precise second patch can't be done with
> a bisect operation.
>
> If we're not going to aggressively revert patches, then maybe we should
> aggressively freeze commits when the tree is broken...
>
Agree.
--
H.J.
http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
04/08/2011
hole program partitioned into smaller chunks,
>> ordered in a way that maximizes optimization opportunities and allow
>> parallel optimization at link-time (and also reduce the memory footprint
>> by reducing the size of the TUs GCC has to deal with).
>>
>> Richard.
>
> Hi Richard,
>
> For what its worth, I got the same error messages using a 04/09/11
> snapshot of binutils/gold version 2.21.51 from Debian. So, if its a bug its
> still there. I'll try -flto-partition=none on Monday.
You can try hjl/lto-mix branch from
http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary
--
H.J.
Hi,
On my target, SCmode is 4 byte aligned. But to load it into
a register, it must be 8byte aligned. I can handle misaligned
load in backend. But IRA generates misaligned load directly
when SCmode is accessed as DImode. How can I tell IRA to use
misaligned load for DImode?
Thanks.
--
H.J.
On Wed, Apr 13, 2011 at 1:50 PM, cirrus75 wrote:
>
> Hi,
>
> Do you mean you support unaligned access to any DImode regular type
> (int64_t) ?
Real DImode support unaligned access. The problem is SCmode accessed via
DImode.
H.J.
---
> regards,
> Alex Prado
>
>
On Wed, Apr 13, 2011 at 12:55 PM, H.J. Lu wrote:
> Hi,
>
> On my target, SCmode is 4 byte aligned. But to load it into
> a register, it must be 8byte aligned. I can handle misaligned
> load in backend. But IRA generates misaligned load directly
> when SCmode is accessed as
bootstrap
Thanks.
--
H.J.
but --enable-checking=yes,rtl. Maybe H.J. had
>> e.g. --enable-checking=release. In any case, something is brittle ATM.
>
> Not really unexpected - LTO testing coverage is pretty low unless we force
> everyone to do LTO bootstraps (and then LTO bootstrap is slow because
> of t
, sd_(sd)
> + : obj_(obj), sd_(sd), arg_serial_(0)
> { }
> // The object file.
> Object* obj_;
>
This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it?
Why doesn't 64bit GCC 4.2 warn it?
--
H.J.
register without using the proper reload_out pattern which has a scratch
register.
How can I tell reload to always use a scratch register when storing a
register?
Thanks.
--
H.J.
On Sat, Apr 30, 2011 at 6:18 AM, Georg-Johann Lay wrote:
> H.J. Lu schrieb:
>>
>> My target needs a scratch register to store a register in one register
>> class
>> and it needs to use memory to copy from one register class to another.
>> I have store and reload
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/08/2011
t can provide better performance and/or
reduce the code size.
GCC x32 branch is available at:
svn://gcc.gnu.org/svn/gcc/branches/x32
Majority of changes are in x86 backend and there are also
some middle-end changes. I appreciate any feedbacks.
Thanks.
--
H.J.
On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann wrote:
> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>> This is the x32 project status update:
>>
>> https://sites.google.com/site/x32abi/
>>
>
> I've had another look at the kernel patch. It basically
>
On Sat, May 21, 2011 at 8:34 AM, H.J. Lu wrote:
> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann wrote:
>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>> This is the x32 project status update:
>>>
>>> https://sites.google.com/site/x32abi/
>>>
&g
On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter wrote:
> I'll look at it but possibly not until the weekend.
I checked it into hjl/x32/syscall branch at
http://git.kernel.org/?p=linux/kernel/git/hjl/linux-2.6.38.y.git;a=summary
H.J.
---
> -Original Message-----
> From: H
On Sat, May 21, 2011 at 4:48 PM, H.J. Lu wrote:
> On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter
> wrote:
>> I'll look at it but possibly not until the weekend.
>
> I checked it into hjl/x32/syscall branch at
>
> http://git.kernel.org/?p=linux/kernel/git/hjl/linux
On Sun, May 22, 2011 at 1:02 PM, H.J. Lu wrote:
> On Sat, May 21, 2011 at 4:48 PM, H.J. Lu wrote:
>> On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter
>> wrote:
>>> I'll look at it but possibly not until the weekend.
>>
>> I checked it into hjl/x32/sysc
Hi Jason,
There is a strange git commit on master branch:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6681e82c16913119b6a3ca0052efe9259d7377a9
in git mit mirror, which isn't in svn gcc trunk. Can you look at a look at it?
Thanks.
--
H.J.
/gofrontend/unsafe.cc.merge-right.r172891
trunk/gcc/go/gofrontend/unsafe.cc.working
Can you fix it?
Thanks.
H.J.
On Sun, Jun 5, 2011 at 12:17 PM, H.J. Lu wrote:
> Hi,
>
> Your commit:
>
> http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00145.html
>
> includes some bogus entries:
>
> trunk/gcc/go/gofrontend/expressions.cc.merge-left.r167407
> trunk/gcc/go/gofrontend/expr
.
3. binutils-2.21.52.0.1.ia64.tar.bz2. IA-64 binary tar ball for RedHat
EL 5.
4. binutils-2.21.52.0.1.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
06/08/2011
EL 5.
3. binutils-2.21.52.0.2.ia64.tar.bz2. IA-64 binary tar ball for RedHat
EL 5.
4. binutils-2.21.52.0.2.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
06/08/2011
memory location. The same ia32 binary works on
Fedora 14 under kernel 2.6.35 and failed under Fedora 15 under
kernel 2.6.38.
We also use uninitialized registers on x86-64, but the program
doesn't crash. This bug may also affects C and other languages.
--
H.J.
y, generally, I wonder if replacing lots of
> fprintf calls won't lead to less readable and maintainable
> code, if many of the fprintfs will need to be replaced
> e.g. by two separate calls (one fwrite, one puthexl
> or similar).
>
> Plus, what I said on IRC, regarding transformation
> of fprintf calls to fwrite if there are no %s in
> the format string, we should leave that to the host
> compiler. It actually already does such transformations
> for fprintf, but in this case we have fprintf_unlocked
> due to system.h macros, and that isn't optimized by gcc
> into fwrite_unlocked. That IMHO should be fixed on the
> host gcc side though.
>
We are working on a patch which will improve decimal
itoa by up to 10X. It will take a while to finish it.
--
H.J.
t;
The updated initial x32 patch is at:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01088.html
--
H.J.
On Tue, Jun 14, 2011 at 2:51 PM, wrote:
>
>> We are working on a patch which will improve decimal
>> itoa by up to 10X. It will take a while to finish it.
>
> What's the method?
>
We use SSSE3 and SSE4 instructions for shift and multiply.
--
H.J.
#x27;t make a
>> difference.
>
> It used to make a difference for function value return. But apparently
> we have lost that feature of transparent union somewhere between gcc 2.7.0
> and gcc 4.4.5 .
>
Do you have a testcase for i386?
--
H.J.
On Tue, Jun 14, 2011 at 8:27 PM, Joern Rennecke wrote:
> Quoting "H.J. Lu" :
>
>> Do you have a testcase for i386?
>
> struct args { int i0, i1; };
>
> union args_u { struct args *a; } __attribute__((transparent_union));
>
> union args_u
> f (union arg
On Wed, Jun 15, 2011 at 2:47 PM, Joern Rennecke wrote:
> Quoting "H.J. Lu" :
>
>> On Tue, Jun 14, 2011 at 8:27 PM, Joern Rennecke
>> wrote:
>>>
>>> Quoting "H.J. Lu" :
>>>
>>>> Do you have a testcase for i38
e and I am investigating the 3rd feedback.
I have more middle-end patches.
--
H.J.
platform.
Thanks for your time.
--
H.J.
On Wed, Jun 22, 2011 at 3:25 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> Apparently, there is no GCC maintainer for Linux/x86 platform. I have
>> been working on GCC, as well as binutils and C libraries, for Linux/x86
>> over 20 years. I ported GCC, b
g. X32 will solve PIE/PIC problem.
--
H.J.
Hi,
I haven't used my gnu.org account for a long time, h...@gnu.org. I can't log in
nor my email forward doesn't work either.
--
H.J.
On Fri, Jul 15, 2011 at 11:57 AM, Andreas Schwab wrote:
> Ian Lance Taylor writes:
>
>> "H.J. Lu" writes:
>>
>>> I haven't used my gnu.org account for a long time, h...@gnu.org. I can't
>>> log in
>>> nor my email for
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/17/2011
): Add $(POSTSTAGE1_CONFIGURE_FLAGS).
>> * configure, Makefile.in: Rebuild.
>
>
> I got agreement from two global reviewers and no objections.
>
> I have committed this patch.
>
> Please let me know about any problems.
It caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49787
--
H.J.
On Tue, Jul 19, 2011 at 5:26 PM, H.J. Lu wrote:
> On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor wrote:
>> Ian Lance Taylor writes:
>>
>>> I would like to propose this patch as a step toward building gcc using a
>>> C++ compiler. This patch builds st
>
> If anybody doesn't like that idea, we can simply add a flags2 field and
> a pta_flags2 enum with PTA2_xxx constants.
>
Hi,
We are also running out of bits in ix86_isa_flags. This patch uses
int64 on both ix86_isa_flags and PTA. I added a new option to opt:
; Maximum number
On Wed, Jul 27, 2011 at 10:00 AM, Uros Bizjak wrote:
> On Wed, Jul 27, 2011 at 6:42 PM, H.J. Lu wrote:
>
>>>> As you may see pta_flags enum in i386.c is almost full. So there is a
>>>> risk of overflow in quite near future. Comment in source code advises
>>
On Wed, Jul 27, 2011 at 2:23 PM, Joseph S. Myers
wrote:
> On Wed, 27 Jul 2011, H.J. Lu wrote:
>
>> ; Maximum number of mask bits in a variable.
>> MaxMaskBits
>> ix86_isa_flags = 64
>>
>> It mark ix86_isa_flags as 64bit. Any comments?
>
> The patch
On Wed, Jul 27, 2011 at 2:37 PM, H.J. Lu wrote:
> On Wed, Jul 27, 2011 at 2:23 PM, Joseph S. Myers
> wrote:
>> On Wed, 27 Jul 2011, H.J. Lu wrote:
>>
>>> ; Maximum number of mask bits in a variable.
>>> MaxMaskBits
>>> ix86_isa_flags = 64
>>&
specific ones. X32 specific system call slots start at 512.
3. All x32 system call numbers have the bit 30 set.
Gibc x32 binary rpms for Fedora 15/x86-64 are available from
the x32 website. People can try out x32 on Fedora 15.
Thanks.
--
H.J.
I am checking the follow patch
into x32 psABI to allow R_X86_64_64.
--
H.J.
diff --git a/object-files.tex b/object-files.tex
index 3c9b9c6..7f0fd14 100644
--- a/object-files.tex
+++ b/object-files.tex
@@ -451,7 +451,7 @@ or \texttt{Elf32_Rel} relocation.
\multicolumn{1}{c}{Calcul
../gcc/configure --prefix=/tmp/lto --enable-languages=c++
> --with-build-config=bootstrap-lto --with-gnu-ld --disable-multilib
> --disable-nls --with-arch=native --with-tune=native && \
>
I checked in this as an obvious fix.
Thanks.
--
H.J.
---Index: ChangeLog
On Wed, Jul 27, 2011 at 2:23 PM, Joseph S. Myers
wrote:
> On Wed, 27 Jul 2011, H.J. Lu wrote:
>
>> ; Maximum number of mask bits in a variable.
>> MaxMaskBits
>> ix86_isa_flags = 64
>>
>> It mark ix86_isa_flags as 64bit. Any comments?
>
> The patch
On Thu, Aug 4, 2011 at 11:08 AM, H.J. Lu wrote:
> On Wed, Jul 27, 2011 at 2:23 PM, Joseph S. Myers
> wrote:
>> On Wed, 27 Jul 2011, H.J. Lu wrote:
>>
>>> ; Maximum number of mask bits in a variable.
>>> MaxMaskBits
>>> ix86_isa_flags = 64
>>&
On Thu, Aug 4, 2011 at 3:46 PM, Joseph S. Myers wrote:
> On Thu, 4 Aug 2011, H.J. Lu wrote:
>
>> Here is the updated patch to get proper HOST_WIDE_INT bits and 1
>> through a new file, opt-gen.c. OK for trunk?
>
> Using another generator program like this can't be th
On Thu, Aug 4, 2011 at 4:44 PM, H.J. Lu wrote:
> On Thu, Aug 4, 2011 at 3:46 PM, Joseph S. Myers
> wrote:
>> On Thu, 4 Aug 2011, H.J. Lu wrote:
>>
>>> Here is the updated patch to get proper HOST_WIDE_INT bits and 1
>>> through a new file, opt-gen.c. OK for
-32 binary tar ball for RedHat
EL 5.
3. binutils-2.21.53.0.2.ia64.tar.bz2. IA-64 binary tar ball for RedHat
EL 5.
4. binutils-2.21.53.0.2.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/dev
Ping. AVX2 support depends on this patch.
Thanks.
On Thu, Aug 4, 2011 at 5:49 PM, H.J. Lu wrote:
> On Thu, Aug 4, 2011 at 4:44 PM, H.J. Lu wrote:
>> On Thu, Aug 4, 2011 at 3:46 PM, Joseph S. Myers
>> wrote:
>>> On Thu, 4 Aug 2011, H.J. Lu wrote:
>>>
>
On Sat, Aug 6, 2011 at 9:05 AM, H.J. Lu wrote:
> Ping. AVX2 support depends on this patch.
>
> Thanks.
>
> On Thu, Aug 4, 2011 at 5:49 PM, H.J. Lu wrote:
>> On Thu, Aug 4, 2011 at 4:44 PM, H.J. Lu wrote:
>>> On Thu, Aug 4, 2011 at 3:46 PM, Joseph S. Myers
>
v %esi, %eax
> movq (%rax), %rcx
> movq 8(%rax), %rbx
> addq $1, %rcx
> adcq $0, %rbx
> sall $4, %edx
> movq %rcx, (%rax)
> movq %rbx, 8(%rax)
> movdqa %xmm0, (%edx,%esi)
> popq %rbx
> .cfi_def_cfa_offset 8
> ret
>
> H.J., can you please test attached patch? This optimization won't
> trigger on x86_64 anymore.
>
I will test it.
Thanks.
--
H.J.
Is this OK for trunk?
On Sun, Aug 7, 2011 at 7:18 PM, H.J. Lu wrote:
> On Sat, Aug 6, 2011 at 9:05 AM, H.J. Lu wrote:
>> Ping. AVX2 support depends on this patch.
>>
>
>>> ---
>>> 2011-08-04 H.J. Lu
>>> Igor Zamyatin
&g
On Tue, Aug 9, 2011 at 7:06 AM, Joseph S. Myers wrote:
> On Tue, 9 Aug 2011, H.J. Lu wrote:
>
>> Is this OK for trunk?
>
> No. You don't need to ping so often; I'll look at it in due course once
> sufficient time has passed since the last posted revision (if a pat
e-word moves from/to non-offsetable addresses instead of
> generating XMM temporary.
>
> Re-bootstrapped and re-tested on x86_64-pc-linux-gnu {,-m32}.
>
No regressions on x32 with GCC, glibc and SPEC CPU 2K/2006.
Thanks.
--
H.J.
On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote:
> Hi,
>
> It turns out that x32 needs R_X86_64_64. One major reason is
> the displacement range of x32 is -2G to +2G. It isn't a problem
> for compiler since only small model is required for x32.
>
> However, to address 0
On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote:
>>>> On 12.08.11 at 06:37, "H.J. Lu" wrote:
>> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote:
>>> Hi,
>>>
>>> It turns out that x32 needs R_X86_64_64. One major reason is
>>>
On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich wrote:
>>>> On 12.08.11 at 14:09, "H.J. Lu" wrote:
>> On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote:
>>>>>> On 12.08.11 at 06:37, "H.J. Lu" wrote:
>>>> On Mon, Aug 1, 2011 at
On Fri, Aug 12, 2011 at 6:59 AM, Jan Beulich wrote:
>>>> On 12.08.11 at 15:22, "H.J. Lu" wrote:
>> On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich wrote:
>>>>>> On 12.08.11 at 14:09, "H.J. Lu" wrote:
>>>> On Fri, Aug 12, 2011
On Fri, Aug 12, 2011 at 8:17 AM, Jan Beulich wrote:
>>>> On 12.08.11 at 16:47, "H.J. Lu" wrote:
>> On Fri, Aug 12, 2011 at 7:42 AM, Jan Beulich wrote:
>>>>>> On 12.08.11 at 16:02, "H.J. Lu" wrote:
>>>> On Fri, Aug 12, 2011 at
On Fri, Aug 12, 2011 at 8:52 AM, H.J. Lu wrote:
> On Fri, Aug 12, 2011 at 8:17 AM, Jan Beulich wrote:
>>>>> On 12.08.11 at 16:47, "H.J. Lu" wrote:
>>> On Fri, Aug 12, 2011 at 7:42 AM, Jan Beulich wrote:
>>>>>>> On 12.08.11 at 16:02, &q
On Fri, Aug 12, 2011 at 10:53 AM, H.J. Lu wrote:
> On Fri, Aug 12, 2011 at 8:52 AM, H.J. Lu wrote:
>> On Fri, Aug 12, 2011 at 8:17 AM, Jan Beulich wrote:
>>>>>> On 12.08.11 at 16:47, "H.J. Lu" wrote:
>>>> On Fri, Aug 12, 2011 at 7:42 AM, Jan Be
Hi,
I checked this into cilkplus branch. Jason, can you also mirror
branches/cilkplus in GCC git mirror?
Thanks.
H.J.
On Mon, Aug 15, 2011 at 1:30 PM, Iyer, Balaji V wrote:
> Hello Everyone,
> This letter describes the recently created GCC branch called "cilkplus"
On Tue, Aug 9, 2011 at 7:06 AM, Joseph S. Myers wrote:
> On Tue, 9 Aug 2011, H.J. Lu wrote:
>
>> Is this OK for trunk?
>
> No. You don't need to ping so often; I'll look at it in due course once
> sufficient time has passed since the last posted revision (if a pat
On Wed, Aug 17, 2011 at 12:28 PM, Joseph S. Myers
wrote:
> On Sun, 7 Aug 2011, H.J. Lu wrote:
>
>> HOST_BITS_PER_WIDE_INT isn't defined in target library.
>> I need to check if HOST_BITS_PER_WIDE_INT is defined
>> first. Here is the updated patch.
>
> As I said
On Wed, Aug 17, 2011 at 1:35 PM, Joseph S. Myers
wrote:
> On Wed, 17 Aug 2011, H.J. Lu wrote:
>
>> On Wed, Aug 17, 2011 at 12:28 PM, Joseph S. Myers
>> wrote:
>> > On Sun, 7 Aug 2011, H.J. Lu wrote:
>> >
>> >> HOST_BITS_PER_WIDE_INT isn'
Since -Wmissing-prototypes doesn't work for C++, using
C++ to bootstrap GCC makes -Wmissing-prototypes useless.
You will see the -Wmissing-prototypes message in stage 1,
but you won't see it in stage3 2/3.
--
H.J.
gt; does it mean to make -Wmissing-prototypes useless?
>
>
> From: gcc-ow...@gcc.gnu.org [gcc-ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> [hjl.to...@gmail.com]
> Sent: Friday, August 19, 2011 9:36 AM
> To: GCC Development
> Subject: Boo
the intended result.
G++ doesn't give a warning at all:
[hjl@gnu-33 gcc]$ cat x.c
int
foo (int x)
{
return x;
}
[hjl@gnu-33 gcc]$ ./g++ -B./ -Wall -S -O x.c
[hjl@gnu-33 gcc]$
> paul
>
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu
On Fri, Aug 19, 2011 at 2:45 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> [hjl@gnu-33 gcc]$ cat x.c
>> int
>> foo (int x)
>> {
>> return x;
>> }
>> [hjl@gnu-33 gcc]$ ./xgcc -B./ -S -O -Wmissing-prototypes x.c
>> x.c:2:1
mbly codes are very close to x86-64 ones. In come cases,
they are 100% compatible.
In kernel, x32 vDSO is built from the x86-64 .o files for x86-64 vDSO.
In gmp, you can assemble x86-64 assembly codes directly into x32
object files. Adding x32 target triplet may not be necessarily helpful.
--
H.J.
x64. Indirect
> branch would be used in assembly code (yeah, concrete example would
> valuable here but indirect branch should be used potentially and
> possibly in assembly code.) If the assembly code use indirect branch,
> it needs to know the target ABI and generate/use difference code path.
>
In assembly codes, most, if not all, of x86-64 indirect branch work fine for x32
--
H.J.
On Mon, Oct 3, 2011 at 8:44 PM, Michael LIAO wrote:
> On Mon, Oct 3, 2011 at 5:53 PM, H.J. Lu wrote:
>> On Mon, Oct 3, 2011 at 4:47 PM, Michael LIAO wrote:
>>> On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger wrote:
>>>> On Monday, October 03, 2011 18:57:28 Michae
o mutlilib just like glibc,
> that new triplet will simiplifies their decision.
>
> gcc definitely is not that kind of package as it could be built to
> support generate x86-64, x32 and i386 code with the same package and
> need a runtime option to tell that.
>
I see 3 separate issues:
1. The file name of an x32 binary package needs to be marked as x32.
2. Compilers need a switch to generate x32 code.
3. We need to configure a software package for x32.
Which problem are you trying to resolve? Please explain yours
if it isn't covered above.
--
H.J.
with -print-prog-name=$LTOPLUGINSONAM to get
plugin name.
Any comments?
--
H.J.
301 - 400 of 1206 matches
Mail list logo
