On 6/6/19 11:54 PM, Jeff Law wrote:
> On 6/6/19 1:42 PM, Andrew MacLeod wrote:
>> On 6/6/19 1:20 PM, Jeff Law wrote:
>>> On 6/6/19 7:02 AM, Andrew MacLeod wrote:
On 6/6/19 6:20 AM, Martin Liška wrote:
> Hi.
>
> The code is dead:
>
> 757 char *
> 758 get_
Snapshot gcc-7-20190606 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190606/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On 6/6/19 1:42 PM, Andrew MacLeod wrote:
> On 6/6/19 1:20 PM, Jeff Law wrote:
>> On 6/6/19 7:02 AM, Andrew MacLeod wrote:
>>> On 6/6/19 6:20 AM, Martin Liška wrote:
Hi.
The code is dead:
757 char *
758 get_lsm_tmp_name (tree ref, unsigned n, const char
On 6/6/19 1:20 PM, Jeff Law wrote:
On 6/6/19 7:02 AM, Andrew MacLeod wrote:
On 6/6/19 6:20 AM, Martin Liška wrote:
Hi.
The code is dead:
757 char *
758 get_lsm_tmp_name (tree ref, unsigned n, const char *suffix)
759 {
760 char ns[2];
761
762 ls
> Another option, which I guess starts to go out of scope of your gsoc, is
> parallel depth first (PDF) search (Blelloch 1999) as an alternative to work
> stealing. Here's a presentation about some recent work in this area,
> although for Julia and not OpenMP (no idea if PDF would fit with OpenMP a
On 6/6/19 7:02 AM, Andrew MacLeod wrote:
> On 6/6/19 6:20 AM, Martin Liška wrote:
>> Hi.
>>
>> The code is dead:
>>
>> 757 char *
>> 758 get_lsm_tmp_name (tree ref, unsigned n, const char *suffix)
>> 759 {
>> 760 char ns[2];
>> 761
>> 762 lsm_tmp_name_l
Hi,
On Mon, Jun 03 2019, Tejas Joshi wrote:
> Hello.
> I have already sent a patch for roundeven implementation but I do not
> know how do I commit my changes to GCC. Am I supposed to create a
> branch or anything etc?
You don't have to create a branch unless you think it would make ease
your own
On Thu, Jun 06, 2019 at 05:06:35PM +0100, Richard Earnshaw (lists) wrote:
> The reason combine doesn't catch this is because at the time it runs the
> MOV is in a different basic block. Later on it is sunk into the same
> basic block, but it's then too late to do the merge.
Or you could say the M
On Tue, 4 Jun 2019, Tejas Joshi wrote:
> Hello.
>
> > NaN, and you should make sure it behaves accordingly. (If it should never
> > be called for them, a gcc_assert would be appropriate.)
>
> I can't find any documentation about how and when to use gcc_assert.
> But I used it looking at the com
On 06/06/2019 15:55, Fredrik Hederstierna wrote:
>> From: Segher Boessenkool
>> Sent: Thursday, June 6, 2019 4:02 PM
>> To: Richard Earnshaw (lists)
>> Cc: Jeff Law; Fredrik Hederstierna; gcc@gcc.gnu.org
>> Subject: Re: ARM peephole2 from 2003 never merged, still valid
>
>> That doesn't stop co
> From: Segher Boessenkool
> Sent: Thursday, June 6, 2019 4:02 PM
> To: Richard Earnshaw (lists)
> Cc: Jeff Law; Fredrik Hederstierna; gcc@gcc.gnu.org
> Subject: Re: ARM peephole2 from 2003 never merged, still valid
> That doesn't stop combine from considering it. It does make that first SET
>
On Thu, Jun 06, 2019 at 10:12:57AM +0100, Richard Earnshaw (lists) wrote:
> On 06/06/2019 00:46, Segher Boessenkool wrote:
> > On Wed, Jun 05, 2019 at 05:02:53PM -0600, Jeff Law wrote:
> >> On 6/2/19 6:28 AM, Segher Boessenkool wrote:
> >>> Do you have a testcase for this? I wonder if it would be
On 6/6/19 6:20 AM, Martin Liška wrote:
Hi.
The code is dead:
757 char *
758 get_lsm_tmp_name (tree ref, unsigned n, const char *suffix)
759 {
760 char ns[2];
761
762 lsm_tmp_name_length = 0;
763 gen_lsm_tmp_name (ref);
764 lsm_tmp_name_add ("_lsm");
Many thanks for your extremely prompt help!
Regards,
Farid Parpia IBM Corporation: 710-2-RF28, 2455 South Road,
Poughkeepsie, NY 12601, USA; Telephone: (845) 433-8420 = Tie Line 293-8420
- Forwarded by Farid Parpia/Poughkeepsie/IBM on 06/06/2019 08:24 AM
-
From: Richard Bie
Hi.
The code is dead:
757 char *
758 get_lsm_tmp_name (tree ref, unsigned n, const char *suffix)
759 {
760char ns[2];
761
762lsm_tmp_name_length = 0;
763gen_lsm_tmp_name (ref);
764lsm_tmp_name_add ("_lsm");
765if (n < 10)
766 {
767
On 06/06/2019 00:46, Segher Boessenkool wrote:
> On Wed, Jun 05, 2019 at 05:02:53PM -0600, Jeff Law wrote:
>> On 6/2/19 6:28 AM, Segher Boessenkool wrote:
>>> On Sat, Jun 01, 2019 at 11:41:30PM +, Fredrik Hederstierna wrote:
+(define_peephole2
+ [(set (match_operand:SI 0 "arm_general
On Wed, Jun 5, 2019 at 3:26 PM Jozef Lawrynowicz wrote:
>
> The MSP430 target in the large memory model uses the (non-ISO) __int20 type
> for
> SIZE_TYPE and PTRDIFF_TYPE.
> The preprocessor therefore expands a builtin such as __SIZE_TYPE__ to
> "__int20 unsigned" in user code.
> When compiling w
On Wed, Jun 5, 2019 at 6:32 PM Farid Parpia wrote:
>
>
> Greetings,
>
> It appears that the given sha512 sum for gcc-7.4.0.tar.gz may be incorrect
> on at least the following mirrors:
>http://mirrors.concertpass.com/
>http://www.netgull.com/
>https://bigsearcher.com/
It's incorrect on
18 matches
Mail list logo
