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
On Wed, 2 Nov 2011, David Miller wrote:
> > ${host} is the *target* when configuring target libraries.
>
> It doesn't represent the 'target' we're generating code for in
> a multilib instance so we can conditionalize off of it correctly.
>
> The only way sparc/t-softfp can be added to tmake is i
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.
>
> ${host} is the *target* when confi
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 test x$$($(CC) -print-multi
On Wed, 2 Nov 2011, David Miller wrote:
> Is this the way differences between multilib cases are going to be
> handled now in libgcc, with these backtick shell conditionals that (of
> all things) looks at the destination directory?
>
> What if I want to put 64-bit libraries in a different locatio
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.
${host} is the *target* when configuring target libraries.
--
Joseph S. Myers
jos...@codesourcery.com
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 test x$$($(CC) -print-multi-os-directory) \
> + = x../lib64; then ech
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
Makefile.
Is thi
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 messages:
>> /tmp/cczMc4jN.s:16: Error:
On Wed, Nov 02, 2011 at 12:05:43PM -0500, Aldy Hernandez wrote:
>
> >I remember at least seeing middle-end pieces in alias analysis.
>
> Yes, but they're mechanical changes. Do you mean these?:
>
> @@ -1182,6 +1182,8 @@ ref_maybe_used_by_call_p_1 (gimple call,
> case BUILT_IN_MEMPCPY:
>
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:
Hi,
The sparc libgcc configure magic looks very
different on the head versus 4.6. sparc-rtems4.11
was not building because it was missing crti.
In 4.6, we got the makefile stub from sparc/t-crtin
but that no longer exists. It looks like the
rules are on t-sol2 now.
I made this change to libgc
On 11/02/2011 03:36 PM, David Miller wrote:
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 pseud
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
On 11/01/2011 02:59 PM, Hans-Peter Nilsson wrote:
> Please, when replying, also send to me, not just the list.
>
> On Tue, 1 Nov 2011, Paulo J. Matos wrote:
>> On 01/11/11 02:43, Hans-Peter Nilsson wrote:
>>>
>>> Not obvious or maybe I was unclear as to what I alluded?
>>> In the below insn-bodies
On 11/02/11 19:07, Rainer Orth wrote:
> Michael Haubenwallner writes:
>
>> Especially as i386 (from config.guess) is the default too.
>
> No, it's not, you're confusing the configure triplet with the default
> 32-bit arch. Since GCC 4.6, the default for Solaris/x86 is pentiumpro
> for Solaris
> Ian Lance Taylor writes:
>
>> Michael Haubenwallner writes:
>>
>>> But still: given that x86-solaris started with some Pentium, I just
>>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now.
>>>
>>> Especially as i386 (from config.guess) is the default too.
>>
>> I'm not sure w
Rainer Orth writes:
> Ian Lance Taylor writes:
>
>> Michael Haubenwallner writes:
>>
>>> But still: given that x86-solaris started with some Pentium, I just
>>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now.
>>>
>>> Especially as i386 (from config.guess) is the default too.
Ian Lance Taylor writes:
> Michael Haubenwallner writes:
>
>> But still: given that x86-solaris started with some Pentium, I just
>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now.
>>
>> Especially as i386 (from config.guess) is the default too.
>
> I'm not sure why you don't
Michael Haubenwallner writes:
> But still: given that x86-solaris started with some Pentium, I just
> can't believe gcc can "optimize" for real 80386 CPU on Solaris now.
>
> Especially as i386 (from config.guess) is the default too.
I'm not sure why you don't believe it. It is what I would expe
Michael Haubenwallner writes:
> Especially as i386 (from config.guess) is the default too.
No, it's not, you're confusing the configure triplet with the default
32-bit arch. Since GCC 4.6, the default for Solaris/x86 is pentiumpro
for Solaris 8/9 and pentium4 for Solaris 10 and beyond
(cf. gcc/
On 11/02/11 18:10, Jonathan Wakely wrote:
> On 2 November 2011 13:52, Michael Haubenwallner wrote:
>>
>> Erm - what I want to say is that I would really wonder if it does have /any/
>> influence (binary-wise) to gcc on Solaris (unlike Linux) whether to configure
>> for i386 or i586 (via '--host'
On 2 November 2011 13:52, Michael Haubenwallner wrote:
>
> Erm - what I want to say is that I would really wonder if it does have /any/
> influence (binary-wise) to gcc on Solaris (unlike Linux) whether to configure
> for i386 or i586 (via '--host' or even '--target').
http://gcc.gnu.org/gcc-4.5/c
I remember at least seeing middle-end pieces in alias analysis.
Yes, but they're mechanical changes. Do you mean these?:
@@ -1182,6 +1182,8 @@ ref_maybe_used_by_call_p_1 (gimple call,
case BUILT_IN_MEMPCPY:
case BUILT_IN_STPCPY:
case BUILT_IN_STPNCPY:
+case BU
>> It's redundant if you *want* to build for that host, but the whole
>> point is that building for i386 is usually a very bad idea, so
>> --host=i586-pc-solaris2.8 would be better.
>
> Erm - what I want to say is that I would really wonder if it does have
> /any/
> influence (binary-wise) to gcc
On 11/02/11 12:41, Jonathan Wakely wrote:
> On 2 November 2011 06:52, Michael Haubenwallner wrote:
>>
>> On 10/31/11 19:20, Jonathan Wakely wrote:
>>> On 31 October 2011 17:38, Rainer Orth wrote:
Dennis Clarke writes:
>>> I'm uncertain if Solaris 8/x86 still supports bare i386 mach
On 2 November 2011 06:52, Michael Haubenwallner wrote:
>
> On 10/31/11 19:20, Jonathan Wakely wrote:
>> On 31 October 2011 17:38, Rainer Orth wrote:
>>> Dennis Clarke writes:
>>>
>> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
>> might be better to keep the defau
>
> Actually, it is uname showing the 'i386' on Solaris:
> $ uname -p # Prints the current host's ISA or processor type.
> i386
> $ uname -i # Prints the name of the platform.
> i86pc
>
> So I'd wonder if '--host=i386-pc-solaris2.8' actually does make any
> difference h
On Wed, Nov 02, 2011 at 01:10:14PM +0400, Kirill Yukhin wrote:
> Actually I did not get the point.
> If we have no src/masking, destination must be unchanged until gather
> will write to it (at least partially)
> If we have all 1's in mask, scr must not be changed at all.
> So, nullification in int
Hi Jakub,
Actually I did not get the point.
If we have no src/masking, destination must be unchanged until gather
will write to it (at least partially)
If we have all 1's in mask, scr must not be changed at all.
So, nullification in intrinsics just useless.
Having such snippet:
(1) vmovdqa k(
30 matches
Mail list logo
