On 26/10/11 12:19, Richard Guenther wrote:
On Tue, Oct 25, 2011 at 2:22 PM, Tom de Vries tom_devr...@mentor.com wrote:
On 09/24/2011 01:42 PM, Richard Guenther wrote:
On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard
* expr.c (get_object_or_type_alignment): Remove static.
* expr.h (get_object_or_type_alignment): Declare.
I did that this morning (and also added an assertion in the function).
--
Eric Botcazou
On Tue, Oct 25, 2011 at 2:22 PM, Tom de Vries tom_devr...@mentor.com wrote:
On 09/24/2011 01:42 PM, Richard Guenther wrote:
On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
In the end I'd probably say the
On 09/24/2011 01:42 PM, Richard Guenther wrote:
On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
In the end I'd probably say the patch is ok without the option (thus
turned on by default), but if
On Wed, Oct 19, 2011 at 1:58 AM, Maxim Kuvyrkov ma...@codesourcery.com wrote:
On 29/09/2011, at 10:23 PM, Richard Guenther wrote:
On Thu, Sep 29, 2011 at 10:27 AM, Tom de Vries tom_devr...@mentor.com
wrote:
+ SSA_NAME_IS_DEFAULT_DEF (expr)
+ TREE_CODE (var) ==
On 29/09/2011, at 10:23 PM, Richard Guenther wrote:
On Thu, Sep 29, 2011 at 10:27 AM, Tom de Vries tom_devr...@mentor.com wrote:
+ SSA_NAME_IS_DEFAULT_DEF (expr)
+ TREE_CODE (var) == PARM_DECL
+ POINTER_TYPE_P (TREE_TYPE (var))
+
On 09/29/2011 12:21 AM, Tom de Vries wrote:
On 09/24/2011 11:31 AM, Richard Guenther wrote:
On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries vr...@codesourcery.com wrote:
Hi Richard,
I have a patch for PR43814. It introduces an option that assumes that
function
arguments of pointer type are
On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
There is nothing like very likely aligned ;) Note that what is new is
On non-strict aligned targets there is no reason not to have something like
very
On Thu, Sep 29, 2011 at 11:11:12AM +0200, Richard Guenther wrote:
On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
There is nothing like very likely aligned ;) Note that what is new is
On non-strict
On Thu, Sep 29, 2011 at 10:27 AM, Tom de Vries tom_devr...@mentor.com wrote:
On 09/29/2011 12:21 AM, Tom de Vries wrote:
On 09/24/2011 11:31 AM, Richard Guenther wrote:
On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries vr...@codesourcery.com
wrote:
Hi Richard,
I have a patch for PR43814. It
On Thu, Sep 29, 2011 at 11:20 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Sep 29, 2011 at 11:11:12AM +0200, Richard Guenther wrote:
On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
There is nothing
On Thu, Sep 29, 2011 at 12:51 PM, Bernd Schmidt ber...@codesourcery.com wrote:
On 09/29/11 11:26, Richard Guenther wrote:
Maybe that was the PR the patch is about, but surely we can't treat
a memcpy (p, ..) like *p. Which means we'd use the declared type
of p only. And we can do so only for
Hi Tom
What's the behavior of your patch to the following case
typedef int int_unaligned __attribute__((aligned(1)));
int foo (int_unaligned *p)
{
return *p;
}
thanks
Carrot
On Tue, Sep 20, 2011 at 7:13 PM, Tom de Vries vr...@codesourcery.com wrote:
Hi Richard,
I have a patch for PR43814.
On 09/28/2011 03:57 PM, Carrot Wei wrote:
Hi Tom
What's the behavior of your patch to the following case
typedef int int_unaligned __attribute__((aligned(1)));
int foo (int_unaligned *p)
{
return *p;
}
I modified the example slightly:
test.c:
...
typedef int
On 24/09/2011, at 9:40 PM, Jakub Jelinek wrote:
On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
In the end I'd probably say the patch is ok without the option (thus
turned on by default), but if LC_GLOBAL_LOCALE is part of the
glibc ABI then we clearly can't do this.
Yes,
On 29/09/2011, at 7:35 AM, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:29:12 +1300
GLIBC patch to fix locale_t definition is attached.
Isn't this going to result in byte loads being used to dereference
all locale_t pointers on targets like
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:40:55 +1300
On 29/09/2011, at 7:35 AM, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:29:12 +1300
GLIBC patch to fix locale_t definition is attached.
Isn't this going to
On 29/09/2011, at 7:41 AM, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:40:55 +1300
On 29/09/2011, at 7:35 AM, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:29:12 +1300
GLIBC patch to fix locale_t
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:45:17 +1300
OK. Do you have an alternative suggestion that would fix non-portable use of
locale_t?
Don't optimize something that is invalidated by a quite common practice?
What about people who encode invalid pointers
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:58:01 +1300
To summarize, your opinion seems to be to not enable the
optimization by default, correct?
Yes, and I don't think we ever could do so.
BTW, another common paradigm is using the always clear bits of a
pointer to
On Wed, Sep 28, 2011 at 03:00:09PM -0400, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:58:01 +1300
To summarize, your opinion seems to be to not enable the
optimization by default, correct?
Yes, and I don't think we ever could do so.
BTW,
On Wed, Sep 28, 2011 at 9:13 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Sep 28, 2011 at 03:00:09PM -0400, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:58:01 +1300
To summarize, your opinion seems to be to not enable the
optimization by
On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
There is nothing like very likely aligned ;) Note that what is new is
On non-strict aligned targets there is no reason not to have something like
very likely aligned. You would expand stores/loads as if it was aligned
in that
On Sep 20, 2011, at 4:13 AM, Tom de Vries wrote:
I have a patch for PR43814. It introduces an option that assumes that function
arguments of pointer type are aligned, and uses that information in
tree-ssa-ccp. This enables the memcpy in pr43814-2.c to be inlined.
I'm not a huge fan of an
On 09/24/2011 11:31 AM, Richard Guenther wrote:
On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries vr...@codesourcery.com wrote:
Hi Richard,
I have a patch for PR43814. It introduces an option that assumes that
function
arguments of pointer type are aligned, and uses that information in
From: Mike Stump mikest...@comcast.net
Date: Wed, 28 Sep 2011 15:19:10 -0700
If Android is safe in this respect, then, they can just turn it on,
and then force anyone porting software to their platform to `fix'
their code.
They'd have to then know to turn this option off when building the
On Wed, Sep 28, 2011 at 06:43:04PM -0400, David Miller wrote:
From: Mike Stump mikest...@comcast.net
Date: Wed, 28 Sep 2011 15:19:10 -0700
If Android is safe in this respect, then, they can just turn it on,
and then force anyone porting software to their platform to `fix'
their code.
On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries vr...@codesourcery.com wrote:
Hi Richard,
I have a patch for PR43814. It introduces an option that assumes that function
arguments of pointer type are aligned, and uses that information in
tree-ssa-ccp. This enables the memcpy in pr43814-2.c to be
On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
In the end I'd probably say the patch is ok without the option (thus
turned on by default), but if LC_GLOBAL_LOCALE is part of the
glibc ABI then we clearly can't do this.
Yes, LC_GLOBAL_LOCALE is part of glibc ABI. I guess we
On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
In the end I'd probably say the patch is ok without the option (thus
turned on by default), but if LC_GLOBAL_LOCALE is part of the
glibc ABI then we clearly
Hi Richard,
I have a patch for PR43814. It introduces an option that assumes that function
arguments of pointer type are aligned, and uses that information in
tree-ssa-ccp. This enables the memcpy in pr43814-2.c to be inlined.
I tested the patch successfully on-by-default on x86_64 and i686
31 matches
Mail list logo
