On 11/12/2013, at 3:45 pm, Ramana Radhakrishnan
wrote:
> On Wed, Dec 11, 2013 at 12:02 AM, Maxim Kuvyrkov wrote:
>> On 11/12/2013, at 11:14 am, Ramana Radhakrishnan
>> wrote:
>>
>>> On Tue, Dec 10, 2013 at 9:44 PM, Maxim Kuvyrkov
>>> wrote:
On 11/12/2013, at 5:17 am, Ramana Radhakrish
On Wed, Dec 11, 2013 at 12:02 AM, Maxim Kuvyrkov wrote:
> On 11/12/2013, at 11:14 am, Ramana Radhakrishnan
> wrote:
>
>> On Tue, Dec 10, 2013 at 9:44 PM, Maxim Kuvyrkov wrote:
>>> On 11/12/2013, at 5:17 am, Ramana Radhakrishnan
>>> wrote:
>>>
On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos
On 11/12/2013, at 11:14 am, Ramana Radhakrishnan
wrote:
> On Tue, Dec 10, 2013 at 9:44 PM, Maxim Kuvyrkov wrote:
>> On 11/12/2013, at 5:17 am, Ramana Radhakrishnan
>> wrote:
>>
>>> On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos wrote:
Hi,
Near the start of schedule_block, find_
On Tue, Dec 10, 2013 at 9:44 PM, Maxim Kuvyrkov wrote:
> On 11/12/2013, at 5:17 am, Ramana Radhakrishnan
> wrote:
>
>> On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos wrote:
>>> Hi,
>>>
>>> Near the start of schedule_block, find_modifiable_mems is called if
>>> DONT_BREAK_DEPENDENCIES is not enabl
On 6/12/2013, at 9:44 pm, shmeel gutl wrote:
> On 06-Dec-13 01:34 AM, Maxim Kuvyrkov wrote:
>> On 6/12/2013, at 8:44 am, shmeel gutl wrote:
>>
>>> On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote:
Dependency type plays a role for estimating costs and latencies between
instructions (which
On 11/12/2013, at 5:17 am, Ramana Radhakrishnan
wrote:
> On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos wrote:
>> Hi,
>>
>> Near the start of schedule_block, find_modifiable_mems is called if
>> DONT_BREAK_DEPENDENCIES is not enabled for this scheduling pass. It seems on
>> c6x backend currentl
On Tue, Dec 10, 2013 at 4:17 PM, Claudiu Zissulescu wrote:
> Hi,
>
> Our ARC processor has a multiplication operation that returns a 64 bit result
> into a fixed register pair named like this:
>
> mlo:DI=zero_extend(r159:SI)*sign_extend(r181:SI)
>
> The GCSE rtl pre step has some difficulties to
> (For the types you do have, there's a need to define C++ name mangling.
I mentioned this before, and I don't have a good solution for it.
Both C++ and LTO need a mangled form of __intN types.
On Tue, 10 Dec 2013, DJ Delorie wrote:
> > This seems mostly plausible, though I don't see anything to ensure that
> > __intN does not exist at all if the size matches one of the standard C
> > types,
>
> My thought here was that, since each __intN is specified by the
> target, they'd know to o
> This seems mostly plausible, though I don't see anything to ensure that
> __intN does not exist at all if the size matches one of the standard C
> types,
My thought here was that, since each __intN is specified by the
target, they'd know to only do so if it doesn't match an existing (for
that
On Tue, 10 Dec 2013, BELBACHIR Selim wrote:
> The selector 'target c++98' (in { dg-error "std=" "std" { target c++98 }
> } for example) do not prevent the FAIL to be printed when -std=c++11
> options is used.
Well, that would be a bug in one of (a) the test harness code, (b) the way
the select
I have exactly the same behaviour than my native linux compiler. I don't
understand why DejaGnu exp files print such FAIL.
3 errors has to be printed when using -std=c++98 and 0 errors has to be printed
when using -std=c++11. That's what my compiler does.
The selector 'target c++98' (in { dg-er
On Tue, 10 Dec 2013, BELBACHIR Selim wrote:
> FAIL: g++.dg/cpp0x/auto27.C -std=c++11 std (test for errors, line 3)
> FAIL: g++.dg/cpp0x/auto27.C -std=c++11 auto (test for errors, line 3)
> FAIL: g++.dg/cpp0x/auto27.C -std=c++11 no type (test for errors, line 3)
That means that the desired result
On Mon, 9 Dec 2013, DJ Delorie wrote:
> First pass at actual code. I took the path of using a new macro in
> TARGET-modes.def and having genmodes build the relevent tables. Part
> of the table is created by genmodes, the rest is created at runtime.
This seems mostly plausible, though I don't se
On 12/10/2013 02:21 PM, Prathamesh Kulkarni wrote:
The following code fails to compile with gcc-4.8.2.
int main(void)
{
while ( ({ break; 0; }) )
;
return 0;
}
foo.c:3:14: error: break statement not within loop or switch
while ( ({ break; 0; }) )
^
Is this
On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos wrote:
> Hi,
>
> Near the start of schedule_block, find_modifiable_mems is called if
> DONT_BREAK_DEPENDENCIES is not enabled for this scheduling pass. It seems on
> c6x backend currently uses this.
> However, it's quite strange that this is not a requ
Hi,
I'm playing c++ testsuite on my gcc.4.7.3 port and I encounter the following
result on test auto27.C
PASS: g++.dg/cpp0x/auto27.C -std=c++98 std (test for errors, line 3)
PASS: g++.dg/cpp0x/auto27.C -std=c++98 auto (test for errors, line 3)
PASS: g++.dg/cpp0x/auto27.C -std=c++98 no type (test
On Tue, Dec 10, 2013 at 4:03 PM, Umesh Kalappa wrote:
> Hi All,
>
> Below is the patterns defined for the mov and add instruction
> .
> [(set (match_operand:HI 0 "general_mov_operand" "=r,rRA")
> (match_operand:HI 1 "general_mov_operand" "rRAi,ri"))]
> ""
> {
>
> }
>
Hi,
Our ARC processor has a multiplication operation that returns a 64 bit result
into a fixed register pair named like this:
mlo:DI=zero_extend(r159:SI)*sign_extend(r181:SI)
The GCSE rtl pre step has some difficulties to handle hard register pair
information. To exemplify my problem please s
Hi All,
Below is the patterns defined for the mov and add instruction
.
[(set (match_operand:HI 0 "general_mov_operand" "=r,rRA")
(match_operand:HI 1 "general_mov_operand" "rRAi,ri"))]
""
{
}
)
(define_insn "addhi3"
[(set (match_operand:HI 0 "register_operand" "=A
The following code fails to compile with gcc-4.8.2.
int main(void)
{
while ( ({ break; 0; }) )
;
return 0;
}
foo.c:3:14: error: break statement not within loop or switch
while ( ({ break; 0; }) )
^
Is this a compile-error or is it a bug in GCC ?
clang-3.2 seems to
"H.J. Lu" writes:
> There are git tags for GCC 4.8.0 and 4.8.1. But git tag
> for GCC 4.8.2 is missing.
Fixed.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
22 matches
Mail list logo