> >> > In final value replacement, expression "&a + D." can be
> figured
> >> out,
> >> > while "&a[i_xxx]" failed to be CHRECed, so I'm wondering if we
> should
> >> > lower
> >> > &a[i_xxx] to "&a + unitsize(a) * i_xxx" first? It seems GCC
> intends
> >> to
> >> > keep
> >> > &a[i_xxx] until
On Thu, Jan 5, 2012 at 9:34 AM, Jiangning Liu wrote:
>> >> > In final value replacement, expression "&a + D." can be
>> figured
>> >> out,
>> >> > while "&a[i_xxx]" failed to be CHRECed, so I'm wondering if we
>> should
>> >> > lower
>> >> > &a[i_xxx] to "&a + unitsize(a) * i_xxx" first? It se
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Thursday, January 05, 2012 5:32 PM
> To: Jiangning Liu
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: Re: A case exposing code sink issue
>
> On Thu, Jan 5, 2012 at 9:34 AM, Jiangning Liu
> wrote:
I've been trying off and on for a couple of days to create a machine
description that handles the following target and produces the output I
am hoping for.
The CPU has a 16 bit word size - and only has word size registers. As a
consequence it sign or zero extends when loading byte operands -
Hi,
I just ran into the following gcc build failure during a gcc+glibc build:
...
libtool: compile:
/home/vries/local/glibc-arm/base/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/./gcc/xgcc
-shared-libgcc -B/home/vries/local/glibc-arm/base/obj/\
gcc-mainline-0-arm-none-linux-gnueabi-
Hi,
I'm still developping a new private target backend (gcc4.5.2) and I noticed
something strange in the assembler generated for conditionnal jump.
The compiled C code source is :
void funct (int c) {
int a;
a = 7;
if (c < 0)
a = 4;
return a;
}
The assembler generated i
On Wed, 4 Jan 2012, Xinyu Qi wrote:
> It seems these two parts of the code dealing with BYTE_BIG_ENDIAN will
> cancel each other, and result in the original imm op unchanged.
Yes, that's correct. Lane numbers for NEON intrinsics are the same as
those used in assembly instructions, but for big-
On Thu, 5 Jan 2012, Tom de Vries wrote:
> My hunch is that this recent glibc change causes/triggers the error:
> ...
> [BZ #13528]
> * libio/stdio.h: Do not declare gets for ISO C11 and _GNU_SOURCE.
> ...
>
> I see this both on ARM and MIPS.
>
> Should I file this as a problem in gcc
I'm working on a GCC plugin which performs static analysis of Python
extension code [1]
In various places I need access to a VAR_DECL for various globals from C
code, many of which potentially aren't used directly within the
compilation unit. For example, I may need to reference this global:
e
On Thu, 5 Jan 2012, Joseph S. Myers wrote:
On Thu, 5 Jan 2012, Tom de Vries wrote:
My hunch is that this recent glibc change causes/triggers the error:
...
[BZ #13528]
* libio/stdio.h: Do not declare gets for ISO C11 and _GNU_SOURCE.
...
I see this both on ARM and MIPS.
Shoul
NYC:Moving and other jobs from 19$/hour/men/truck and no hidden fees
Our team of healthy english and russian speaking guys looking for a group or
personal job on own minivans or rented truck
We doing deliveries and any type of movies
>From delivery of a coach to 3 bedroom house relocation
**$19/
On Thu, 5 Jan 2012, Marc Glisse wrote:
Do you have any suggestion on what libstdc++ can do when faced with C
libraries that will randomly declare gets or not depending on flags? It would
need knowledge of these exact flags so it can provide a replacement exactly
when it isn't declared (or at l
On 5 January 2012 16:33, Marc Glisse wrote:
> On Thu, 5 Jan 2012, Joseph S. Myers wrote:
>
>> If the final C++11 still requires gets in , despite it being
>> removed in C11, that's probably also a bug in C++11. (At least the most
>> recent draft I have to hand still has gets in .)
>
>
> It still h
On 05/01/12 18:40, Jonathan Wakely wrote:
> On 5 January 2012 16:33, Marc Glisse wrote:
>> On Thu, 5 Jan 2012, Joseph S. Myers wrote:
>>
>>> If the final C++11 still requires gets in , despite it being
>>> removed in C11, that's probably also a bug in C++11. (At least the most
>>> recent draft I h
BELBACHIR Selim writes:
> How can I tell GCC to perform the best conditionnal jump by sometimes
> reversing the comparison ?
It should work when compiling with -O2. I can't think of anything you
are doing wrong or anything special you should need to do. I think you
will need to debug this. S
On 10/10/2011 08:07 PM, Gabriel Dos Reis wrote:
PODness has changed from C++98.
Class layout in the ABI still uses the C++98 definition of POD.
Jason
On 5 January 2012 18:24, Tom de Vries wrote:
> On 05/01/12 18:40, Jonathan Wakely wrote:
>> On 5 January 2012 16:33, Marc Glisse wrote:
>>> On Thu, 5 Jan 2012, Joseph S. Myers wrote:
>>>
If the final C++11 still requires gets in , despite it being
removed in C11, that's probably also a bu
On 10/10/2011 08:07 PM, Gabriel Dos Reis wrote:
> PODness has changed from C++98.
Jason Merrill wrote:
> Class layout in the ABI still uses the C++98 definition of POD.
But does this actually matter? If I understand correctly, more classes are POD
under the C++11
rules than the C++98 rules, bu
On Thu, 2012-01-05 at 14:49 +0100, BELBACHIR Selim wrote:
> Hi,
>
> I'm still developping a new private target backend (gcc4.5.2) and I
> noticed something strange in the assembler generated for conditionnal
> jump.
>
>
I'm not sure whether it can help you in this particular case, but you
might
On 01/05/2012 01:38 PM, Joe Buck wrote:
Class layout in the ABI still uses the C++98 definition of POD.
But does this actually matter?
Yes, since PODness affects the use of tail padding. But it isn't a
source of ABI incompatibility since "POD for the purpose of layout"
isn't changing.
Ja
On 01/05/2012 10:33 PM, Paul S wrote:
> (define_insn "addqi3i"
> [(set (match_operand:HI 0 "register_operand" "=r")
> (plus:HI (match_operand:HI 1 "register_operand" "%0")
> (sign_extend:HI (match_operand:QI 2 "memory_operand" "m"]
Two things are wrong with this pattern:
(1) % is incorrect b
BELBACHIR Selim schrieb:
Hi,
I'm still developping a new private target backend (gcc4.5.2) and I
noticed something strange in the assembler generated for conditionnal
jump.
Maybe unfortunate defnition of branch costs or rtx costs?
How can I tell GCC to perform the best conditionnal jump by s
I am making a OS for a PC/AT compatible machine with gcc on ubuntu.
The code , whose extension is .c , to task switch in the handler for PIT(timer)
interrupt is...
int tr=(a selector(segment number));
farjmp(0,tr);
the function prototype is
farjmp(int eip,int cs);
farjmp() is defined in another
From: Joseph Myers [mailto:jos...@codesourcery.com]
> On Wed, 4 Jan 2012, Xinyu Qi wrote:
>
> > It seems these two parts of the code dealing with BYTE_BIG_ENDIAN will
> > cancel each other, and result in the original imm op unchanged.
>
> Yes, that's correct. Lane numbers for NEON intrinsics are
24 matches
Mail list logo
