I'm working on converting sparc to LRA, and thanks probably to the
work the powerpc folks did this is going much better than when I
last tried this.
The first major stumbling block I've run into is when LRA forces
a reload for a SUBREG, and specifically there is a MEM involved
that itself needs a
From: Segher Boessenkool
Date: Thu, 3 Sep 2015 20:26:51 -0500
> On Thu, Sep 03, 2015 at 03:33:56PM -0700, David Miller wrote:
>> (insn 18631 1099 1100 14 (set (reg:SI 13423)
>> (subreg:SI (mem/c:QI (plus:SI (reg/f:SI 101 %sfp)
>> (const_int -1426
From: Vladimir Makarov
Date: Fri, 4 Sep 2015 10:00:54 -0400
> LRA porting frequently needs changing in constraints.md, .c,
> and .md files.
I did make such changes, trust me :-)
First obstacle was that, unlike reload, LRA is very strict about
register constraints. If a constraint doesn't evalu
From: Segher Boessenkool
Date: Fri, 4 Sep 2015 06:46:04 -0500
> On Thu, Sep 03, 2015 at 11:19:43PM -0700, David Miller wrote:
>> The paradoxical subreg restriction in general_operand() is only
>> enforced when reload_completed is true, which will not be the
>> case
From: David Miller
Date: Fri, 04 Sep 2015 11:30:26 -0700 (PDT)
> From: Segher Boessenkool
> Date: Fri, 4 Sep 2015 06:46:04 -0500
>
>> On Thu, Sep 03, 2015 at 11:19:43PM -0700, David Miller wrote:
>>> The paradoxical subreg restriction in general_operand() i
From: David Miller
Date: Fri, 04 Sep 2015 11:27:31 -0700 (PDT)
> From: Vladimir Makarov
> Date: Fri, 4 Sep 2015 10:00:54 -0400
>
>> I don't think we should add a new LRA code calling process_address
>> before adding insns for further processing. LRA just needs to get
From: Eric Botcazou
Date: Fri, 16 Sep 2016 23:43:43 +0200
>> p.s. Are there plans for converting the SPARC port?
>
> There are more than plans - actual patches by DaveM that were installed at
> some point and then reverted quickly because of unexpected fallout.
Yeah, sparc64 failed to bootstr
From: Eric Botcazou
Date: Sat, 17 Sep 2016 10:18:23 +0200
>> I lacked the time to debug it properly so we reverted.
>
> Do you plan to give it a try again in the near future?
I was going to work on this over the past summer, but other
responsibilities took up all of my time.
Probably the earli
From: Eric Botcazou
Date: Tue, 03 Jan 2017 22:22:05 +0100
>> p.s. Are there plans for converting the SPARC port?
>
> The SPARC port has now been converted.
Thanks so much for doing this work, I wish I could have been more
helpful.
From: Anthony Yznaga
Date: Tue, 15 Aug 2017 17:45:12 -0700
> I compiled a kernel with gcc 7 and found that the compiler inserted a
> call to __multi3() in mq_attr_ok(). The sparc64 implementation of
> __multi3() was added by 1b4af13ff2cc specifically for gcc 7 and later,
> but it clobbers %g4 an
From: Anatoly Pugachev
Date: Tue, 15 Aug 2017 21:50:45 +0300
> Together with Dmitry (ldv) , we've discovered that running test suite
> from strace produces kernel OOPS, when kernel is compiled with gcc 7.1
> or with gcc 7.2 , but not with gcc 6 :
Please try this patch:
diff --git a/arch/sparc/l
From: Anatoly Pugachev
Date: Wed, 16 Aug 2017 11:42:43 +0300
> On Wed, Aug 16, 2017 at 7:30 AM, David Miller wrote:
>> From: Anatoly Pugachev
>> Date: Tue, 15 Aug 2017 21:50:45 +0300
>>
>>> Together with Dmitry (ldv) , we've discovered that running test su
From: Russell King - ARM Linux
Date: Wed, 2 Feb 2011 16:37:02 +
> 1. there's no way to tell GCC that the inline assembly is a load
>instruction and therefore it needs to schedule the following
>instructions appropriately.
Just add a dummy '"m" (pointer)' asm input argument to the inl
From: Russell King - ARM Linux
Date: Wed, 2 Feb 2011 21:45:22 +
> On Wed, Feb 02, 2011 at 01:38:31PM -0800, David Miller wrote:
>> From: Russell King - ARM Linux
>> Date: Wed, 2 Feb 2011 16:37:02 +
>>
>> > 1. there's no way to tell GCC
From: Måns Rullgård
Date: Wed, 02 Feb 2011 23:08:01 +
> David Miller writes:
>
>> From: Russell King - ARM Linux
>> Date: Wed, 2 Feb 2011 16:37:02 +
>>
>>> 1. there's no way to tell GCC that the inline assembly is a load
>>>ins
I'm planning to support some new instructions found in recent sparc
cpus, specifically VIS 3.0 adds a series of "X and halve"
floating-point instructions where X is one of "add" or "subtract".
There are variants which negate the result as well.
They operate similar to FMA in that all the operati
From: Richard Henderson
Date: Wed, 12 Oct 2011 17:49:19 -0700
> There's a code sample 7-1 that illustrates a 16x16 multiply:
>
> fmul8sux16 %f0, %f1, %f2
> fmul8ulx16 %f0, %f1, %f3
> fpadd16%f2, %f3, %f4
Be wary of code examples that don't even assemble (even numbered
floa
From: David Miller
Date: Thu, 13 Oct 2011 14:26:36 -0400 (EDT)
> product = src1 * src2;
>
> scaled = (product & 0x0000) >> 8;
> if (product & 0x80)
> scaled++;
In fact, all of the partitioned multiply instructions scale the r
From: Richard Henderson
Date: Wed, 12 Oct 2011 17:49:19 -0700
> The comment for fpmerge_vis is not correct.
> I believe that the operation is representable with
>
> (vec_select:V8QI
> (vec_concat:V8QI
> (match_operand:V4QI 1 ...)
> (match_operand:V4QI 2 ...)
> (parallel [
>
From: Richard Henderson
Date: Thu, 13 Oct 2011 13:06:19 -0700
> On 10/13/2011 12:55 PM, David Miller wrote:
>> -(define_insn "_vis"
>> +(define_insn ""
>
> Missing a "3" on the end. Otherwise these look ok.
Thanks for finding that.
>&g
From: Eric Botcazou
Date: Fri, 14 Oct 2011 00:41:42 +0200
>> Unfortunately, that would involve some ABI changes for the VIS
>> builtins. I'm trending towards considering just changing things
>> anyways since the VIS intrinsics were next to unusable beforehand.
>
> Could you elaborate? The call
While working on some test cases I noticed that the 'fsmuld'
instruction on sparc was not being matched by the combiner for
things like:
double fsmuld (float a, float b)
{
return a * b;
}
Combine does try to match:
(set x (float_extend:DF (mul:SF y z)))
instead of what backends (and
From: Jakub Jelinek
Date: Tue, 25 Oct 2011 10:00:50 +0200
> I bet
> double fsmuld (float a, float b)
> {
> return (double) a * b;
> }
> instead will match your pattern, then the operands are first extended
> into double and then multiplied into a double product.
Right, in existing testcases I'
Although copy_value() in regcprop.c tries to avoid recording cases
where substitutions would be illegal, there are some bad cases it
still can let through.
On 64-bit sparc, integer regs are 64-bit and float regs are
(basically) 32-bit. So HARD_REGNO_NREGS(float_reg, DFmode) is 2, and
HARD_REGNO_
From: Eric Botcazou
Date: Thu, 27 Oct 2011 15:17:40 +0200
>> To reproduce build gcc.c-torture/execute/ieee/mzero.c with
>> "-m64 -mcpu=niagara3 -O2" on sparc.
>
> AFAICS there is no such file as gcc.c-torture/execute/ieee/mzero.c.
Sorry, the final path component should be "mzero2.c"
From: Eric Botcazou
Date: Thu, 27 Oct 2011 15:17:40 +0200
>> On 64-bit sparc, integer regs are 64-bit and float regs are
>> (basically) 32-bit. So HARD_REGNO_NREGS(float_reg, DFmode) is 2, and
>> HARD_REGNO_NREGS(integer_reg, DImode) is 1.
>>
>> cprop sees the sequence:
>>
>> (insn 330 172 230 .
From: Eric Botcazou
Date: Thu, 27 Oct 2011 23:11:33 +0200
>> Sorry, the final path component should be "mzero2.c"
>
> Thanks. I think we that need the same treatment in:
...
> as:
...
> i.e. we need to bail out if we are narrowing and this is a big-endian target.
I quickly tried the patch be
From: Eric Botcazou
Date: Thu, 27 Oct 2011 23:55:00 +0200
>> I quickly tried the patch below, but this does not prevent the
>> transformation.
>
> The quoted code is in copyprop_hardreg_forward_1.
Indeed :-)
This patch below works for the specific test case, and I'll post to
gcc-patches and co
I'm getting an ICE on 64-bit sparc for some vector test cases but
I'm not sure where the fix belongs.
When the compiler expands a vecor shift by scalar into a vector
shift by a vector it uses expand_vector_broadcast(), which has
a comment which states:
"The mode of OP must be the element mode of
g++.dg/init/copy7.C makes sure that memcpy() is not emitted with
src and dst equal.
The fix installed absolutely relies upon a backend implementing
the movmem pattern, and essentially that such a pattern will
always succeed to emit for arbitrary circumstances.
However 1) not all platforms implem
From: Richard Guenther
Date: Fri, 28 Oct 2011 11:27:25 +0200
> On Fri, Oct 28, 2011 at 9:48 AM, David Miller wrote:
>>
>> g++.dg/init/copy7.C makes sure that memcpy() is not emitted with
>> src and dst equal.
>
> The testcase is bogus and should be removed. See th
From: Richard Guenther
Date: Fri, 28 Oct 2011 12:47:30 +0200
> Then we have to fix the middle-end which will happily expand
> block-moves to memcpy with exact overlap (a = a is valid in C).
> See the PR and the C testcases therein.
>
> Just trying to avoid this in the C++ frontend is bogus.
Agr
gcc.dg/pr48616.c segfaults on sparc as of a day or two ago
vectorizable_shift() crashes because op1_vectype is NULL and
we hit this code path:
/* Vector shifted by vector. */
if (!scalar_shift_arg)
{
optab = optab_for_tree_code (code, vectype, optab_vector);
if (vect_print_d
Please post binutils patches with the binutils development list CC:'d.
GCC patches are to be posted to gcc-patches, not gcc.
From: Konrad Eisele
Date: Tue, 01 Nov 2011 10:19:04 +0100
> David Miller wrote:
>>
>> Please post binutils patches with the binutils development list CC:'d.
>>
>>
>
> Is the binutils development list bug-binut...@gnu.org ?
No, it's binut...@sourceware.org
From: David Miller
Date: Fri, 28 Oct 2011 01:05:54 -0400 (EDT)
> So should expand_vector_broadcast() really provide this invariant to
> the vec_init expander, or does the vec_init expander need to tidy
> things up with gen_lowpart() etc. calls?
Richard I don't know if you had a
My sparc-linux-gnu builds with --enable-targets=all is failing with:
../../../../gcc/libgcc/config/sparc/lb1spc.S: Assembler messages:
../../../../gcc/libgcc/config/sparc/lb1spc.S:124: Error: detected global
register use not covered by .register pseudo-op
../../../../gcc/libgcc/config/sparc/lb1s
From: Joel Sherrill
Date: Wed, 2 Nov 2011 16:29:16 -0500
> Is this similar to what I just got for sparc-rtems when compiling
> libgcc2 with -mcpu=v8?
>
> /tmp/cczMc4jN.s: Assembler messages:
> /tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled for
> "smul".
> /tmp/cczMc4jN.s:18:
From: David Miller
Date: Wed, 02 Nov 2011 18:30:56 -0400 (EDT)
> From: Joel Sherrill
> Date: Wed, 2 Nov 2011 16:29:16 -0500
>
>> Is this similar to what I just got for sparc-rtems when compiling
>> libgcc2 with -mcpu=v8?
>>
>> /tmp/cczMc4jN.s: Assembler messa
From: David Miller
Date: Wed, 02 Nov 2011 18:43:52 -0400 (EDT)
> So t-softmul gets appended anyways, and this causes us to try and
> build config/sparc/lb1spc.S for the 64-bit libgcc which we should
> never do.
I tried the patch below but it just results in syntax errors in the
Make
From: Andrew Pinski
Date: Wed, 2 Nov 2011 16:40:13 -0700
> On Wed, Nov 2, 2011 at 4:28 PM, David Miller wrote:
>> +LIB1ASMSRC = `if test x$$($(CC) -print-multi-os-directory) \
>> + = x../lib64; then echo sparc/lb1spc.S; fi`
>> +LIB1ASMFUNCS = `if
From: "Joseph S. Myers"
Date: Thu, 3 Nov 2011 00:22:49 + (UTC)
> On Wed, 2 Nov 2011, David Miller wrote:
>
>> Actually the problem is that libgcc/config.host checks ${host}
>> to decide whether to append config/sparc/t-softmul to the tmake
>> variable.
From: "Joseph S. Myers"
Date: Thu, 3 Nov 2011 01:21:35 + (UTC)
> What is new is that you can now put tests in libgcc/configure.ac
> such as the "Check 32bit or 64bit for x86." one, and select t-*
> files based on those tests - whereas in the gcc/ directory there is
> no possibility at all for
From: Jakub Jelinek
Date: Thu, 3 Nov 2011 09:22:51 +0100
> On Wed, Nov 02, 2011 at 11:41:08PM -0400, David Miller wrote:
>> --- a/libgcc/configure.ac
>> +++ b/libgcc/configure.ac
>> @@ -255,11 +255,12 @@ AC_CACHE_CHECK([whether assembler supports CFI
>>
From: Jakub Jelinek
Date: Thu, 3 Nov 2011 09:22:51 +0100
> I think much better would be to handle sparc*/s390*/powerpc* differently
> here, just using #ifdef __LP64__ test. i?86/x86_64 is different because
> of the third weirdo multilib option.
I just tested and committed the following, it seem
While building libstdc++ I get an assertion failure in haifa-sched.c,
specifically the assertion on line 3437 is failing:
gcc_assert (!jump_p
|| ((common_sched_info->sched_pass_id == SCHED_RGN_PASS)
&& IS_SPECULATION_BRANCHY_CHECK_P (insn)
From: David Miller
Date: Fri, 11 Nov 2011 20:41:23 -0500 (EST)
> I haven't looked more deeply at it, but the first recent suspicious change
> are the basic block handling changes Alan made two days ago:
>
> 2011-11-09 Alan Modra
>
> * function.c (bb_active
From: Dennis Clarke
Date: Sat, 12 Nov 2011 12:51:18 -0500 (EST)
>> While building libstdc++ I get an assertion failure in haifa-sched.c,
>> specifically the assertion on line 3437 is failing:
>
> I am seeing no major problems on Sparc at all. What rev of GCC are you
> referring to please?
As
From: Joel Sherrill
Date: Sat, 12 Nov 2011 08:34:29 -0600
> From my perspective, the head doesn't look so good. :(
I'm extremely disappointed with how the last 2 weeks have gone
as well. I can't work on any of the bugs I want to work on
because the tree keeps being broken.
I guess the end of s
From: Hans-Peter Nilsson
Date: Sat, 12 Nov 2011 07:25:46 -0500 (EST)
> On Fri, 11 Nov 2011, David Miller wrote:
>>
>> While building libstdc++ I get an assertion failure in haifa-sched.c,
>> specifically the assertion on line 3437 is failing:
>
>> I haven'
For a few days a lot of new testsuite failures have popped up on sparc,
wherein int_mode_for_mode() gets called with "VOIDmode" as an argument
from extract_bit_field_1 because "op0" is "(const_int 0)"
I have a feeling this is a known problem, but I couldn't find any
discussions about this.
I str
From: Michael Matz
Date: Wed, 1 Feb 2012 18:41:05 +0100 (CET)
> One problem is that it's not a new problem, GCC emitted similar code since
> about forever, and still they turned up only now (well, probably because
> ia64 is dead, but sparc64 should have similar problems).
Indeed, on sparc64 i
From: Eric Botcazou
Date: Wed, 5 Aug 2009 17:59:01 +0200
>> I believe that I could legitimately approve that patch myself (it's
>> pretty trivial and I didn't author it), but I'd prefer to get approval
>> from one of the SPARC maintainers. Here's your chance:
>>
>> http://gcc.gnu.org/ml/gcc
There is one g++ LTO test case (g++.lto/20090303) that fails on sparc,
it compiles the intermediate objects with -fPIC but the final
compilation creates an executable.
The problem is that when LTO re-instantiates the options for the
individual builds, the proper ASM specs of the target are not
ex
Ever since your changes installed on March 12th, I've been getting
fixincludes testsuite failures of the form below.
I also notice that none of these changes added ChangeLog entries, and
furthermore the SVN commit messages were extremely terse so it was
hard to diagnose the intent or reasoning be
From: Richard Henderson
Date: Tue, 16 Mar 2010 11:31:44 -0700
> On 03/12/2010 09:33 PM, David Miller wrote:
>> I couldn't figure out immediately how to fix this as the
>> way LTO does spec overriding and such looked non-trivial.
>
> It would not be a bad thing, I
From: Richard Henderson
Date: Tue, 16 Mar 2010 12:53:47 -0700
> On 03/16/2010 12:28 PM, David Miller wrote:
>> It's not the assemblers fault.
>>
>> We're using %hi() and expecting the assembler to emit a
>> PC relative relcation just bec
You said you would fix this several nights ago, but I still
haven't seen any changes to fixincludes since then.
When will you get around to fixing these regressions you
introduced?
Thank you.
From: Eric Botcazou
Date: Wed, 21 Jan 2009 15:22:19 +0100
> > Obviously the GCC folks broke backwards compatibility with themselves.
> > So unless we find evidence that contradicts the wiki page you cite, I
> > think GCC needs to be fixed.
>
> Yes, the SVR4 definition used to be masked by that o
From: Ian Lance Taylor
Date: Tue, 27 Jan 2009 13:16:31 -0800
> A co-worker of mine at Google did some experiments along those lines
> using gold. He was not able to demonstrate any performance
> improvements, unfortunately (x86_64 target, proprietary test cases).
> He was hacking linker scripts.
From: "Joseph S. Myers"
Date: Wed, 29 Feb 2012 17:17:17 + (UTC)
Thanks for looking into all of these issues.
> (c) Various functions do not set errno correctly (many cases) or raise the
> proper floating-point exceptions (a smaller number of cases - both
> spurious exceptions where not per
From: Jeff Law
Date: Wed, 14 Mar 2012 10:41:27 -0600
> The better performance with potential loss of accuracy is an across
> the board request, it's not just a sin/cos issue. All the trig, exp,
> pow, log, etc, which I don't think are necessarily covered by using
> the old x87 fp unit.
This is
On sparc a simple test like (from the PR tree-optimization/53410 testcase):
typedef int V __attribute__((vector_size (4 * sizeof (int;
typedef unsigned int W __attribute__((vector_size (4 * sizeof (int;
void
f10 (W *p, W *q)
{
*p = *p < (((const W) { 1U, 1U, 1U, 1U
From: Jakub Jelinek
Date: Mon, 29 Oct 2012 18:56:42 +0100
> I'd like to close the stage 1 phase of GCC 4.8 development
> on Monday, November 5th. If you have still patches for new features you'd
> like to see in GCC 4.8, please post them for review soon. Patches
> posted before the freeze, but
From: Eric Botcazou
Date: Mon, 29 Oct 2012 20:25:15 +0100
>> I'd like to get the Sparc cbcond stuff in (3 revisions posted) which
>> is waiting for Eric B. to do some Solaris specific work.
>>
>> I'd also like to enable LRA for at least 32-bit sparc, even if I can't
>> find the time to work on a
On 32-bit sparc with LRA enabled we have the following (this
generated for gcc.dg/vect/pr51581-4.c with -flto):
(insn 252 142 165 4 (set (reg:HI 234 [ D.1511 ])
(mem/c:HI (plus:SI (reg/f:SI 1307)
(const_int 24 [0x18])) [4 b+24 S2 A64])) test.c:23 59
{*movhi_insn}
(ex
Unlike the other variables that track the state of the current
instruction being analyzed by the LRA constraints code, I don't
see anything which initializes best_reload_nregs when we start
looking at a new instruction.
From: Richard Sandiford
Date: Mon, 29 Oct 2012 10:14:53 +
> ...given that the code is like you say written:
>
> if (SHIFT_COUNT_TRUNCATED)
> {
> if (CONST_INT_P (op1)
> ...
> else if (GET_CODE (op1) == SUBREG
> && subreg_lowpart_p (op1)
> &
Hello Eric, this is in regards to your HAVE_window_save code in
var-tracking.c and elsewhere added for PR target/48220.
I'm trying to fix all of the guality failures on sparc and this issue
below is the first one I was able to comprehend.
All of this special register window debugging handling in
From: David Miller
Date: Tue, 05 Feb 2013 18:18:39 -0500 (EST)
> The only other alternative I can see would be to get everything in
> var-tracking.c and the other subsystems it uses to do leaf register
> remapping, but that seems completely like the wrong way to handle
> this.
Fol
From: Eric Botcazou
Date: Wed, 06 Feb 2013 11:13:30 +0100
> I think testing crtl->uses_only_leaf_regs is sufficient here (and
> while you're at it, you could also test the value of
> HAVE_window_save, which can be 0 if -mflat is passed on the SPARC),
> so
>
> #ifdef HAVE_window_save
> if (HA
From: Jakub Jelinek
Date: Wed, 6 Feb 2013 07:56:44 +0100
> so achieving zero failures might be too hard
I don't believe this, all the sparc failures I see look
like a similar bug just showing up in multiple tests.
From: Jakub Jelinek
Date: Thu, 7 Feb 2013 18:22:32 +0100
> Then supposedly somewhere in dwarf2out we do some adjustment,
> but still end up with d/e loclist of:
> .LLST2:
> .uaxword.LVL0-.Ltext0 ! Location list begin address
> (*.LLST2)
> .uaxword.LVL1-.Ltext0
From: David Miller
Date: Thu, 07 Feb 2013 14:38:18 -0500 (EST)
> From: Jakub Jelinek
> Date: Thu, 7 Feb 2013 18:22:32 +0100
>
>> Then supposedly somewhere in dwarf2out we do some adjustment,
>> but still end up with d/e loclist of:
>> .LLST2:
>>
From: Jakub Jelinek
Date: Thu, 7 Feb 2013 20:43:32 +0100
> This and earlier patch are ok, if it bootstraps/regtests fine, and suitable
> ChangeLog entry is provided.
> Running gdb testsuite before and after wouldn't hurt though.
I've done all of this, and committed to trunk and the gcc-4.7 branc
From: David Miller
Date: Fri, 16 Nov 2012 00:33:05 -0500 (EST)
> From: Richard Sandiford
> Date: Mon, 29 Oct 2012 10:14:53 +
>
>> ...given that the code is like you say written:
>>
>> if (SHIFT_COUNT_TRUNCATED)
>> {
>> if (CONST_INT_
From: Richard Biener
Date: Wed, 13 Feb 2013 12:15:13 +0100
> On Tue, Feb 12, 2013 at 11:31 PM, David Miller wrote:
>> Maybe what we really mean to do here is check both op1 and SUBREG_REG
>> (op1) against SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P?
>
> Yes.
Ok, I'
From: Aurelien Jarno <[EMAIL PROTECTED]>
Date: Wed, 05 Mar 2008 21:52:14 +0100
> H. Peter Anvin a écrit :
> > The best would be if this could be controlled by a flag, which we can
> > flip once kernel fixes has been around for long enough.
>
> I have to agree there. Whatever the decision that gcc
From: "Richard Guenther" <[EMAIL PROTECTED]>
Date: Wed, 5 Mar 2008 22:40:59 +0100
> Right. So this problem is over-exaggerated. It's not like
> "any binary you create on that system will be broken on any
> other existing system."
I will be sure to hunt you down to help debug when someone report
From: Michael Matz <[EMAIL PROTECTED]>
Date: Wed, 5 Mar 2008 22:43:33 +0100 (CET)
> The error is arcane and happens seldomly if at all. And only on
> unfixed kernels.
Which translates right now into "all kernels."
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Thu, 6 Mar 2008 00:13:04 +0200
> On Wed, Mar 05, 2008 at 10:59:21PM +0100, Michael Matz wrote:
> > The problem is with old kernels, which by definition stay unfixed.
>
> Compiling older kernels with new gcc versions has never been supported.
Adrian we'
From: Michael Matz <[EMAIL PROTECTED]>
Date: Thu, 6 Mar 2008 00:07:39 +0100 (CET)
> The fix lies in the kernel, the work-around in gcc.
This depends upon how you interpret this ABI situation.
There is at least some agreement that how things have
actually been implemented by these kernels for mor
From: Ian Lance Taylor <[EMAIL PROTECTED]>
Date: Fri, 11 Apr 2008 11:04:38 -0700
> "Robert C. Seacord" <[EMAIL PROTECTED]> writes:
>
> >> What you really mean is,
> >> "Use an older GCC or some other compiler that is known not to
> >> take advantage of this optimization."
> >>
> > i think we
From: Chad Dougherty <[EMAIL PROTECTED]>
Date: Wed, 23 Apr 2008 07:52:26 -0400
> We won't include information about other vendors without either a
> statement from them or independent verification of their affectedness.
How, may I ask, did that policy apply to the GCC "vendor"
when this all go
From: Chad Dougherty <[EMAIL PROTECTED]>
Date: Wed, 23 Apr 2008 08:37:11 -0400
> David Miller wrote:
> > How, may I ask, did that policy apply to the GCC "vendor"
> > when this all got started?
>
> Our own testing of multiple versions of gcc on multiple pla
From: Joe Buck <[EMAIL PROTECTED]>
Date: Wed, 23 Apr 2008 08:24:44 -0700
> If CERT is to maintain its reputation, it needs to do better. The warning
> is misdirected in any case; given the very large number of compilers that
> these coding practices cause trouble for, you need to focus on the bad
From: "Steven Bosscher" <[EMAIL PROTECTED]>
Date: Sat, 21 Jun 2008 00:09:26 +0200
> What is far more worrying to me, actually, is that libjava grows
> bigger and bigger and bigger with every release, so that testing it
> costs developers who care zilch about java (i.e. most people) get
> penalized
From: Ralf Wildenhues <[EMAIL PROTECTED]>
Date: Sat, 21 Jun 2008 10:58:55 +0200
> Would that be compiles of object files that end up in libgcj (as opposed
> to the link, or stuff that depends on libgcj)? If yes, the lack of
> parallelism should be fixable.
It's the compilation of the object file
From: Laurent GUERBY <[EMAIL PROTECTED]>
Date: Sat, 21 Jun 2008 22:12:24 +0200
> I'm curious at how many GCC developpers use non x86/_64 as their
> main development machine (and how many non x86/_64 core they use).
I definitely am one.
Or, maybe you are asking the wrong question, which likely
sh
From: Laurent GUERBY <[EMAIL PROTECTED]>
Date: Sun, 22 Jun 2008 09:21:32 +0200
> On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:
> > From: Laurent GUERBY <[EMAIL PROTECTED]>
> > Date: Sat, 21 Jun 2008 22:12:24 +0200
> >
> > > I'm curious
From: Laurent GUERBY <[EMAIL PROTECTED]>
Date: Sun, 22 Jun 2008 10:05:26 +0200
> On Sun, 2008-06-22 at 00:45 -0700, David Miller wrote:
> > > How many core does your main development machine have?
> >
> > 8 cores and 8 cpu threads per core on one, 64 cpus total.
From: Mikulas Patocka <[EMAIL PROTECTED]>
Date: Wed, 25 Jun 2008 08:53:10 -0400 (EDT)
> Even worse, gcc doesn't use these additional bytes. If you try this:
>
> extern void f(int *i);
> void g()
> {
> int a;
> f(&a);
> }
>
> , it allocates additional 16 bytes for the variable "
From: "Bart Van Assche" <[EMAIL PROTECTED]>
Date: Thu, 26 Jun 2008 08:32:35 +0200
> On Thu, Jun 26, 2008 at 12:09 AM, David Miller <[EMAIL PROTECTED]> wrote:
> > The extra 16 bytes of space allocated is so that GCC can perform a
> > secondary reload of a quad
From: Mikulas Patocka <[EMAIL PROTECTED]>
Date: Wed, 2 Jul 2008 00:39:35 -0400 (EDT)
> The ABI is very vague about it. The V9 ABI just displays that 6-word space
> in a figure bug doesn't say anything about it's usage. The V8 ABI just
> says that "the function may write incoming arguments there"
From: Rainer Orth <[EMAIL PROTECTED]>
Date: Mon, 8 Sep 2008 17:18:50 +0200 (MEST)
> Eric Botcazou writes:
>
> > Confirmed (on Solaris 9). Would you mind opening a PR? There is already
> > one
> > for Linux (37344) but the failure is a little different. Thanks in advance.
>
> Sure, done: PR
From: Andrew Walrond <[EMAIL PROTECTED]>
Date: Wed, 12 Sep 2007 12:37:03 +0100
> I have to make buying decisions, and having tested a Sun T1000 for a
> while I am impressed with Suns hardware. But, we are 100% gnu/linux and
> it disturbs me that David Miller seems to be a (very i
From: Sunil Amitkumar Janki <[EMAIL PROTECTED]>
Date: Thu, 13 Sep 2007 11:16:00 +0200
> As far as I know, GCC for SPARC appears to be a front end
> to the Sun Studio compiler which happens to translate GCC
> flags to ones suitable for their own compiler.
That's correct, it's essentially GCC's lan
From: Andrew Walrond <[EMAIL PROTECTED]>
Date: Thu, 13 Sep 2007 15:02:08 +0100
> So, Sun really _don't_ give a damn about gnu/linux on sparc64.
That is a gross mischaracterization of the situation, don't
say this, it isn't true at all.
I have a full rack of Niagara systems that proves that Sun
c
From: Andrew Walrond <[EMAIL PROTECTED]>
Date: Fri, 14 Sep 2007 22:43:16 +0100
> And I apologise (to everyone) for any unnecessary rhetoric on my part; I
> freely admit that I designed my posts specifically to sparc (ahem) this
> debate, but I guess most of you knew that already ;)
The big issue
1 - 100 of 140 matches
Mail list logo
