I just found a behavior change of driver on multiple input assembly
files. Previously (before r164357), for the command line
gcc -o t t1.s t2.s
, the driver will call assembler twice, once for t1.s and once for t2.s.
After r164357, the driver will only call assembler once for t1.s and
t2.s. T
Apologies if you receive multiple copies of this call.
CALL FOR PAPERS
5th Workshop on
Statistical and Machine learning approaches
On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin wrote:
> On 12/30/2010 01:08 PM, Robert Millan wrote:
>> Hi folks,
>>
>> I had this unsubmitted patch in my local filesystem. It makes Linux
>> detect ELF32 AMD64 binaries and sets a flag to restrict them to
>> 32-bit address space.
>>
>> It's not r
On 12/30/2010 01:08 PM, Robert Millan wrote:
> Hi folks,
>
> I had this unsubmitted patch in my local filesystem. It makes Linux
> detect ELF32 AMD64 binaries and sets a flag to restrict them to
> 32-bit address space.
>
> It's not rocket science but can save you some work in case you
> haven't
On Thu, Dec 30, 2010 at 4:25 PM, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 3:00 PM, Joseph S. Myers
> wrote:
>> On Thu, 30 Dec 2010, H. Peter Anvin wrote:
>>
>>> On 12/30/2010 02:21 PM, Robert Millan wrote:
>>> > 2010/12/30 Richard Guenther :
>>> >> Would be nice if LFS would be mandatory on the n
On Thu, Dec 30, 2010 at 3:00 PM, Joseph S. Myers
wrote:
> On Thu, 30 Dec 2010, H. Peter Anvin wrote:
>
>> On 12/30/2010 02:21 PM, Robert Millan wrote:
>> > 2010/12/30 Richard Guenther :
>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>> >> off_t being 64bits.
>> >
>> > Please do
On Thu, 30 Dec 2010 18:40:35 -0500
Jack Howarth wrote:
> Sebastian,
> It appears that the official tarballs are now posted at
> http://www.cloog.org/
> for cloog and cloog-parma 0.16. Do you plan on placing those both in the
> infrastructure
> directory at gcc.gnu.org's ftp site? If so, the
Sebastian,
It appears that the official tarballs are now posted at
http://www.cloog.org/
for cloog and cloog-parma 0.16. Do you plan on placing those both in the
infrastructure
directory at gcc.gnu.org's ftp site? If so, the newer ppl 0.11 tarball should
be added
as well. If those files are
On Thu, 30 Dec 2010, H. Peter Anvin wrote:
> On 12/30/2010 02:21 PM, Robert Millan wrote:
> > 2010/12/30 Richard Guenther :
> >> Would be nice if LFS would be mandatory on the new ABI, thus
> >> off_t being 64bits.
> >
> > Please do also consider time_t.
> >
>
> Changing the kernel-facing time_
Snapshot gcc-4.5-20101230 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101230/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 12/30/2010 02:21 PM, Robert Millan wrote:
> 2010/12/30 Richard Guenther :
>> Would be nice if LFS would be mandatory on the new ABI, thus
>> off_t being 64bits.
>
> Please do also consider time_t.
>
Changing the kernel-facing time_t might completely wreck the reuse of
the i386 kernel ABI; I'm
On 12/30/2010 02:18 PM, Robert Millan wrote:
> 2010/12/30 H.J. Lu :
>> I also have a patch for gcc 4.4 which works on simple codes.
>>
>> H.J.
>> On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin wrote:
>>> We do have a slightly more extensive patch already implemented.
>
> Could you make those pat
On Thu, Dec 30, 2010 at 2:18 PM, Robert Millan wrote:
> 2010/12/30 H.J. Lu :
>> I also have a patch for gcc 4.4 which works on simple codes.
>>
>> H.J.
>> On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin wrote:
>>> We do have a slightly more extensive patch already implemented.
>
> Could you make
2010/12/30 Richard Guenther :
> Would be nice if LFS would be mandatory on the new ABI, thus
> off_t being 64bits.
Please do also consider time_t.
--
Robert Millan
2010/12/30 H.J. Lu :
> I also have a patch for gcc 4.4 which works on simple codes.
>
> H.J.
> On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin wrote:
>> We do have a slightly more extensive patch already implemented.
Could you make those patches available somewhere? It'd be
interesting to play w
On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>>
>> Would be nice if LFS would be mandatory on the new ABI, thus
>> off_t being 64bits.
>
> And avoid ambiguous cases that x86-64 ABI has, e.g. whether
> caller or callee is responsible for sign/zero extension of arguments, to
> avoid the need to sign
On 12/30/2010 12:39 PM, David Daney wrote:
>
> Really I don't care one way or the other. The necessity of syscall
> wrappers is actually probably beneficial to me. It will create a
> greater future employment demand for people with the necessary skills to
> write them.
>
Or perhaps automatic g
I also have a patch for gcc 4.4 which works on simple codes.
H.J.
On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin wrote:
> We do have a slightly more extensive patch already implemented.
>
> "Robert Millan" wrote:
>
>>Hi folks,
>>
>>I had this unsubmitted patch in my local filesystem. It makes
We do have a slightly more extensive patch already implemented.
"Robert Millan" wrote:
>Hi folks,
>
>I had this unsubmitted patch in my local filesystem. It makes Linux
>detect ELF32 AMD64 binaries and sets a flag to restrict them to
>32-bit address space.
>
>It's not rocket science but can sav
I believe it covers all cases *relevant for this particular situation* (unlike,
say, MIPS) and that any deviation is a bug which can and should be fixed.
"David Daney" wrote:
>On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
>> On 12/30/2010 11:34 AM, David Daney wrote:
>>>
>>> My suggestion: Sin
Hi folks,
I had this unsubmitted patch in my local filesystem. It makes Linux
detect ELF32 AMD64 binaries and sets a flag to restrict them to
32-bit address space.
It's not rocket science but can save you some work in case you
haven't implemented this already.
Best regards
--
Robert Millan
di
On 12/30/2010 12:28 PM, H.J. Lu wrote:
On Thu, Dec 30, 2010 at 12:27 PM, David Daney wrote:
On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
On 12/30/2010 11:34 AM, David Daney wrote:
My suggestion: Since people already spend a great deal of effort
maintaining the existing i386 compatible Lin
On Thu, 30 Dec 2010, Richard Guenther wrote:
> Would be nice if LFS would be mandatory on the new ABI, thus
> off_t being 64bits.
That's certainly abstractly better (and something BSDs do better than
GNU/Linux). I expect you'd run into a few complications actually making a
32-bit glibc port li
On Thu, Dec 30, 2010 at 12:27 PM, David Daney wrote:
> On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
>>
>> On 12/30/2010 11:34 AM, David Daney wrote:
>>>
>>> My suggestion: Since people already spend a great deal of effort
>>> maintaining the existing i386 compatible Linux syscall infrastructure,
On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
On 12/30/2010 11:34 AM, David Daney wrote:
My suggestion: Since people already spend a great deal of effort
maintaining the existing i386 compatible Linux syscall infrastructure,
make your new 32-bit x86-64 Linux syscall ABI identical to the existi
On Thu, Dec 30, 2010 at 12:02 PM, H.J. Lu wrote:
>
> Here is the ILP32 psABI:
>
> http://www.kernel.org/pub/linux/devel/binutils/ilp32/
>
I put my x86-64 psABI changes at:
http://git.kernel.org/?p=devel/binutils/hjl/x86-64-psabi.git;a=summary
Please send me patches to improve the ILP32 psABI.
On 12/30/2010 11:34 AM, David Daney wrote:
>
> My suggestion: Since people already spend a great deal of effort
> maintaining the existing i386 compatible Linux syscall infrastructure,
> make your new 32-bit x86-64 Linux syscall ABI identical to the existing
> i386 syscall ABI. This means that t
On 12/30/2010 11:53 AM, Richard Guenther wrote:
>
> Would be nice if LFS would be mandatory on the new ABI, thus
> off_t being 64bits.
>
Yes, although that's a higher-order thing.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their beh
On Thu, Dec 30, 2010 at 11:40 AM, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 11:30 AM, Joseph S. Myers
> wrote:
>> On Thu, 30 Dec 2010, H.J. Lu wrote:
>>
>>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>>> wrote:
>>> > On Thu, 30 Dec 2010, H.J. Lu wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> This p
On Thu, Dec 30, 2010 at 08:53:32PM +0100, Richard Guenther wrote:
> > Syscalls sometimes need three different versions in the kernel; sometimes
> > the wrong version gets put in the n32 syscall table. Special syscall
> > wrappers are often needed in glibc; although for most purposes the glibc
> >
On Thu, Dec 30, 2010 at 8:30 PM, Joseph S. Myers
wrote:
> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>> wrote:
>> > On Thu, 30 Dec 2010, H.J. Lu wrote:
>> >
>> >> Hi,
>> >>
>> >> This patch adds 32bit x86-64 support to binutils. Support in compiler,
On Thu, Dec 30, 2010 at 11:30 AM, Joseph S. Myers
wrote:
> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>> wrote:
>> > On Thu, 30 Dec 2010, H.J. Lu wrote:
>> >
>> >> Hi,
>> >>
>> >> This patch adds 32bit x86-64 support to binutils. Support in compiler
On 12/30/2010 10:59 AM, H.J. Lu wrote:
On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
wrote:
On Thu, 30 Dec 2010, H.J. Lu wrote:
Hi,
This patch adds 32bit x86-64 support to binutils. Support in compiler,
library and OS is required to use it. It can be used to implement the
new 32bit OS
On Thu, 30 Dec 2010, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
> wrote:
> > On Thu, 30 Dec 2010, H.J. Lu wrote:
> >
> >> Hi,
> >>
> >> This patch adds 32bit x86-64 support to binutils. Support in compiler,
> >> library and OS is required to use it. It can be used to impl
On 12/30/2010 10:59 AM, H.J. Lu wrote:
>
>> (If you could arrange for the syscall ABI always to be the same as the
>> existing 64-bit ABI, rather than needing to handle three different syscall
>> ABIs in the kernel, that might be one solution, but it could have its own
>> complexities in ensuring
On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
wrote:
> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> Hi,
>>
>> This patch adds 32bit x86-64 support to binutils. Support in compiler,
>> library and OS is required to use it. It can be used to implement the
>> new 32bit OS for x86-64. Any comments?
On Thu, 30 Dec 2010, H.J. Lu wrote:
> Hi,
>
> This patch adds 32bit x86-64 support to binutils. Support in compiler,
> library and OS is required to use it. It can be used to implement the
> new 32bit OS for x86-64. Any comments?
Do you have a public psABI document? I think the psABI at the E
Hello,
The attached patch is my latest attempt to model doloop for arm.
I followed Chung-Lin Tang suggestion and used subs+jump similar to your
patch.
On crotex-A8 I see gain of 29% on autocor benchmark (telecom suite) with
SMS using the following flags: -fmodulo-sched-allow-regmoves
-funsafe-loop
Roman Zhuykov wrote:
> Memory is used instead of a register to store doloop counter.
Yes, this can happen, and your doloop insn pattern *must* be
able to handle this. This is usually done via a splitter
(and possibly an additional scratch register allocated via
an extra insn operand). See vario
Hello!
The main idea of the work described below was to estimate speedup we can
gain from SMS on ARM. SMS depends on doloop_end pattern and there is no
appropriate instruction on ARM. We decided to create a "fake"
doloop_end pattern on ARM using a pair of "subs" and "bne" assembler
instruct
40 matches
Mail list logo
