On Thu, Jun 27, 2019 at 05:20:56AM +0900, 김규래 wrote:
> I'll share my status for GSoC first evaluation.
>
> Current status of libgomp task system:
> I'll first summarize my understanding of libgomp.
> Please correct me if I'm wrong.
> Currently libgomp has 3 different queues: children_queue, taskl
>>> On 27.06.19 at 11:03, wrote:
> With just an "m" constraint misaligned memory operands won't be forced
> into a register, and hence cause #GP. So far this was guaranteed only
> in the case that CVT{,T}PD2DQ were chosen (which looks to be the case on
> x86-64 only).
>
> Instead of switching the
On Wed, Jun 26, 2019 at 5:33 PM charfi asma via gcc wrote:
>
> Hello,
> I am interested in generating the CFG from several gcc front ends. All works
> fine for GCC and G++, and we are also interrested in JAVA.
> we have seen that GCJ is no longer maintained/distributed by GCCHowever, we
> do not
On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote:
>
> >>> On 27.06.19 at 11:03, wrote:
> > With just an "m" constraint misaligned memory operands won't be forced
> > into a register, and hence cause #GP. So far this was guaranteed only
> > in the case that CVT{,T}PD2DQ were chosen (which looks
>>> On 27.06.19 at 12:22, wrote:
> On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote:
>>
>> >>> On 27.06.19 at 11:03, wrote:
>> > With just an "m" constraint misaligned memory operands won't be forced
>> > into a register, and hence cause #GP. So far this was guaranteed only
>> > in the case th
On Thu, Jun 27, 2019 at 12:47 PM Jan Beulich wrote:
>
> >>> On 27.06.19 at 12:22, wrote:
> > On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote:
> >>
> >> >>> On 27.06.19 at 11:03, wrote:
> >> > With just an "m" constraint misaligned memory operands won't be forced
> >> > into a register, and h
Hi Kewen,
On Thu, Jun 27, 2019 at 10:32:18AM +0800, Kewen.Lin wrote:
> 6: NOTE_INSN_BASIC_BLOCK 2
>
>12: r135:CC=cmp(r122:DI,0)
>13: pc={(r135:CC!=0)?L52:pc}
> REG_DEAD r135:CC
> REG_BR_PROB 1041558836
>31: L31:
>17: NOTE_INSN_BASIC_BLOCK 3
>
> The above
>>> On 27.06.19 at 13:02, wrote:
> On Thu, Jun 27, 2019 at 12:47 PM Jan Beulich wrote:
>>
>> >>> On 27.06.19 at 12:22, wrote:
>> > On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote:
>> >>
>> >> >>> On 27.06.19 at 11:03, wrote:
>> >> > With just an "m" constraint misaligned memory operands won
On Thu, Jun 27, 2019 at 1:31 PM Jan Beulich wrote:
>
> >>> On 27.06.19 at 13:02, wrote:
> > On Thu, Jun 27, 2019 at 12:47 PM Jan Beulich wrote:
> >>
> >> >>> On 27.06.19 at 12:22, wrote:
> >> > On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote:
> >> >>
> >> >> >>> On 27.06.19 at 11:03, wrote
>>> On 27.06.19 at 14:07, wrote:
> On Thu, Jun 27, 2019 at 1:31 PM Jan Beulich wrote:
>>
>> >>> On 27.06.19 at 13:02, wrote:
>> > On Thu, Jun 27, 2019 at 12:47 PM Jan Beulich wrote:
>> >>
>> >> >>> On 27.06.19 at 12:22, wrote:
>> >> > On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote:
>> >>
On Thu, Jun 27, 2019 at 2:14 PM Jan Beulich wrote:
>
> >>> On 27.06.19 at 14:07, wrote:
> > On Thu, Jun 27, 2019 at 1:31 PM Jan Beulich wrote:
> >>
> >> >>> On 27.06.19 at 13:02, wrote:
> >> > On Thu, Jun 27, 2019 at 12:47 PM Jan Beulich wrote:
> >> >>
> >> >> >>> On 27.06.19 at 12:22, wrote:
Hi.
So this is a patch candidate for the .gnu.lto_.lto ELF section.
As mentioned, the section contains information about bytecode version,
compression algorithm used and slim LTO object flag.
One minor issues is that I need to append random suffix to the section:
[ 6] .gnu.lto_.lto.36e74acfb145
On 6/21/19 4:28 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>>
>> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
>>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> On 6/21/19 1:47
On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
>
> On 6/21/19 4:28 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
> >>
> >> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> >>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> On Fri, Jun 21, 20
On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
>>
>> On 6/21/19 4:28 PM, Richard Biener wrote:
>>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> On 6/21/19 1:58 PM,
Hi people!
This is a call for proposals for the Toolchain micro-conference at this
years' Linux Plumbers Conference (LPC) 2019 which will be held in
Lisbon, Portugal for September 9-11.
The Linux kernel is particularly demanding in terms of tooling, and the
main purpose of this micro-conference
Thank you for your help.
Yes, It seems that gcj6 is not well installaed.
Could you please help me to install it ? which installation instruction should
I follow ?
I can not installed with apt-get
should I checkout the gcj 6 from git and setup it manually ?
If yes, can you please give me the ste
On Thu, Jun 27, 2019 at 10:23 AM Martin Liška wrote:
>
> On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> > On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
> >>
> >> On 6/21/19 4:28 PM, Richard Biener wrote:
> >>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>
> On Fri, Jun 21, 2
>
> It's useful on targets without COMDAT support. Are there any such
> that we care about at this point?
>
> If the problem is the combination with LTO, why not just prohibit that?
The problem is that at the collect2 time we want to decide whether to
hold stderr/stdout of the linker. The issue
> On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
>
>>
>> It's useful on targets without COMDAT support. Are there any such
>> that we care about at this point?
>>
>> If the problem is the combination with LTO, why not just prohibit that?
>
> The problem is that at the collect2 time we want to
>
> > On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
> >
> >>
> >> It's useful on targets without COMDAT support. Are there any such
> >> that we care about at this point?
> >>
> >> If the problem is the combination with LTO, why not just prohibit that?
> >
> > The problem is that at the colle
On Thu, Jun 27, 2019 at 11:32 AM charfi asma via gcc wrote:
>
> Thank you for your help.
> Yes, It seems that gcj6 is not well installaed.
> Could you please help me to install it ? which installation instruction
> should I follow ?
>
> I can not installed with apt-get
> should I checkout the gc
Snapshot gcc-7-20190627 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190627/
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
Hi Segher,
Thanks a lot for the comments.
on 2019/6/28 上午9:32, wrote:
> Hi Kewen,
>
> On Thu, Jun 27, 2019 at 10:32:18AM +0800, Kewen.Lin wrote:
>> 6: NOTE_INSN_BASIC_BLOCK 2
>>
>>12: r135:CC=cmp(r122:DI,0)
>>13: pc={(r135:CC!=0)?L52:pc}
>> REG_DEAD r135:CC
>>
Greetings,
Did you received my message?let me know.
Best Regards,
Mr.Abdelkader Alsamman.
25 matches
Mail list logo
