On Mon, Aug 8, 2011 at 7:11 PM, Uros Bizjak wrote:
>> Moves are special as far as reload is concerned. If there is already
>> a move instruction present *before* reload, it will get fixed up
>> according to its constraints as any other instruction.
>>
>> However, reload will *introduce* new move
Ayal Zaks writes:
>> (FWIW, libav did show up extra differences when using the patch
>> that I'd originally submitted. They were due to the count_preds
>> and count_succs thing that you picked up in your review.)
>
>
> (These differences had no noticable consequences performance-wise, right?)
We
This merge brings in Gab's trunk changes to line_map and my
refactoring of the streaming code. It also allows us to
use C++ for the implementation (with the same caveats we have in
trunk, the code must be ifdef'd to build with both C and C++
compilers).
I will continue the next phase of the strea
On Mon, Aug 08, 2011 at 05:25:23PM +0100, Jonathan Wakely wrote:
> On 8 August 2011 13:20, Mike Hommey wrote:
> >
> > I unfortunately hit several problems with gcc 4.7 (latest snapshot).
> > One is bug 50022 that I filed today.
> >
> > Another is the following error in stlport headers:
> > error:
On 9 August 2011 13:57, Mike Hommey wrote:
> On Mon, Aug 08, 2011 at 05:25:23PM +0100, Jonathan Wakely wrote:
>> On 8 August 2011 13:20, Mike Hommey wrote:
>> >
>> > I unfortunately hit several problems with gcc 4.7 (latest snapshot).
>> > One is bug 50022 that I filed today.
>> >
>> > Another is t
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
>>>
>>> * hwint.h (HOST_WIDE_INT_1): New.
>>>
>>>
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 patch
keeps getting new versions posted, I consider that evidence that I should
wait a while befor
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 patch
> keeps getting new versions p
Georg-Johann Lay wrote:
> Ulrich Weigand schrieb:
> > It's not a restriction so much, it's simply that TR 18037 does not say
> > anything
> > about string literals at all, so they keep working as they do in standard C.
>
> Take the following bit more elaborate example where you want to describe
On Tue, Aug 9, 2011 at 12:40 AM, Uros Bizjak wrote:
> On Mon, Aug 8, 2011 at 7:11 PM, Uros Bizjak wrote:
>
>>> Moves are special as far as reload is concerned. If there is already
>>> a move instruction present *before* reload, it will get fixed up
>>> according to its constraints as any other i
On 02/08/11 13:22, Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
>> Michael Walle writes:
>> >
>> > Hi,
>> >
>> > > To confirm that try -fno-tree-ter.
>> >
>> > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
>> > assembly code:
Georg-Johann Lay wrote:
> Thanks, it works.
OK, thanks for testing!
> std Y+2,r31 ; 30 *movphi/3 [length = 7]
> std Y+1,r30
I'm actually not seeing those (maybe I'm using a different code
base than you were using ...)
But I still see that the frame is created. The pro
Richard Earnshaw wrote:
> Better still would be to change the specification and implementation of
> local register variables to only guarantee them at the beginning of ASM
> statements. At other times they are simply the same as other local
> variables. Now we have a problem that the register al
On Tue, 9 Aug 2011, Mike Hommey wrote:
This one only happens with using the -std=gnu++0x flag.
The attached preprocessed file builds fine without -std=gnu++0x, and
fails with -std=gnu++0x. Note the same original file didn't fail with
the same stlport and -std=gnu++0x with gcc 4.6.
Shorter:
c
On Mon, Aug 08, 2011 at 02:20:37PM +0200, Mike Hommey wrote:
> I unfortunately hit several problems with gcc 4.7 (latest snapshot).
> One is bug 50022 that I filed today.
>
> Another is the following error in stlport headers:
> error: invalid use of incomplete type 'std::string {aka struct
> s
Hi folks,
Following on from the founding of the cross-distro ARM mailing list,
I'd like to propose an ARM summit at this year's Linux Plumbers
conference [1]. I'm hoping for a slot on Thursday evening, but this
remains to be confirmed at this point.
We had some lively discussion about the state o
On Tue, 9 Aug 2011, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
>
> > Better still would be to change the specification and implementation of
> > local register variables to only guarantee them at the beginning of ASM
> > statements. At other times they are simply the same as other local
> > v
Snapshot gcc-4.4-20110809 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110809/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
The vSphere Hypervisor (ESXi) kernel runs on x86_64 and loads all text
and data sections (for the kernel itself and for modules) within a 2GB
window that lives around virtual address 0x4180 (65.5 TiB).
Thus, 32-bit absolute addresses won't work, but %rip-relative addressing
is fine. Addit
>
> I identified the libstdc++ failure as a problem when building gcc:
>
> configure:16321: /tmp/build-ndk/gcc-4.7.0/./gcc/xgcc
> -shared-libgcc -B/tmp/build-ndk/gcc-4.7.0/./gcc -nostdinc++
> -L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/
> src
> -L/tmp/build-ndk/gcc-4.7.0/arm
On Tue, Aug 9, 2011 at 4:26 PM, Jed Davis wrote:
> The existing workaround, which predates my personal involvement, is to
> use -fPIE together with a -include'd file that uses a #pragma to set the
> default symbol visibility to hidden, which suppresses the PLTness.
> That works on GCC 4.1, but wit
On Tue, 9 Aug 2011, Richard Earnshaw wrote:
> Better still would be to change the specification and implementation of
> local register variables to only guarantee them at the beginning of ASM
> statements.
Only for those asm statements taking the same asm-register
variables as arguments.
> At ot
22 matches
Mail list logo
