On 11/11/2013 03:22 AM, Jeff Law wrote:
> On 11/09/13 08:55, Andrew Haley wrote:
>> On 11/09/2013 03:44 PM, Alec Teal wrote:
>>> If Java must go, and it must have a replacement Ada makes sense. The
>>> issues with Go (sadly, you guys are doing superb work) do make sense.
>>>
>>> I don't know enough
On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving
wrote:
> That didn't do it. What was the rationale w.r.t. to the relation
> between the vectorized sequenced and/or the alignment (I think these
> things are actually 2 separate things..) and the common block?!
We cannot adjust the alignment of a co
On Fri, Nov 8, 2013 at 9:21 PM, Jeff Law wrote:
> On 11/08/13 02:28, Konstantin Vladimirov wrote:
>>
>> typedef struct
>> {
>>unsigned prev;
>>unsigned next;
>> } foo_t;
>>
>> void
>> foo( unsigned x, unsigned y)
>>{
>> foo_t *ptr = (foo_t *)((void *)x);
>>
>> if (y != 0)
>>
On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote:
> On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving
> wrote:
> > That didn't do it. What was the rationale w.r.t. to the relation
> > between the vectorized sequenced and/or the alignment (I think these
> > things are actually 2 separat
On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek wrote:
> On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote:
>> On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving
>> wrote:
>> > That didn't do it. What was the rationale w.r.t. to the relation
>> > between the vectorized sequenced and/or
On Mon, Nov 11, 2013 at 02:13:24PM +0100, Richard Biener wrote:
> On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek wrote:
> > On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote:
> >> On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving
> >> wrote:
> >> > That didn't do it. What was the rati
On Mon, Nov 11, 2013 at 2:39 PM, Jakub Jelinek wrote:
> On Mon, Nov 11, 2013 at 02:13:24PM +0100, Richard Biener wrote:
>> On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek wrote:
>> > On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote:
>> >> On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Grev
Jeff Law writes:
> Thoughts or comments?
If noone tests java completely then it will quickly bitrot won't it?
So ideally some bot would still regularly build/test it.
If you don't do that you could as well just remove the code.
The underlying problem seems to be the requirement for each
contri
On Mon, Nov 11, 2013 at 9:38 AM, Andi Kleen wrote:
> Jeff Law writes:
>
>> Thoughts or comments?
>
> If noone tests java completely then it will quickly bitrot won't it?
>
> So ideally some bot would still regularly build/test it.
> If you don't do that you could as well just remove the code.
>
>
On Mon, Nov 11, 2013 at 06:38:15AM -0800, Andi Kleen wrote:
> Jeff Law writes:
>
> > Thoughts or comments?
>
> If noone tests java completely then it will quickly bitrot won't it?
>
> So ideally some bot would still regularly build/test it.
> If you don't do that you could as well just remove t
On Mon, 11 Nov 2013, Ondrej Bilka wrote:
> These will be checked by bots and when there is a failure on closed bug it
> will be reopened.
No, don't reopen old bugs unless it turns out the patch claimed to fix the
bug didn't fix it at all, or needed to be reverted. Open new bugs when
all you kn
On Mon, Nov 11, 2013 at 04:12:51PM +, Joseph S. Myers wrote:
> On Mon, 11 Nov 2013, Ondrej Bilka wrote:
>
> > These will be checked by bots and when there is a failure on closed bug it
> > will be reopened.
>
> No, don't reopen old bugs unless it turns out the patch claimed to fix the
> bug
On 11/10/2013 07:58 PM, Iyer, Balaji V wrote:
Semi crazy thought...If I do something like a string compare for the operation after
operator toward the end of the function, will I get what I want? I guess another way to
ask this is, will a '+' operation, for example, be mapped to a function endi
On 11/11/13 07:38, Andi Kleen wrote:
Jeff Law writes:
Thoughts or comments?
If noone tests java completely then it will quickly bitrot won't it?
So ideally some bot would still regularly build/test it.
If you don't do that you could as well just remove the code.
There's no reason to remove
On 11/11/2013 11:57 PM, Richard Biener wrote:
> On Mon, Nov 11, 2013 at 2:39 PM, Jakub Jelinek wrote:
>> On Mon, Nov 11, 2013 at 02:13:24PM +0100, Richard Biener wrote:
>>> On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek wrote:
On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote:
Am 11.11.2013 11:06, schrieb Andrew Haley:
> On 11/11/2013 03:22 AM, Jeff Law wrote:
>> On 11/09/13 08:55, Andrew Haley wrote:
>>> On 11/09/2013 03:44 PM, Alec Teal wrote:
If Java must go, and it must have a replacement Ada makes sense. The
issues with Go (sadly, you guys are doing superb
On Mon, Nov 11, 2013 at 3:56 PM, Richard Henderson wrote:
>> I suppose targets without .bss section support should not switch
>> (that is, targets not defining BSS_SECTION_ASM_OP or
>> ASM_OUTPUT_ALIGNED_BSS).
>
> Good point. I don't expect that we have many of those left, but
> if any do still
Am 09.11.2013 01:24, schrieb Ian Lance Taylor:
> On Fri, Nov 8, 2013 at 2:21 PM, Jeff Law wrote:
>>
>> So instead of proposing that we just remove Java from the default languags,
>> I propose that we replace Java with Go.
>
> I'm certainly in favor of removing Java from the set of default
> langu
Am 08.11.2013 23:21, schrieb Jeff Law:
>
>
> GCJ has, IMHO, moved from active development into a deep maintenance mode.
> I
> suspect this is largely due to the change of focus of key developers to
> OpenJDK
> and other projects. GCJ played a role in bootstrapping OpenJDK, both
> technicall
On Mon, Nov 11, 2013 at 1:32 PM, Matthias Klose wrote:
>
> One more thing for posting test results with multilib enabled: It would be
> nice
> if libgo would use dejagnu and honor RUNTESTFLAGS for multilib test runs.
What does libstdc++ do for RUNTESTFLAGS?
Ian
Ok, thanks, that explains it... Apparently x86 splits the vector movs
into 2 in
ix86_expand_vector_move_misalign->ix86_avx256_split_vector_move_misalign.
But I wanted to mention that e.g. icc, despite also putting g_a, g_b,
g_c into .comm, actually generates AVX2 vmovdqu using ymm...
Examples:
f
On Mon, Nov 11, 2013 at 2:48 PM, Hendrik Greving
wrote:
> Ok, thanks, that explains it... Apparently x86 splits the vector movs
> into 2 in
> ix86_expand_vector_move_misalign->ix86_avx256_split_vector_move_misalign.
> But I wanted to mention that e.g. icc, despite also putting g_a, g_b,
> g_c int
On 11/08/13 05:36, Joseph S. Myers wrote:
I realised that the C11 atomics changes didn't do anything to record
atomic types as such in DWARF debug info - then found that DWARF4 didn't
provide a way to specify the C11 _Atomic qualifier at all. Could someone
working with the DWARF committee get an
On 11/11/13 14:48, Matthias Klose wrote:
The last news item related to Java was 2009 and scanning the ChangeLog doesn't
show significant project activity (~14 changes in 2013, most of which look like
routine maintenance in the language front-end. There's even fewer changes
occurring in the run
I've filed bug 59084. I think it actually might affect the same x86
backend stuff as bug 41464.
Hendrik
On Mon, Nov 11, 2013 at 4:00 PM, H.J. Lu wrote:
> On Mon, Nov 11, 2013 at 2:48 PM, Hendrik Greving
> wrote:
>> Ok, thanks, that explains it... Apparently x86 splits the vector movs
>> into 2 i
On 11/09/13 04:12, Eric Botcazou wrote:
Right now Go does not build on a range of targets, notably including
Windows, MacOS, AIX, and most embedded systems. We would have to
disable it by default on targets that are not supported, which is
straightforward (we already have rules to disable java o
> From what I can see, bootstrapping with Ada is slower than bootstapping
> with Java, by around 15%. Again this is on one of my slower boxes, but
> the results clearly show building Ada & its runtime takes a considerable
> amount of time:
>
> default languages:67 minutes
> default - java:
[text-only]
On Sun, Nov 10, 2013 at 10:34 PM, FX wrote:
>> Unfortunately, we are not able to keep up with the old kernels.
>> Two possible ways to go:
>> - disable libsanitizer on older kernels
>> - someone needs to work with us in upstream repository (llvm) to keep the
>> code old-kernel-comp
On Tue, Nov 12, 2013 at 11:34:41AM +0400, Kostya Serebryany wrote:
> On Sun, Nov 10, 2013 at 10:34 PM, FX wrote:
>
> > > Unfortunately, we are not able to keep up with the old kernels.
> > > Two possible ways to go:
> > > - disable libsanitizer on older kernels
> > > - someone needs to work wit
29 matches
Mail list logo
