On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov wrote:
> I can not reproduce the problem. It would be nice to give all info (the
> code without includes and all options). In this case I could have more info
> to say more definitely about the reason of the problem in IRA.
>
One of the issue wi
On Thu, Aug 11, 2011 at 10:11 AM, Paulo J. Matos wrote:
> On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov wrote:
>> I can not reproduce the problem. It would be nice to give all info (the
>> code without includes and all options). In this case I could have more info
>> to say more definitely
On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov wrote:
> I can not reproduce the problem. It would be nice to give all info (the
> code without includes and all options). In this case I could have more info
> to say more definitely about the reason of the problem in IRA.
>
Let me add another
On 08/08/11 21:35, Jan Hubicka wrote:
>> On Fri, Aug 5, 2011 at 3:24 PM, Jan Hubicka wrote:
>
> In a way I like the current scheme since it is simple and extending it
> should IMO have some good reason. We could refine -Os behaviour without
> changing current predicates to optimize
On Thu, Aug 04, 2011 at 04:05:25PM +0200, Mike Hommey wrote:
> Hi,
>
> We (Mozilla) are trying to get the best of the ARM toolchain for our
> Android build. I recently built an Android Native-code Development Kit
> with GCC 4.6.1 and binutils 2.21.53, instead of GCC 4.4.3 and binutils
> 2.19 that
On 08/11/2011 04:49 AM, Richard Guenther wrote:
On Thu, Aug 11, 2011 at 10:11 AM, Paulo J. Matos wrote:
On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov wrote:
I can not reproduce the problem. It would be nice to give all info (the
code without includes and all options). In this case I cou
Dear gcc developers,
this is about an issue that popped up in a verification project [1] based on
LLVM, but it seems to be already present in the gimple code, before llvm-gcc
transforms the gimple code to LLVM-IR.
In short:
Calculating the difference of two pointers seems to be treated by gcc a
On Thu, Aug 11, 2011 at 5:15 PM, Florian Merz wrote:
> Dear gcc developers,
>
> this is about an issue that popped up in a verification project [1] based on
> LLVM, but it seems to be already present in the gimple code, before llvm-gcc
> transforms the gimple code to LLVM-IR.
>
> In short:
> Calcu
This brings the second part of the streamer refactoring. I'm
going to be doing frequent merges in the next little while to
avoid big conflicts.
Tested on x86_64.
Diego.
Thanks for your reply Richard, but I'm not satisfied with your answer, yet. :-)
If I'm right, then the problem I'm refering to doesn't require large objects.
See below for more.
Am Thursday, 11. August 2011, 17:48:26 schrieb Richard Guenther:
> On Thu, Aug 11, 2011 at 5:15 PM, Florian Merz wrote
On Thu, Aug 11, 2011 at 7:21 AM, Mike Hommey wrote:
> On Thu, Aug 04, 2011 at 04:05:25PM +0200, Mike Hommey wrote:
>> Hi,
>>
>> We (Mozilla) are trying to get the best of the ARM toolchain for our
>> Android build. I recently built an Android Native-code Development Kit
>> with GCC 4.6.1 and binut
Hello all,
I was making some modifications to picochip port and ran into a problem
with cse within reload and I think it is a bug. Can someone familiar
with reload let me know if it is indeed a bug. The c testcase that
caused the problem was
gcc-4.6.0/gcc/testsuite/./gcc.c-torture/execute/9912
On Thu, Aug 11, 2011 at 6:05 PM, Florian Merz wrote:
> Thanks for your reply Richard, but I'm not satisfied with your answer, yet.
> :-)
> If I'm right, then the problem I'm refering to doesn't require large objects.
>
> See below for more.
>
> Am Thursday, 11. August 2011, 17:48:26 schrieb Richa
On Thu, Aug 11, 2011 at 09:05:19AM -0700, Florian Merz wrote:
> If I remember the standard correctly, pointer subtraction is valid if both
> pointers point to elements of the same array or to one past the last element
> of the array. According to this 0x8000 - 0x7FFF should be a valid
>
On Thu, Aug 11, 2011 at 7:13 PM, Joe Buck wrote:
> On Thu, Aug 11, 2011 at 09:05:19AM -0700, Florian Merz wrote:
>> If I remember the standard correctly, pointer subtraction is valid if both
>> pointers point to elements of the same array or to one past the last element
>> of the array. According
Am Thursday, 11. August 2011, 19:15:41 schrieb Richard Guenther:
> On Thu, Aug 11, 2011 at 7:13 PM, Joe Buck wrote:
> > On Thu, Aug 11, 2011 at 09:05:19AM -0700, Florian Merz wrote:
> >> If I remember the standard correctly, pointer subtraction is valid if
> >> both pointers point to elements of t
Jed Davis writes:
>
> But is that the right way to do that, do people think? Or should I
> look into making this its own -mcmodel option? (Which would raise the
I would make it a new -mcmodel=... option.
> question of what to call it -- medsmall? smallhigh? altkernel?) Or is
smallhigh sounds
On Thu, 11 Aug 2011, Richard Guenther wrote:
> int x,y;
> int main ()
> {
> char *a, *b;
> __INTPTR_TYPE__ w;
> if (x)
> a = 0x7ffe;
> else
> a = 0x7fff;
> if (y)
> b = 0x8001;
> else
> b = 0x8000;
> w = b - a;
> return w;
> }
>
> indeed traps with
On Thu, Aug 11, 2011 at 12:15 PM, Richard Guenther
wrote:
> On Thu, Aug 11, 2011 at 7:13 PM, Joe Buck wrote:
>> On Thu, Aug 11, 2011 at 09:05:19AM -0700, Florian Merz wrote:
>>> If I remember the standard correctly, pointer subtraction is valid if both
>>> pointers point to elements of the same a
On Thu, Aug 11, 2011 at 1:58 PM, Joseph S. Myers
wrote:
> -ftrapv and -fwrapv should have no effect on pointer subtraction.
Yes!
-- Gaby
On Thu, Aug 11, 2011 at 1:58 PM, Joseph S. Myers
wrote:
> -ftrapv and -fwrapv should have no effect on pointer subtraction.
Gaby writes:
> Yes!
Wouldn't it suffice to convert the pointers to unsigned, do an unsigned
subtraction, and then convert the result to signed? This would then guarantee
Snapshot gcc-4.5-20110811 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110811/
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 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 to 4G directly in assembly
Hello All,
I am working on 32-bit target with gcc 4.6.0. I need some help on the following:
For my target, If my CCR register is set, all the arithmetic
instructions update the CC register else the don't update.
Setting the CCR register is done by a built-in function.
Can any one help how to pro
24 matches
Mail list logo
