Dorit Nuzman wrote:
(would be intereting to see an example for a loop that is now vectorized
and didn't vectorize before, if you have that information available)
Unfortunately not - it caught me by surprise (on a routine recompile /
rerun of a fixed test-case). Otherwise I would at least hav
This proof of concept patch modifies GCC to have 32-bit pointers and
longs on x86-64.
This allows to create an "x86-32" architecture that takes advantage of
the higher number of registers and support for 64-bit computation in
x86-64 long mode while avoiding the disadvantage of increased memory
usa
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> And then, once the underlying problem is addressed and we
Alexandre> have an API that is usable by regular users, maybe we will
Alexandre> find out that we don't need plugins, after all.
Plugins are about deployment, not
Original Message
Subject: Libiberty problem in gcc-4.3 snapshots
Date: Sun, 25 Nov 2007 17:14:47 -0500
From: Andris Pavenis <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Tried to build gcc-4.3-20071123 for DJGPP (native build). Run into a following
lib
Thank you for your reply, Oliver.
Briefly speaking the solution to the problems you have mentioned looks
like this:
1. take a loot at the first picture here:
http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking+how+it+works
2. Pointer 1, 2... are vptrs
3. The idea is that each
bounce
> 7. Add support for loading x86-32 and x86-64 objects in the same
> address space, using a single modified 64-bit libc.
I'm not convinvinced this is practical, or even possible. I'd expect the
restrictions imposed on code to make it work properly to be too onerous for
it to be of any real use.
On 11/25/07, Luca <[EMAIL PROTECTED]> wrote:
> 7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
> to allow 64-bit pointers in 32-bit mode and viceversa
This is already there, try using __attribute__((mode(DI) )).
-- Pinski
Alexandre Oliva wrote:
>> You're again trying to make this a binary-value question. Why?
>
> Because in my mind, when we agree there is a bug, then a fix for it
> can is easier to swallow even if it makes the compiler spend more
> resources, whereas a mere quality-of-implementation issue is subj
Tom Tromey wrote:
"Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> And then, once the underlying problem is addressed and we
Alexandre> have an API that is usable by regular users, maybe we will
Alexandre> find out that we don't need plugins, after all.
Plugin
-Wtype-limits guards a very useful, in my experience, set of warnings
including the following:
warning: comparison of unsigned expression < 0 is always false
warning: comparison of unsigned expression >= 0 is always true
Based on these I identified and fixed several real bugs in Wine so far
a
On 26/11/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
>
> So, I got a "creative" idea. What if we disable this warning if comparing
> against 0U instead of 0? Then we could use #define DEFINE_FIRST 0U and
> avoid the warning for cases like this, without losing real diagnostics
> assuming that
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| -Wtype-limits guards a very useful, in my experience, set of warnings
| including the following:
|
| warning: comparison of unsigned expression < 0 is always false
| warning: comparison of unsigned expression >= 0 is always true
|
| Based on these
On Wed, Nov 21, 2007 at 06:32:22PM -0500, Geert Bosch wrote:
> Richard, for the help). However, we're not quite sure if this is
> right. If you or other ARM-knowledgeable people have any feedback,
> that would be most welcome. I'll then make an updated patch against
> head and submit for review a
I like option B. It will be very helpful to reduce software product development
time. Some software product just release with -O0 because they are not
confident releasing a version differ to the one they were debugging and testing
in.
Also in some systems -O0 simply doesn't work, which is too
Saturday 24 November 2007 Tarihinde 03:44:04 yazmıştı:
> Hi all,
>
> I am trying to bootstrap gcc with the following config :
>
> ../configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.3.0
> --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include
> --datadir=/usr/share/gcc/i686-pc-linux
On Nov 24, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
> No, hashing is fine, but doing walks over a hashtable when your algorithm
> depends on ordering is not.
Point.
> I have patches to fix the instance of walking over all referenced
> vars. Which is in the case of UIDs using bitmaps
17 matches
Mail list logo
