Relational Association Programming Paradigm

[Aaron Abassi]

GCC mailing list readers;

I am seeking persons interested in reviewing a proposed programming
paradigm called Relational Association Programming (RAP).
This paradigm complements the procedural programming paradigm with
modular emphasis.
The C programming language natively supports RAP which is demontrated
in the RAP-C package.
I believe this paradigm will be well suited to complex real time and
high performance systems requiring function group abstractions.
It retains full backwards compatiblity with classical procedural
programming since it is a complementary paradigm.

Paradigm documentation and nomenclature reference
http://rapp.sourceforge.net/RAP.PDF

C sample implementation and example code
http://rapp.sourceforge.net/RAP-C.PDF

SourceFORGE web page
http://rapp.sourceforge.net/

I request that reviewers focus their comments and/or dissertations on
the science behind the paradigm's model.  Please send them to my email
address to keep this mailing list on topic.  Richard Stallman
suggested I send this request on this list so please don't flame me
about my own message being off topic.

Thank you in advance,
  Aaron Sami Abassi

Re: How can I increase the default alignment of complex float?

[Ian Lance Taylor]

"H.J. Lu"  writes:

> On Thu, Mar 31, 2011 at 9:14 PM, Ian Lance Taylor  wrote:
>> "H.J. Lu"  writes:
>>
>>> I'd like to bump the default alignment of complex float from 4 byte
>>> to 8 byte.  ADJUST_ALIGNMENT doesn't work since SC is a stand
>>> mode. Is that OK to update mode_base_align directly?
>>
>> No, that would change every target.  I think you have to change
>> DATA_ALIGNMENT, CONSTANT_ALIGNMENT, and LOCAL_ALIGNMENT.
>>
>
> I need something similar to what ADJUST_ALIGNMENT does, i.e.,
> set the default alignment of SCmode.

Why?

Ian

Relational Association Programming

[Aaron Abassi]

GCC mailing list readers;

I am seeking persons interested in reviewing a proposed programming
paradigm called Relational Association Programming (RAP).
This paradigm complements the procedural programming paradigm with
modular emphasis.
The C programming language natively supports RAP which is demontrated
in the RAP-C package.
I believe this paradigm will be well suited to complex real time and
high performance systems requiring function group abstractions.
It retains full backwards compatiblity with classical procedural
programming since it is a complementary paradigm.

Paradigm documentation and nomenclature reference
http://rapp.sourceforge.net/RAP.PDF

C sample implementation and example code
http://rapp.sourceforge.net/RAP-C.PDF

SourceFORGE web page
http://rapp.sourceforge.net/

I request that reviewers focus their comments and/or dissertations on
the science behind the paradigm's model.  Please send them to my email
address to keep this mailing list on topic.  Richard Stallman
suggested I send this request on this list so please don't flame me
about my own message being off topic.

Thank you in advance,
  Aaron Sami Abassi

Re: How can I increase the default alignment of complex float?

[H.J. Lu]

On Thu, Mar 31, 2011 at 9:14 PM, Ian Lance Taylor  wrote:
> "H.J. Lu"  writes:
>
>> I'd like to bump the default alignment of complex float from 4 byte
>> to 8 byte.  ADJUST_ALIGNMENT doesn't work since SC is a stand
>> mode. Is that OK to update mode_base_align directly?
>
> No, that would change every target.  I think you have to change
> DATA_ALIGNMENT, CONSTANT_ALIGNMENT, and LOCAL_ALIGNMENT.
>

I need something similar to what ADJUST_ALIGNMENT does, i.e.,
set the default alignment of SCmode.

-- 
H.J.

Re: How can I increase the default alignment of complex float?

[Ian Lance Taylor]

"H.J. Lu"  writes:

> I'd like to bump the default alignment of complex float from 4 byte
> to 8 byte.  ADJUST_ALIGNMENT doesn't work since SC is a stand
> mode. Is that OK to update mode_base_align directly?

No, that would change every target.  I think you have to change
DATA_ALIGNMENT, CONSTANT_ALIGNMENT, and LOCAL_ALIGNMENT.

Ian

How can I increase the default alignment of complex float?

[H.J. Lu]

Hi,

I'd like to bump the default alignment of complex float from 4 byte
to 8 byte.  ADJUST_ALIGNMENT doesn't work since SC is a stand
mode. Is that OK to update mode_base_align directly?

Thanks.

-- 
H.J.

gcc-4.5-20110331 is now available

[gccadmin]

Snapshot gcc-4.5-20110331 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110331/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch 
revision 171802

You'll find:

 gcc-4.5-20110331.tar.bz2 Complete GCC (includes all of below)

  MD5=3981a1e6e557f68985a164734bc4434e
  SHA1=479bcd115191674f2272d2ae746a88a192ccd913

 gcc-core-4.5-20110331.tar.bz2C front end and core compiler

  MD5=fd57954f49e5b732c7ccffb8eba3c47e
  SHA1=13284b343f71f44a2f8f821c43171b60af3b96d9

 gcc-ada-4.5-20110331.tar.bz2 Ada front end and runtime

  MD5=c864e463d2bdd871bb5f3040c95634b0
  SHA1=356732e22f537848cb63ddcaa127efde97c56217

 gcc-fortran-4.5-20110331.tar.bz2 Fortran front end and runtime

  MD5=6fafe59d23ff0225c4aab9d372925157
  SHA1=717f5764a238868fc625f48c5a9bec11480ec81e

 gcc-g++-4.5-20110331.tar.bz2 C++ front end and runtime

  MD5=89584bc2603dc8ea875399be1a2ecc5e
  SHA1=4b5eef6a389096752e730ec6fda52449c6a8b28c

 gcc-go-4.5-20110331.tar.bz2  Go front end and runtime

  MD5=3301f7923f8920b4ca848696de7f44cb
  SHA1=a05f797beeb077b168fe860dfb1d008e65279d42

 gcc-java-4.5-20110331.tar.bz2Java front end and runtime

  MD5=8dc82f397294c899b6b088a9ba14d1af
  SHA1=8c8f5b372967a36c01e3174e7fcdcce0696eb368

 gcc-objc-4.5-20110331.tar.bz2Objective-C front end and runtime

  MD5=1525f5315a5958e6e4da71852d577514
  SHA1=93e98f4a31ae8ff88f6ba91520f85280bb3c0e3a

 gcc-testsuite-4.5-20110331.tar.bz2   The GCC testsuite

  MD5=5195c303722b68e17019e46ef9971f31
  SHA1=68644fd71b6bfd792efb96242502580441c5933f

Diffs from 4.5-20110324 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Question about Temporary Outputs

[Ian Lance Taylor]

"Iyer, Balaji V"  writes:

>I see in GCC that when we use the flag "-f-tree-optimized" it 
> will dump the contents of the input file after doing all the tree-based 
> optimization. Is it possible for me to modify this file and then submit it 
> back into gcc for processing to create an executable/assembly dump?

Not directly, no.

There is some ongoing work on the GIMPLE frontend which would permit
this to occur.  http://gcc.gnu.org/wiki/GimpleFrontEnd .  I don't know
if the project has any specific schedule.

(Note that due to licensing requirements you would not in general be
permitted to modify the file using proprietary code and then distribute
the resulting program.)

Ian

Re: GCC 4.6.0 Released

[Dennis Clarke]

> Dennis Clarke  writes:
>
>>> The only caveat are strange errors with gmake:
>>>
>>> make[3]: write error
>>>
>>> See CR 6938116  GNU make highly unreliable: `write error' message.
>>>
>>> I've hacked around this by ignoring the error in misc.c (close_stdout)
>>> ;-)
>>>
>>
>> It seems odd that gmake would pass every test in its own testsuite and
>> then get an odd little message like that. Oh well, if you feel it can be
>
> It only happens once in a while, and primarily for Solaris 11 NFS
> servers.  Even more rarely, it occurs on Solaris 11 locally.

I generally build my prod things on Solaris 8 with the assumption that the
Solaris ABI stability will provide what I need up to Solaris 9. Then I
rebuild again on Solaris 10 for AMD64/x86_64 functionality. This has
worked well thus far.

I avoid Solaris 11 Express entirely as I just don't see it as a valid
release yet. If the OpenSolaris project was still alive and the bug
process was open then I'd may feel differently but with thing being as
they are ... I avoid Sol 11 for now.

>
>> ignored then I'm so very happy to see this.
>
> I think it is harmless enough to be ignored in this particular case, but
> this deviation from pre-S11 behaviour is bad.  Suddenly expecting every
> single piece of software to handle EINTR all over the place when you
> didn't need to before and don't need it on any other platform isn't
> exactly a winning proposition to me ;-(  I'll try to pursue this with
> Solaris engineering.

 How is that going ? I have filed bugs in the past regarding Studio 11
Update 1 and was not exactly thrilled with the response. However ..
dropping an email to Daryl Gove can generally get things moving.

>> By the way, I just want to say thank you for posting results on Solaris
>> because I review them and use them for comparison all the time. I am
>> still
>> fascinated that GCC can post different results on two servers running
>> the
>> same OS and probably with the same revs of tools avail.
>>
>> Consider this on Sol 8 i386 :
>>
>> === gcc Summary ===
>>
>> # of expected passes72652
>> # of unexpected failures18
>> # of expected failures  212
>> # of unresolved testcases   1
>> # of unsupported tests  1874
>> /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc  version 4.6.0
>> (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011)
>>
>> This : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html
>>
>>  === gcc Summary ===
>>
>> # of expected passes 74529
>> # of unexpected failures 1
>> # of expected failures   212
>> # of unresolved testcases1
>> # of unsupported tests   1031
>> /var/gcc/gcc-4.6.0/8-gcc-gas/gcc/xgcc  version 4.6.0 (GCC)
>
> One would have to compare gcc.sum in detail to know what's going on.
>

Well my testsuite run with N=2 finished and the results look like :

http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg03106.html

=== gcc Summary ===

# of expected passes72652
# of unexpected failures18
# of expected failures  212
# of unresolved testcases   1
# of unsupported tests  1874
/opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc  version 4.6.0
(Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011)

Exact same as before !

This is a very good sign.

OKay .. so my days of running gmake -k check as a single thread are over.
Thank you very much!

>> I decided to toss caution to the wind and run my build with as and ld in
>> /usr/ccs/bin and I was happy to see a decent result set. I often wonder
>> if
>> we *need* GNU as or just *want* GNU as in an older Solaris release like
>> 8.
>
> IMO you want gas on Solaris/x86 before 10 because as lacks several
> features there (like visibility support).  On Solaris 10/x86 and up, as
> is mostly fine (primarily COMDAT group support is missing, but I'm
> working on that with the assembler and linker engineers as we speak).
> Unfortunately, a recent as patch broke several -gstabs tests, but this
> is expected to be fixed soon.
>
> On Solaris/SPARC I usually do the production builds with as; there seems
> little reason to go for gas instead.
>
> Hope this helps.

Very much so, thank you.

I'll go back and rebuild on x86 with gas and leave my Sparc build as is. I
generally do a double bootstrap merely to see what happens when GCC 4.6.0
is built with GCC 4.6.0 after it has already been bootstrapped. If I see
any significant changes in the testsuite results then I assume something
funky is afoot.


-- 
Dennis Clarke
dcla...@opensolaris.ca  <- Email related to the open source Solaris
dcla...@blastwave.org   <- Email related to open source for Solaris

Re: Question about Temporary Outputs

[Pranav Bhandarkar]

On Thu, Mar 31, 2011 at 4:04 PM, Iyer, Balaji V  wrote:
> Hello Everyone,
>               I see in GCC that when we use the flag "-f-tree-optimized" it 
> will dump the contents of the input file after doing all the tree-based 
> optimization. Is it possible for me to modify this file and then submit it 
> back into gcc for processing to create an executable/assembly dump?

It has been a while since I have worked on GCC - back then (a couple
of years ago) this was not possible. I do not have reason to believe
this would have changed.

Pranav

Question about Temporary Outputs

[Iyer, Balaji V]

Hello Everyone,
   I see in GCC that when we use the flag "-f-tree-optimized" it 
will dump the contents of the input file after doing all the tree-based 
optimization. Is it possible for me to modify this file and then submit it back 
into gcc for processing to create an executable/assembly dump?

Any help is highly appreciated!

Thanks,

Balaji V. Iyer.

P.S.  Please CC me when you respond to this email since I am not a subscribed 
member of this mailing list.

Re: Use --format=pax for release?

[Ian Lance Taylor]

Joe Buck  writes:

> On Wed, Mar 30, 2011 at 11:38:02PM -0700, Ian Lance Taylor wrote:
>> Our releases are normally built with GNU tar, which seems to default to
>> --format=tar.  I wonder if we should switch to --format=pax.  The pax
>> format was defined by POSIX.1 10 years ago, and should be widely
>> supported at this point.  GNU tar can generate it and recognize it.
>
> I've never seen anyone distribute free software with the pax format.
> Yes, Posix created it to settle a fight between promoters of the tar
> and the cpio format: create yet a third format and declare peace
> (pax is Latin for peace).  But no one uses pax.
>
>> That might permit us to remove this paragraph from install.texi:
>> 
>> @item GNU tar version 1.14 (or later)
>> 
>> Necessary (only on some platforms) to untar the source code.  Many
>> systems' @command{tar} programs will also work, only try GNU
>> @command{tar} if you have problems.
>
> But you'd need a program that could deal with the pax format, which, for
> most people, would be GNU tar.

The question is whether the tar program on other operating systems is
more likely to support the pax format or the GNU tar format.

If the tar program on other systems does not support the pax format,
then I agree this would be useless.

Ian

Re: Use --format=pax for release?

[Joe Buck]

On Wed, Mar 30, 2011 at 11:38:02PM -0700, Ian Lance Taylor wrote:
> Our releases are normally built with GNU tar, which seems to default to
> --format=tar.  I wonder if we should switch to --format=pax.  The pax
> format was defined by POSIX.1 10 years ago, and should be widely
> supported at this point.  GNU tar can generate it and recognize it.

I've never seen anyone distribute free software with the pax format.
Yes, Posix created it to settle a fight between promoters of the tar
and the cpio format: create yet a third format and declare peace
(pax is Latin for peace).  But no one uses pax.

> That might permit us to remove this paragraph from install.texi:
> 
> @item GNU tar version 1.14 (or later)
> 
> Necessary (only on some platforms) to untar the source code.  Many
> systems' @command{tar} programs will also work, only try GNU
> @command{tar} if you have problems.

But you'd need a program that could deal with the pax format, which, for
most people, would be GNU tar.

Re: PING^2 [PATCH] Support for AMD64 targets running GNU/kFreeBSD

[Joseph S. Myers]

I advise CC:ing the relevant target maintainers on such patch submissions.  
Since there is no *-kfreebsd-gnu maintainer (you might wish to volunteer 
to be such), and no *-linux* maintainer for the linux*.h changes, this 
means the people listed as maintainers of the i386 port.

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

Re: Supporting multiple pointer sizes in GCC

[Paulo J. Matos]

On 30/03/11 08:57, Claudiu Zissulescu wrote:

Hi,

I would try using the named address space for your issue (see
TARGET_ADDR_SPACE_POINTER_MODE). Please check the SPU target for an
implementation example.



Hummm, I haven't noticed this hook before. Could this be used to 
implement cases where function pointers have a different size than data 
pointers (as in harvard archs). It looks like it but can someone confirm?


Cheers,

--
PMatos

Re: On the toplevel configure and build system

[Joseph S. Myers]

On Thu, 31 Mar 2011, Paolo Bonzini wrote:

> On 03/30/2011 05:54 PM, Joseph S. Myers wrote:
> > Thanks.  My inclination is to say that this should be considered an
> > independent tool in its own repository, as something not required in the
> > build of any of the other tools.  More specifically, utils/mep and
> > utils/wince look like independent tools each of which would better go in
> > its own toplevel directory (mep-integrator, cesetup) (and would each go in
> > an independent repository based on the shared toplevel, since they use
> > libiberty), while utils/spu appears to have no toplevel dependencies and
> > so should be completely independent, possibly without toplevel support for
> > building it.  Since utils/spu and utils/wince have no non-build-system
> > changes since 2000, I'd be inclined to say we should declare those two
> > subdirectories dead and run "cvs rm" on them - people wanting to resurrect
> > them can always extract the data from CVS later.  (And I still think
> > utils/mep should move to its own toplevel directory.)
> 
> No, these tools _are_ built after all.

My claim is that while they *are* built, the lack of substantive changes 
in the past decade is evidence that utils/spu and utils/wince are probably 
no longer being used.

Stan, you appear to be the only person with non-build-system changes in 
the utils/spu ChangeLog (from the years 1994 and 2000).  Do you have any 
reason to believe it is still being used, or is it OK to run "cvs rm" on 
that directory's contents in the src repository?

DJ, the same questions apply for utils/wince; you appear to have the only 
non-build-system changes, in 1999 and 2000.

In the modules file the only place utils appears is in old-gdb (that is, 
it used to be considered part of the GDB sources but no longer is).

> However, moving them to a new toplevel directory and getting rid of utils
> would be a good thing.

Moving utils/mep to its own toplevel directory, that is, if the other two 
aren't being used.

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

Re: PING^2 [PATCH] Support for AMD64 targets running GNU/kFreeBSD

[Robert Millan]

Ping^2

2011/1/26 Robert Millan :
> Ping!
>
> 2011/1/18 Robert Millan :
>> 2011/1/14 Robert Millan :
>>> 2011/1/12 Robert Millan :
> * The headers config/kfreebsd-gnu.h etc. override
>  GLIBC_DYNAMIC_LINKER.  But the 64-bit configurations
>  x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to
>  use any header that would override GLIBC_DYNAMIC_LINKER32 and
>  GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h
>  actually uses.  Thus those configurations would use Linux-specific
>  dynamic linker settings, which seems unlikely to be as intended.

 It's not as intended. On amd64 we use /lib/ld.so.1 and
 /lib/ld-kfreebsd-x86-64.so.1.
>>>
>>> It seems x86_64-kfreebsd-gnu has been broken for a while.  I
>>> just realized that I wrote a patch to fix this in 2006 [1], but
>>> somehow it was never merged in GCC (actually I'm not even
>>> sure I submitted it).
>>>
>>> In the meantime Debian GNU/kFreeBSD has been using this
>>> patch to build GCC on their "kfreebsd-amd64" port.
>>>
>>> I can prepare an updated version of this patch (relative to
>>> trunk + your linux.h overhaul [2]).
>>
>> Here is it.
>>
>> --
>> Robert Millan
>>
>
>
>
> --
> Robert Millan
>



-- 
Robert Millan
2011-01-18  Robert Millan  

Support for AMD64 targets running GNU/kFreeBSD.

* config.gcc (tm_file): Include `i386/kfreebsd-gnu.h' on
x86_64-*-kfreebsd*-gnu.
* config/i386/kfreebsd-gnu.h
(GLIBC_DYNAMIC_LINKER32): If defined, redefine to "/lib/ld.so.1".
(GLIBC_DYNAMIC_LINKER64): If defined, redefine to
"/lib/ld-kfreebsd-x86-64.so.1".

* config/i386/linux.h (LINK_EMULATION): Redefine this macro
to a noop filter, which can be overriden by other headers.
* config/i386/linux64.h (LINK_SPEC): Process emulation names
through LINK_EMULATION().
* config/kfreebsd-gnu.h (LINK_EMULATION): Redefine to append
a "_fbsd" suffix.
* config/i386/kfreebsd-gnu.h (LINK_EMULATION): Remove macro
(superceded by the definition in config/kfreebsd-gnu.h).

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 168952)
+++ gcc/config.gcc  (working copy)
@@ -1267,7 +1267,7 @@
case ${target} in
x86_64-*-linux*)
  default_gnu_indirect_function=glibc-2011 ;;
-   x86_64-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h" ;;
+   x86_64-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h 
i386/kfreebsd-gnu.h" ;;
x86_64-*-knetbsd*-gnu) tm_file="${tm_file} knetbsd-gnu.h" ;;
esac
tmake_file="${tmake_file} i386/t-linux64 i386/t-crtstuff i386/t-crtpc 
i386/t-crtfm t-dfprules"
Index: gcc/config/i386/linux.h
===
--- gcc/config/i386/linux.h (revision 168952)
+++ gcc/config/i386/linux.h (working copy)
@@ -91,7 +91,7 @@
done.  */
 
 /* These macros may be overridden in k*bsd-gnu.h and i386/k*bsd-gnu.h. */
-#define LINK_EMULATION "elf_i386"
+#define LINK_EMULATION(em) em
 #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
 
 #undef  ASM_SPEC
@@ -100,7 +100,7 @@
 
 #undef  SUBTARGET_EXTRA_SPECS
 #define SUBTARGET_EXTRA_SPECS \
-  { "link_emulation", LINK_EMULATION },\
+  { "link_emulation", LINK_EMULATION("elf_i386") },\
   { "dynamic_linker", LINUX_DYNAMIC_LINKER }
 
 #undef LINK_SPEC
Index: gcc/config/i386/kfreebsd-gnu.h
===
--- gcc/config/i386/kfreebsd-gnu.h  (revision 168952)
+++ gcc/config/i386/kfreebsd-gnu.h  (working copy)
@@ -19,7 +19,15 @@
 along with GCC; see the file COPYING3.  If not see
 .  */
 
-#undef LINK_EMULATION
-#define LINK_EMULATION "elf_i386_fbsd"
+#ifdef GLIBC_DYNAMIC_LINKER32
+#undef GLIBC_DYNAMIC_LINKER32
+#define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
+#endif
+
+#ifdef GLIBC_DYNAMIC_LINKER64
+#undef GLIBC_DYNAMIC_LINKER64
+#define GLIBC_DYNAMIC_LINKER64 "/lib/ld-kfreebsd-x86-64.so.1"
+#endif
+
 #undef REG_NAME
 #define REG_NAME(reg) sc_ ## reg
Index: gcc/config/i386/linux64.h
===
--- gcc/config/i386/linux64.h   (revision 168952)
+++ gcc/config/i386/linux64.h   (working copy)
@@ -75,7 +75,8 @@
  %{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}"
 
 #undef LINK_SPEC
-#define LINK_SPEC "%{" SPEC_64 ":-m elf_x86_64} %{" SPEC_32 ":-m elf_i386} \
+#define LINK_SPEC "%{" SPEC_64 ":-m " LINK_EMULATION("elf_x86_64") "} \
+  %{" SPEC_32 ":-m " LINK_EMULATION("elf_i386") "} \
   %{shared:-shared} \
   %{!shared: \
 %{!static: \
Index: gcc/config/kfreebsd-gnu.h
===
--- gcc/config/kfreebsd-gnu.h   (revision 168952)
+++ gcc/config/kfreebsd-gnu.h   (working copy)
@@ -35,3 +35,6 @@
 #undef GLIBC_DYNAMIC_LINKER
 #define GLIBC_DYNAMIC_LINKER "/lib/l

Re: GCC 4.6.0 Released

[Rainer Orth]

Dennis Clarke  writes:

>> The only caveat are strange errors with gmake:
>>
>> make[3]: write error
>>
>> See CR 6938116   GNU make highly unreliable: `write error' message.
>>
>> I've hacked around this by ignoring the error in misc.c (close_stdout) ;-)
>>
>
> It seems odd that gmake would pass every test in its own testsuite and
> then get an odd little message like that. Oh well, if you feel it can be

It only happens once in a while, and primarily for Solaris 11 NFS
servers.  Even more rarely, it occurs on Solaris 11 locally.

> ignored then I'm so very happy to see this.

I think it is harmless enough to be ignored in this particular case, but
this deviation from pre-S11 behaviour is bad.  Suddenly expecting every
single piece of software to handle EINTR all over the place when you
didn't need to before and don't need it on any other platform isn't
exactly a winning proposition to me ;-(  I'll try to pursue this with
Solaris engineering.

> By the way, I just want to say thank you for posting results on Solaris
> because I review them and use them for comparison all the time. I am still
> fascinated that GCC can post different results on two servers running the
> same OS and probably with the same revs of tools avail.
>
> Consider this on Sol 8 i386 :
>
> === gcc Summary ===
>
> # of expected passes72652
> # of unexpected failures18
> # of expected failures  212
> # of unresolved testcases   1
> # of unsupported tests  1874
> /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc  version 4.6.0
> (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011)
>
> This : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html
>
>   === gcc Summary ===
>
> # of expected passes  74529
> # of unexpected failures  1
> # of expected failures212
> # of unresolved testcases 1
> # of unsupported tests1031
> /var/gcc/gcc-4.6.0/8-gcc-gas/gcc/xgcc  version 4.6.0 (GCC)

One would have to compare gcc.sum in detail to know what's going on.

> I decided to toss caution to the wind and run my build with as and ld in
> /usr/ccs/bin and I was happy to see a decent result set. I often wonder if
> we *need* GNU as or just *want* GNU as in an older Solaris release like 8.

IMO you want gas on Solaris/x86 before 10 because as lacks several
features there (like visibility support).  On Solaris 10/x86 and up, as
is mostly fine (primarily COMDAT group support is missing, but I'm
working on that with the assembler and linker engineers as we speak).
Unfortunately, a recent as patch broke several -gstabs tests, but this
is expected to be fixed soon.

On Solaris/SPARC I usually do the production builds with as; there seems
little reason to go for gas instead.

Hope this helps.

Rainer

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

Re: GCC 4.6.0 Released

[Dennis Clarke]

> Dennis Clarke  writes:
>
>> Do you know if anyone has ever tested that on Solaris ? Lately Solaris
>> is
>> where open source goes to die ( blame Larry for that ) so I figure I may
>> as well give it a shot, but before I do .. tell me know if this little
>> trick works at all.
>
> Why shouldn't it?

No idea, and in the absence of data, I just am not sure yet.

> I'm using it all the way from Solaris 8 to 11, with N
> from 2 on a single-CPU HP Proliant DL-320 G2 via 96 on a 8-socket
> NehalemEX Fujitsu RX900 S1 up to 128 on a SPARC Enterprise T5120.
>

awesome ... I am running it right now with N=2 and I have to assume that
it will do the *exact* same results for my testsuite results.

I already posted this :

  http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02960.html

So right now the very same machine, with no changes at all, is runnung
with N=2. Thus far it looks to be quite busy :

mpstat 5 says
.
.
.
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0 4552   1  151   623  235  399  100   80   820  4185   50  46   4   0
  1 4538   1  225   286   49  360  106   76   810  3200   59  38   2   1
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0 3836   1  213   582  282  316   93   62   620  3375   62  34   3   0
  1 4463   0  142   378   81  348  108   57   640  3655   62  36   2   1
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0 3180   1  141   521  220  286   81   56   440  3363   65  32   2   1
  1 2895   0  150   258   38  298   93   59   490  2791   67  30   2   0
.
.
.



> The only caveat are strange errors with gmake:
>
> make[3]: write error
>
> See CR 6938116GNU make highly unreliable: `write error' message.
>
> I've hacked around this by ignoring the error in misc.c (close_stdout) ;-)
>

It seems odd that gmake would pass every test in its own testsuite and
then get an odd little message like that. Oh well, if you feel it can be
ignored then I'm so very happy to see this.

By the way, I just want to say thank you for posting results on Solaris
because I review them and use them for comparison all the time. I am still
fascinated that GCC can post different results on two servers running the
same OS and probably with the same revs of tools avail.

Consider this on Sol 8 i386 :

=== gcc Summary ===

# of expected passes72652
# of unexpected failures18
# of expected failures  212
# of unresolved testcases   1
# of unsupported tests  1874
/opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc  version 4.6.0
(Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011)

This : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html

=== gcc Summary ===

# of expected passes74529
# of unexpected failures1
# of expected failures  212
# of unresolved testcases   1
# of unsupported tests  1031
/var/gcc/gcc-4.6.0/8-gcc-gas/gcc/xgcc  version 4.6.0 (GCC)

I decided to toss caution to the wind and run my build with as and ld in
/usr/ccs/bin and I was happy to see a decent result set. I often wonder if
we *need* GNU as or just *want* GNU as in an older Solaris release like 8.

-- 
Dennis Clarke
dcla...@opensolaris.ca  <- Email related to the open source Solaris
dcla...@blastwave.org   <- Email related to open source for Solaris

Re: GCC 4.6.0 Released

[Rainer Orth]

Dennis Clarke  writes:

> Do you know if anyone has ever tested that on Solaris ? Lately Solaris is
> where open source goes to die ( blame Larry for that ) so I figure I may
> as well give it a shot, but before I do .. tell me know if this little
> trick works at all.

Why shouldn't it?  I'm using it all the way from Solaris 8 to 11, with N
from 2 on a single-CPU HP Proliant DL-320 G2 via 96 on a 8-socket
NehalemEX Fujitsu RX900 S1 up to 128 on a SPARC Enterprise T5120.

The only caveat are strange errors with gmake:

make[3]: write error

See CR 6938116  GNU make highly unreliable: `write error' message.

I've hacked around this by ignoring the error in misc.c (close_stdout) ;-)

Rainer

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

Re: On the toplevel configure and build system

[Paolo Bonzini]

On 03/30/2011 05:15 PM, Joseph S. Myers wrote:

On Tue, 29 Mar 2011, Joseph S. Myers wrote:


Specifically, I propose removal of all support for building: ash autoconf
automake bash byacc bzip2 diff dosutils fileutils findutils find gawk
gettext gnuserv gzip hello indent libiconv libtool make mmalloc patch perl
prms rcs release recode sed send-pr shellutils tar textutils time uudecode
wdiff zip expect guile target-gperf target-examples target-qthreads.  See
  and followups
regarding reasons to keep a few packages in my original list that aren't
in the list above.


There's been push-back on libiconv and expect.


I still think expect has no reason to stay in the toplevel (not any more 
than tcl or tk).


dejagnu is another story, and there's good reasons for leaving libiconv 
as well.



2'. If the combination of directories present in the source tree would not
build and install anything for the host or target (other than host
libraries such as libiberty) then there should be an error at configure or
build time.  For example, a GCC source tree should not quietly build
nothing because GCC isn't supported for the target; a binutils+gdb tree
should not quietly build nothing for lack of BFD support, although it
might build only a subset of binutils if ld and gdb aren't supported.


Agreed.

Paolo

Re: On the toplevel configure and build system

[Paolo Bonzini]

On 03/30/2011 05:54 PM, Joseph S. Myers wrote:

Thanks.  My inclination is to say that this should be considered an
independent tool in its own repository, as something not required in the
build of any of the other tools.  More specifically, utils/mep and
utils/wince look like independent tools each of which would better go in
its own toplevel directory (mep-integrator, cesetup) (and would each go in
an independent repository based on the shared toplevel, since they use
libiberty), while utils/spu appears to have no toplevel dependencies and
so should be completely independent, possibly without toplevel support for
building it.  Since utils/spu and utils/wince have no non-build-system
changes since 2000, I'd be inclined to say we should declare those two
subdirectories dead and run "cvs rm" on them - people wanting to resurrect
them can always extract the data from CVS later.  (And I still think
utils/mep should move to its own toplevel directory.)


No, these tools _are_ built after all.

However, moving them to a new toplevel directory and getting rid of 
utils would be a good thing.


Paolo

Re: how can I split 1 mov insn into 2 sub_mov and 1 combine?

[Liu]

On Thu, Mar 31, 2011 at 2:57 PM, Ian Lance Taylor  wrote:
> Liu  writes:
>
>> On Wed, Mar 30, 2011 at 11:45 PM, Ian Lance Taylor  wrote:
>>> Liu  writes:
>>>
       if (GET_MODE (dest) == V32QImode)
         tmp_reg = gen_reg_rtx (V32QImode);
>>>
 vpaddd.c:33:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:863
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See  for instructions.

 emit-rtl.c:863 is  gcc_assert (can_create_pseudo_p ());
>>>
>>> You can only call gen_reg_rtx if can_create_pseudo_p returns true.  It
>>> will return false during and after register allocation.  Your code is
>>> being called at that time somehow, probably during reload.  You have to
>>> either ensure that that does not happen, or, more likely, you have to
>>> arrange to use an existing register rather than create a new one.  For
>>> example, look for uses of can_create_pseudo_p in mips.c.
>>>
>>> Ian
>>>
>>
>> Thank you very much Ian!
>>
>> Does SCRATCH will be OK?
>
> Not directly, no.  You can use match_scratch as part of a secondary
> reload, though.  I don't know whether you need a secondary reload here
> or not.
>
> Ian
>

Thanks.
 I'll go to look into can_create_pseudo_p, maybe reload.c, it is really complex.

Re: GCC 4.6.0 Released

[Dennis Clarke]

> On Wed, Mar 30, 2011 at 11:45:38PM -0700, Ian Lance Taylor wrote:
>> Ryan Hill  writes:
>>
>> > Does anyone know since when (if) running make check with more than one
>> job
>> > has been supported?  IIRC back in the 3.x days it caused issues so
>> we've
>> > been forcing -j1 here forever.  If we could run it in parallel that
>> would be a
>> > big timesaver.
>>
>> Jakub fixed it back in 2008 for gcc 4.4.  It is indeed a big timesaver.
>
> Fixed just in the sense that the testing is more parallelized.
> I've been using make -jN -k check for more than a decade and I don't
> remember problems with that, mudflap tests are flaky and tend to fail
> more often under load, but mudflap has only been added in 4.0.
> Of course the N keeps changing over time, but currently testing certainly
> works with -j48 that I'm using daily.
>
>   Jakub


Do you know if anyone has ever tested that on Solaris ? Lately Solaris is
where open source goes to die ( blame Larry for that ) so I figure I may
as well give it a shot, but before I do .. tell me know if this little
trick works at all.


-- 
Dennis Clarke
dcla...@opensolaris.ca  <- Email related to the open source Solaris
dcla...@blastwave.org   <- Email related to open source for Solaris

Re: GCC 4.6.0 Released

[Jakub Jelinek]

On Wed, Mar 30, 2011 at 11:45:38PM -0700, Ian Lance Taylor wrote:
> Ryan Hill  writes:
> 
> > Does anyone know since when (if) running make check with more than one job
> > has been supported?  IIRC back in the 3.x days it caused issues so we've
> > been forcing -j1 here forever.  If we could run it in parallel that would 
> > be a
> > big timesaver.
> 
> Jakub fixed it back in 2008 for gcc 4.4.  It is indeed a big timesaver.

Fixed just in the sense that the testing is more parallelized.
I've been using make -jN -k check for more than a decade and I don't
remember problems with that, mudflap tests are flaky and tend to fail
more often under load, but mudflap has only been added in 4.0.
Of course the N keeps changing over time, but currently testing certainly
works with -j48 that I'm using daily.

Jakub