Re: _mm{,256}_i{32,64}gather_{ps,pd,epi32,epi64} intrinsics semantics

[Kirill Yukhin]

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(%rax,%rax), %ymm1
(2)   vmovaps %ymm0, %ymm6
(3)   vmovaps %ymm0, %ymm2
(4)   vmovdqa k+32(%rax,%rax), %ymm3
(5)   vgatherdps  %ymm6, vf1(,%ymm1,4), %ymm2

Looks pretty strange. Which value has ymm0? If it has all zeroes, then
(1)-(5) is dead code, which may be just removed.
If contains all 1s then (2) s useless.
But again, seems I did not get your point...

Thanks, K

Re: _mm{,256}_i{32,64}gather_{ps,pd,epi32,epi64} intrinsics semantics

[Jakub Jelinek]

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 intrinsics just useless.
> Having such snippet:
> (1)   vmovdqa k(%rax,%rax), %ymm1
> (2)   vmovaps %ymm0, %ymm6
> (3)   vmovaps %ymm0, %ymm2
> (4)   vmovdqa k+32(%rax,%rax), %ymm3
> (5)   vgatherdps  %ymm6, vf1(,%ymm1,4), %ymm2
> 
> Looks pretty strange. Which value has ymm0? If it has all zeroes, then
> (1)-(5) is dead code, which may be just removed.
> If contains all 1s then (2) s useless.

%ymm0 is all ones (this is code from the auto-vectorization).
(2) is not useless, %ymm6 contains the mask, for auto-vectorization
(3) is useless, it is there just because the current gather insn patterns
always use the previous value of the destination register.
Because if vgatherdps above doesn't segfault, the whole register will
be overwritten, and if it does segfault, nothing anywhere says that
the scalar code was supposed to be vectorized through vgatherdps and
what the destination register should contain.

My question was about the intrinsics.  If user writes something like
the proglet below, can he have any expectations on what will be the content
of the destination register of the vgather* insn that crashed (e.g. if
the segfault handler decides to skip the vpgather* insn and longjmps
to the next insn)?  Currently 0 would be put there, because avx2intrin.h
uses there src { 0, 0 ... } and mask { -1, -1 ... }.

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

__m256i a, b;
long long c[3] = { 64, 65, 66 };

void
segv (int signum, siginfo_t *info, void *ctx)
{
  struct ucontext *uc = (struct ucontext *) ctx;
  gregset_t *gregs = &uc->uc_mcontext.gregs;
  unsigned char *eip = (unsigned char *)gregs[REG_RIP];
  printf ("%x\n", eip);
  exit (0);
}

int
main ()
{
  struct sigaction sa;
  sa.sa_sigaction = segv;
  sigemptyset (&sa.sa_mask);
  sa.sa_flags = SA_SIGINFO;
  if (sigaction (SIGSEGV, &sa, NULL) != 0)
return 1;
  b = _mm256_set_epi64x ((uintptr_t) & c[0], (uintptr_t) & c[1],
 (uintptr_t) NULL, (uintptr_t) & c[2]);
  a = _mm256_i64gather_epi64 (NULL, b, 1);
  printf ("%lx %lx %lx %lx\n",
  ((long long *) &a)[0], ((long long *) &a)[1],
  ((long long *) &a)[2], ((long long *) &a)[3]);
  return 0;
}

BTW, sde doesn't seem to work here as documented for the insn,
TID0: Read 0x42 = *(UINT64*)0x6009f0
TID0: Read 0x42 = *(UINT64*)0
TID0: Read 0x41 = *(UINT64*)0x6009e8
TID0: Read 0x40 = *(UINT64*)0x6009e0
TID0: INS 0x00400523 vpgatherqq ymm0, qword ptr 
[rax+ymm1*1], ymm2
TID0:   YMM0 := _0040__0041
   __0042__0042
Or did I misunderstand the documentation and the insn isn't supposed
to segfault?

And, if user can't expect anything in the register because
the intrinsics doesn't even have any src/mask arguments,
what about if
  a = _mm256_i64gather_epi64 (NULL, b, 1);
in the testcase is replaced with:
  __m256i d, e;
  d = _mm256_set_epi64x (1, 2, 3, 4);
  e = _mm256_set_epi64x (-1, -1, -1, -1);
  a = _mm256_mask_i64gather_epi64 (d, NULL, b, e, 1);
Again, does the intrinsics (as opposed to hw insn) make any guarantees
on what will be in the register after the segfault?  Does the
compiler have to load the destination of vpgather* insn register with
the { 1LL, 2LL, 3LL, 4LL } vector before the insn or is it free to
optimize that away as it can see the mask loads all values?

Can you ask what ICC does here and what the intrinsics semantics
should be?

Jakub

Re: # of unexpected failures 768 ?

[Dennis Clarke]

>
> 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 here.
>
> Just my 2 cents.

no prob.

Actually on Solaris you will always get 'i386' even if you are running on
a top of the line AMD Opteron 16-core machine with 8 sockets. It still
reports that it is a i386 and not x86_64 or even amd64.

Now isainfo and isalist are a whole other matter. Personally I'd like to
see conffigure take advantage of that data as it is much more rich.

On sparc you get this sort of data :

# isalist -a
sparcv9+vis sparcv9 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld
sparcv7 sparc
# isainfo -v
64-bit sparcv9 applications
32-bit sparc applications

On some old pentium box you get this :

Sun Microsystems Inc.   SunOS 5.8   Generic February 2000
$
$ isalist -a
pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
$ isainfo -v
32-bit i386 applications
$

Dennis


-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke   | Solaris and Linux and Open Source |
| dcla...@blastwave.org   | Respect for open standards.   |
+-+---+

Re: # of unexpected failures 768 ?

[Jonathan Wakely]

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 default of pentiumpro instead.
>
> Solaris 8 won't run on anything less than pentium, I recently
> convinced someone else to stop building GCC for i386 on Solaris:
>
> http://gcc.gnu.org/ml/gcc-help/2011-10/msg5.html
>>
>> Quite.  In fact there are *very* good reasons not to configure for
>> 80386: libstdc++'s configure uses the default arch being configured
>> for, and disables a number of features on i386 because it doesn't
>> support the required atomic ops.
>>
>> So by configuring for i386 you will distribute a GCC package that is
>> missing useful features, but supports an ancient architecture that
>> Solaris doesn't even run on.
>>
>> You should configure for pentium-pc-solaris2.8 or use --with-arch-32=pentium
>
> When not configuring with '--host=i386-pc-solaris2.8', it is config.guess
> that detects 'i386-pc-solaris2.8', just tried here with most recent
> config.guess on i86pc Solaris2.10, result is 'i386-pc-solaris2.10'.
>
> 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 here.

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.

Re: # of unexpected failures 768 ?

[Michael Haubenwallner]

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 machines, so it
>>> might be better to keep the default of pentiumpro instead.
>>
>> Solaris 8 won't run on anything less than pentium, I recently
>> convinced someone else to stop building GCC for i386 on Solaris:
>>
>> http://gcc.gnu.org/ml/gcc-help/2011-10/msg5.html
>>>
>>> Quite.  In fact there are *very* good reasons not to configure for
>>> 80386: libstdc++'s configure uses the default arch being configured
>>> for, and disables a number of features on i386 because it doesn't
>>> support the required atomic ops.
>>>
>>> So by configuring for i386 you will distribute a GCC package that is
>>> missing useful features, but supports an ancient architecture that
>>> Solaris doesn't even run on.
>>>
>>> You should configure for pentium-pc-solaris2.8 or use --with-arch-32=pentium
>>
>> When not configuring with '--host=i386-pc-solaris2.8', it is config.guess
>> that detects 'i386-pc-solaris2.8', just tried here with most recent
>> config.guess on i86pc Solaris2.10, result is 'i386-pc-solaris2.10'.
>>
>> 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 here.
> 
> 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 Solaris (unlike Linux) whether to configure
for i386 or i586 (via '--host' or even '--target').

/haubi/

Re: # of unexpected failures 768 ?

[Dennis Clarke]

>> 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 Solaris (unlike Linux) whether to
> configure
> for i386 or i586 (via '--host' or even '--target').
>


Oh, well, that would be a worthwhile experiment I think.

dc


-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke   | Solaris and Linux and Open Source |
| dcla...@blastwave.org   | Respect for open standards.   |
+-+---+

Re: Potentially merging the transactional-memory branch into mainline.

[Aldy Hernandez]

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 BUILT_IN_TM_MEMCPY:
+case BUILT_IN_TM_MEMMOVE:

etc, etc.


I'd like to see some breakdown into subsystem patches.  Can someone provide
those together with changelog entries?


I've done another merge this morning, and here is the master patchset 
divided up by subsystems.  ChangeLog entries at the top.  Testsuite 
changes at the bottom:


http://quesejoda.com/redhat/tm-branch-diffs-from-trunk-at-180744/

p.s. libstdc++-v3 changelog entries are actually in the toplevel 
ChangeLog.tm.  I can move these if it bothers someone.

Re: # of unexpected failures 768 ?

[Jonathan Wakely]

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/changes.html#x86 doesn't say it only
happens on GNU/Linux.

Re: # of unexpected failures 768 ?

[Michael Haubenwallner]

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' or even '--target').
> 
> http://gcc.gnu.org/gcc-4.5/changes.html#x86 doesn't say it only
> happens on GNU/Linux.

Oh my dear... thank you!

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.

/haubi/

Re: # of unexpected failures 768 ?

[Rainer Orth]

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/config.gcc).

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: # of unexpected failures 768 ?

[Ian Lance Taylor]

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 expect.

If we want to make this work more normally for ordinary users, I think
the right thing to do would be to patch config.guess to compute a better
value for the build system CPU on Solaris systems.

Ian

Re: # of unexpected failures 768 ?

[Rainer Orth]

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 believe it.  It is what I would expect.
>
> If we want to make this work more normally for ordinary users, I think
> the right thing to do would be to patch config.guess to compute a better
> value for the build system CPU on Solaris systems.

Please no: alpha went this route, and the consequence is that your
self-built gcc will generate code for the build system.  This breaks
completely if you have a heterogeneous collection of systems, and the
GCC build system isn't the least common denominator of them.  This
single-system mindset creates unnecessary trouble in this scenario.
GCC's configure has enough control over the default target CPU, even
without messing with config.guess, and most other programs won't care
about this at all.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: # of unexpected failures 768 ?

[Ian Lance Taylor]

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.
>>
>> I'm not sure why you don't believe it.  It is what I would expect.
>>
>> If we want to make this work more normally for ordinary users, I think
>> the right thing to do would be to patch config.guess to compute a better
>> value for the build system CPU on Solaris systems.
>
> Please no: alpha went this route, and the consequence is that your
> self-built gcc will generate code for the build system.  This breaks
> completely if you have a heterogeneous collection of systems, and the
> GCC build system isn't the least common denominator of them.  This
> single-system mindset creates unnecessary trouble in this scenario.
> GCC's configure has enough control over the default target CPU, even
> without messing with config.guess, and most other programs won't care
> about this at all.

Oh, I completely agree that it would be wrong to have config.guess
produce the exact CPU used on the build system.

But having config.guess produce "i386" for an OS which does not even run
on a vanilla i386 is also wrong.  A much better choice here would be the
earliest CPU value which the OS actually supports.

Ian

Re: # of unexpected failures 768 ?

[Dennis Clarke]

> 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 believe it.  It is what I would expect.
>>
>> If we want to make this work more normally for ordinary users, I think
>> the right thing to do would be to patch config.guess to compute a better
>> value for the build system CPU on Solaris systems.
>
> Please no: alpha went this route, and the consequence is that your
> self-built gcc will generate code for the build system.  This breaks
> completely if you have a heterogeneous collection of systems, and the
> GCC build system isn't the least common denominator of them.  This
> single-system mindset creates unnecessary trouble in this scenario.
> GCC's configure has enough control over the default target CPU, even
> without messing with config.guess, and most other programs won't care
> about this at all.
>
>

Personally I am all for "it ain't broke, don't fix it".

Dennis



-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke   | Solaris and Linux and Open Source |
| dcla...@blastwave.org   | Respect for open standards.   |
+-+---+

Re: # of unexpected failures 768 ?

[Michael Haubenwallner]

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 8/9 and pentium4 for Solaris 10 and beyond
> (cf. gcc/config.gcc).

I've meant the default "i386-pc-solaris2.*" target triplet from config.guess,
not the default 32bit arch - which always is some pentium as I've expected
(and tried to say before).

Reading [1], it really doesn't make any difference on Solaris to configure for
"i386-pc-solaris2.*" or (up to) "i786-pc-solaris2.*" target triplet, the 32bit
arch default is controlled by the solaris version (and '--with-arch-32') only.

But yes, for platforms not explicitly specifying a default $with_arch_32,
that default value is calculated [2] from the cpu-part of the target-triplet.

[1] 
http://gcc.gnu.org/viewcvs/trunk/gcc/config.gcc?view=markup&pathrev=180775#l1312
[2] 
http://gcc.gnu.org/viewcvs/trunk/gcc/config.gcc?view=markup&pathrev=180775#l2831

/haubi/

Re: approaches to carry-flag modelling in RTL

[Richard Henderson]

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, "sub" is the insn that sets cc0 as a
>>> side-effect.
>>>
>>> Supposed canonical form :
>>>
>>> (parallel
>>>   [(set cc_reg) (compare ...))
>>>(set destreg) (sub ...))])
>>> and:
>>> (parallel
>>>   [(set destreg) (sub ...))
>>>(clobber cc_reg)])
> 
>> That is very strange because if you look into RX or MN10300, they all have 
>> the
>> set REG_CC as the last in the parallel.

Yes.  The cc_reg last there is a consequence of the post-reload compare-elim 
pass.
Which wants to splat the CC set on top of the clobber.  Thus it must be last.

> That'd be a good reason to flip the default...except that the
> i386 has it the other way round i.e. as shown above.  I think
> the main reason is that it just seemed right to those port
> authors.

Frankly, I'd prefer to flip the default.  It does seem to make the most sense.
We shan't do that until we tackle...

> I'm still thinking of a generic md iterator mechanism (one that
> doesn't restrict the form of the expansion in ways getting in
> the way with expanding to both a clobber and a set, and in
> swapped locations as above), to make the troubles go away...
> But maybe expanding them by a pass through e.g. m4 would be
> better than cooking up something new there.

... this, so that it can all be done automatically.

I think some sort of iterator mechanism is best, much like we
automate cond_exec and other sorts of macro-izations.

I can imagine a sort of

(define_insn_with_flags "name"
  [(set ...)
   (set (reg:cc) (...)]
  ""
  ...)

where we automatically expand to

(define_insn "name"
  [(set ...)
   (clobber (reg:cc))]
  ...)

(define_insn "name_flags"
  [(set ...)
   (set (reg:cc) (...)]
  ...)

or something like that.


r~

serious libgcc regression added recently

[David Miller]

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/lb1spc.S:134: Error: detected global 
register use not covered by .register pseudo-op
...

It looks like it's trying to build 32-bit sparc files during the -m64
64-bit multiarch build or similar.  Or, alternatively, doing the
32-bit multiarch build with 64-bit options.

And others have reported link failures during the testsuite on
other targets.

Rainer it seems it might be your changes?

Re: serious libgcc regression added recently

[Joel Sherrill]

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 pseudo-op
../../../../gcc/libgcc/config/sparc/lb1spc.S:134: Error: detected global 
register use not covered by .register pseudo-op
...

It looks like it's trying to build 32-bit sparc files during the -m64
64-bit multiarch build or similar.  Or, alternatively, doing the
32-bit multiarch build with 64-bit options.

And others have reported link failures during the testsuite on
other targets.


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: Error: Hardware capability "mul32" not enabled for 
"smul".
/tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for 
"umul".


I can prepare a PR if you think it is different.

Rainer it seems it might be your changes?



--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

libgcc sparc-rtems config on gcc head

[Joel Sherrill]

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 libgcc/config.host and
it is getting further.  Does this look like
what the intended change?

Index: config.host
===
--- config.host(revision 180798)
+++ config.host(working copy)
@@ -1028,7 +1028,7 @@
 md_unwind_header=sparc/linux-unwind.h
 ;;
 sparc-*-rtems*)
-tmake_file="sparc/t-elf t-crtfm t-rtems t-fdpbit"
+tmake_file="sparc/t-elf t-crtfm t-sol2 t-rtems t-fdpbit"
 extra_parts="$extra_parts crti.o crtn.o crtfastmath.o"
 ;;
 sparc*-*-solaris2*)

--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: serious libgcc regression added recently

[David Miller]

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: Error: Hardware capability "mul32" not enabled for
> "smul".
> /tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for
> "umul".
> 
> I can prepare a PR if you think it is different.

I don't think so.  The bug I'm hitting seems to be simply that
config/sparc/t-linux64 wasn't migrated up into the libgcc configure
area properly the way that config/sparc/t-linux was.

I'm working on a fix right now.

Re: Potentially merging the transactional-memory branch into mainline.

[Jakub Jelinek]

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:
>   case BUILT_IN_STPCPY:
>   case BUILT_IN_STPNCPY:
> +case BUILT_IN_TM_MEMCPY:
> +case BUILT_IN_TM_MEMMOVE:
> 
> etc, etc.
> 
> >I'd like to see some breakdown into subsystem patches.  Can someone provide
> >those together with changelog entries?
> 
> I've done another merge this morning, and here is the master
> patchset divided up by subsystems.  ChangeLog entries at the top.
> Testsuite changes at the bottom:
> 
> http://quesejoda.com/redhat/tm-branch-diffs-from-trunk-at-180744/
> 
> p.s. libstdc++-v3 changelog entries are actually in the toplevel
> ChangeLog.tm.  I can move these if it bothers someone.

Could you please fix up whitespace in the patch, at least leading tabs
and trailing whitespace?
On the patch it is easy to do, something like:
sed 's/^+\([\t]*\) \{64\}/+\1\t\t\t\t\t\t\t\t/;s/^+\([\t]*\) 
\{32\}/+\1\t\t\t\t/;s/^+\([\t]*\) \{16\}/+\1\t\t/;s/^+\([\t]*\) 
\{8\}/+\1\t/;s/^+\(.*[^[:blank:]]\)[[:blank:]]\+$/+\1/;s/^+[[:blank:]]\+$/+/' 
patch > patch.whitespace
and then interdiff patch patch.whitespace > whitespace
and review that diff and if appropriate commit to branch before merging?

Jakub

Re: serious libgcc regression added recently

[David Miller]

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: Hardware capability "mul32" not enabled for
>> "smul".
>> /tmp/cczMc4jN.s:18: Error: Hardware capability "mul32" not enabled for
>> "smul".
>> /tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for
>> "umul".
>> 
>> I can prepare a PR if you think it is different.
> 
> I don't think so.  The bug I'm hitting seems to be simply that
> config/sparc/t-linux64 wasn't migrated up into the libgcc configure
> area properly the way that config/sparc/t-linux was.

Actually the problem is that libgcc/config.host checks ${host}
to decide whether to append config/sparc/t-softmul to the tmake
variable.

But when multilibbing 64-bit libraries on a 32-bit hosted build
configured with --enable-targets=all, the host will be sparc-*-linux
even when building the 64-bit libgcc.

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.

And it will do the wrong thing in the opposite case too, when building
a 64-bit hosted sparc gcc, host will be sparc64-*-* when building the
multilib 32-bit libgcc, and in that cast config.host will not append
t-softfp even when it should.

I sure wish these changes got a lot more testing before they were
installed :-/

Re: serious libgcc regression added recently

[David Miller]

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 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 location such as
plain 'lib/' to create a 64-bit pure system or similar?

I definitely prefer how this stuff worked beforehand wherein we would
know the actual "target" we're building for and we bring in the
appropriate "target" makefile fragments based upon that "target".

Now we just seem to look at the host and essentially include every
possible target makefile that could be multilibbed out of that host.

diff --git a/libgcc/config.host b/libgcc/config.host
index 05f084b..47e0e73 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1052,7 +1052,8 @@ sparc64-*-freebsd*|ultrasparc-*-freebsd*)
;;
 sparc64-*-linux*)  # 64-bit SPARC's running GNU/Linux
extra_parts="$extra_parts crtfastmath.o"
-   tmake_file="${tmake_file} t-crtfm sparc/t-linux sparc/t-linux64"
+   tmake_file="${tmake_file} t-crtfm sparc/t-linux sparc/t-linux64 \
+sparc/t-softmul"
md_unwind_header=sparc/linux-unwind.h
;;
 sparc64-*-netbsd*)
diff --git a/libgcc/config/sparc/t-softmul b/libgcc/config/sparc/t-softmul
index 7142200..5489a37 100644
--- a/libgcc/config/sparc/t-softmul
+++ b/libgcc/config/sparc/t-softmul
@@ -1,2 +1,4 @@
-LIB1ASMSRC = sparc/lb1spc.S
-LIB1ASMFUNCS = _mulsi3 _divsi3 _modsi3
+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 echo _mulsi3 _divsi3 _modsi3; fi`

Re: serious libgcc regression added recently

[Andrew Pinski]

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 echo _mulsi3 _divsi3 _modsi3; fi`
>

-print-multi-directory is most likely easier to handle than os-directory.

Thanks,
Andrew Pinski

Re: serious libgcc regression added recently

[Joseph S. Myers]

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

Re: serious libgcc regression added recently

[Joseph S. Myers]

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 location such as
> plain 'lib/' to create a 64-bit pure system or similar?

See my review  
suggesting a followup to improve on the logic that was carried from the 
gcc/ directory.

> I definitely prefer how this stuff worked beforehand wherein we would
> know the actual "target" we're building for and we bring in the
> appropriate "target" makefile fragments based upon that "target".

Previously, makefile variables in the gcc/ directory had to be set just 
once and could not depend on the multilib, only on the target triplet - 
hence the `` code.

Now, because the variables are set in the libgcc directory which is 
configured separately for each multilib, it is possible for the makefile 
fragment selected to depend on the multilib as well as the target triplet, 
in a way it couldn't before.  This is a clear improvement.

Note that all these patches were posted at least two months ago with calls 
for testers, so there was plenty of time for target maintainers to review 
and test them for their targets.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: serious libgcc regression added recently

[David Miller]

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-os-directory) \
>> +                       = x../lib64; then echo _mulsi3 _divsi3 _modsi3; fi`
>>
> 
> -print-multi-directory is most likely easier to handle than os-directory.

I was just copying the construct Rainer was already using in
sparc/t-linux64 :-)

Re: serious libgcc regression added recently

[David Miller]

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 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 if the host
matches sparc-*-* and that's what happens even when we're building
the 64-bit libgcc in my case.

It's sparc-*-* for both the 32-bit and 64-bit libgcc builds.

Re: serious libgcc regression added recently

[Joseph S. Myers]

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 if the host
> matches sparc-*-* and that's what happens even when we're building
> the 64-bit libgcc in my case.
> 
> It's sparc-*-* for both the 32-bit and 64-bit libgcc builds.

Yes, there is nothing new there - when this configuration was in the gcc/ 
directory the target name was also the same for both builds.  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 the 
choice of t-* files to depend on the multilib.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: serious libgcc regression added recently

[David Miller]

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 the choice of t-* files to depend on the
> multilib.

That works for me, I'm bootstrapping the following:


[PATCH] Fix multilib build of libgcc on Linux/sparc.

* configure.ac: Set host_address on sparc too.
* configure: Regenerate.
* config.host: Add sparc/t-linux64 and sparc/t-softmul conditionally
based upon host_address.
* config/sparc/t-linux64: Set CRTSTUFF_T_CFLAGS unconditionally.
---
 libgcc/ChangeLog  |8 
 libgcc/config.host|   17 ++---
 libgcc/config/sparc/t-linux64 |3 +--
 libgcc/configure  |7 ---
 libgcc/configure.ac   |7 ---
 5 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index 1bbe29a..3944193 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,11 @@
+2011-11-02  David S. Miller  
+
+   * configure.ac: Set host_address on sparc too.
+   * configure: Regenerate.
+   * config.host: Add sparc/t-linux64 and sparc/t-softmul conditionally
+   based upon host_address.
+   * config/sparc/t-linux64: Set CRTSTUFF_T_CFLAGS unconditionally.
+
 2011-11-02  Rainer Orth  
 
* gthr-single.h, gthr.h: New files.
diff --git a/libgcc/config.host b/libgcc/config.host
index 05f084b..647c6a1 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1008,7 +1008,10 @@ sparc-*-elf*)
extra_parts="$extra_parts crti.o crtn.o crtfastmath.o"
;;
 sparc-*-linux*)# SPARC's running GNU/Linux, libc6
-   tmake_file="${tmake_file} t-crtfm sparc/t-linux64"
+   tmake_file="${tmake_file} t-crtfm"
+   if test "${host_address}" = 64; then
+   tmake_file="$tmake_file sparc/t-linux64"
+   fi
case ${host} in
*-leon*)
tmake_file="${tmake_file} t-fdpbit"
@@ -1021,7 +1024,9 @@ sparc-*-linux*)   # SPARC's running GNU/Linux, 
libc6
*-leon[3-9]*)
;;
*)
-   tmake_file="$tmake_file sparc/t-softmul"
+   if test "${host_address}" = 32; then
+   tmake_file="$tmake_file sparc/t-softmul"
+   fi
;;
esac
extra_parts="$extra_parts crtfastmath.o"
@@ -1052,7 +1057,13 @@ sparc64-*-freebsd*|ultrasparc-*-freebsd*)
;;
 sparc64-*-linux*)  # 64-bit SPARC's running GNU/Linux
extra_parts="$extra_parts crtfastmath.o"
-   tmake_file="${tmake_file} t-crtfm sparc/t-linux sparc/t-linux64"
+   tmake_file="${tmake_file} t-crtfm sparc/t-linux"
+   if test "${host_address}" = 64; then
+   tmake_file="${tmake_file} sparc/t-linux64"
+   fi
+   if test "${host_address}" = 32; then
+   tmake_file="${tmake_file} sparc/t-softmul"
+   fi
md_unwind_header=sparc/linux-unwind.h
;;
 sparc64-*-netbsd*)
diff --git a/libgcc/config/sparc/t-linux64 b/libgcc/config/sparc/t-linux64
index ca4a892..6583fe2 100644
--- a/libgcc/config/sparc/t-linux64
+++ b/libgcc/config/sparc/t-linux64
@@ -1,2 +1 @@
-CRTSTUFF_T_CFLAGS = `if test x$$($(CC) -print-multi-os-directory) \
-   = x../lib64; then echo -mcmodel=medany; fi`
+CRTSTUFF_T_CFLAGS = -mcmodel=medany
diff --git a/libgcc/configure b/libgcc/configure
index 0d91645..0f18037 100644
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -4609,11 +4609,12 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $libgcc_cv_cfi" >&5
 $as_echo "$libgcc_cv_cfi" >&6; }
 
-# Check 32bit or 64bit for x86.
+# Check 32bit or 64bit for x86 and sparc.
 case ${host} in
-i?86*-*-* | x86_64*-*-*)
+i?86*-*-* | x86_64*-*-* | sparc*-*-*)
   cat > conftest.c < conftest.c <