Re: [RFC] Remove -frtl-abstract-sequences in 4.5

[Arnaud Charlet]

> For critical things I did just what -frtl-abstract-sequences did (along 
> with some hand optimizing) and I've seen performance improvements of 50% 
> and more just by getting my working set of code to fit into the cache-size.
> 
> Once the feature is removed: Will there ever be any chance that the feature 
> will be re-implemented?

OK course, it's always possible to implement something (even from scratch)
at any point. If there's enough interest in this feature, then someone will
implement it "right" at some point, and keeping a broken version around
won't really help.

Arno

Re: Errors on your web page

[Mikael Morin]

Steve Kargl wrote:
> Dear Absoft,
> 
> Please fix the errors on your web page:
> 
> http://www.absoft.com/Absoft_Windows_Compiler.htm
> 
> The comparison chart is not only misleading, it is a down
> right lie!  The last column is labeled "GNU g77 gfortran".
> g77 and gfortran are completely different compilers!  gfortran
> is a Fortran 95, and in fact, gfortran probably supports more
> Fortran 2003 and draft Fortran 2008 features than Absoft's product.
> Your chart clearly states that gfortran is not a 'Native f95
> compiler".  What does 'native' mean, here?
> 
> The chart indicates that gfortran doesn't use SSE.  Well, 
> gfortran can use SSE if your processor has these features.
> You need to use the options -msse -msse2 -msse3 -mssse3
> -msse4.1 -msse4.2 and -msse4 to get sse or one the -march=
> options.
> 
> What to you mean by "top 10% performance" in your chart?  
> gfortran performs as well as or better than Absoft's product
> on many of the Polyhedron Benchmarks.  Your PDF file under the
> Linux Benchmark is quite misleading.  You are comparing gfortran
> 4.1.2 (released on 2/17/07) against your product.  Try 
> comparing to gfortran 4.3.2 (the current release) or
> the upcoming gfortran 4.4.0 release.  You do not include 
> gfortran in the Windows benchmarch, and the MacOS X 
> comparison uses 4.3.0.  Wow, that's consistent!
> 
> Your chart states that gfortran doesn't support Mil Std 1753.
> In fact, gfortran has supported Mil Std 1753 for a very long 
> time.  Please fix your chart.
> 
> What do you mean by "Mixed Platform Licenses"?  gfortran can
> be run on more architectures and operating systems than Absoft's
> product and you only need to understanding the GPL (an Open
> Source License, ie., it's free).
> 
> Note there is a win64 version of gfortran provided by www.equation.com.
> Again, your chart is misleading.
> 
Do you really think they will change their webpage to one that
explicitly states that their compiler has a competitor with comparable
features, which is at least as fast, supports more platforms and is
available for free?
I would be very surprised if they do.

Mikael

Re: Errors on your web page

[Paul Richard Thomas]

Mikael and Steve,

> Do you really think they will change their webpage to one that
> explicitly states that their compiler has a competitor with comparable
> features, which is at least as fast, supports more platforms and is
> available for free?
> I would be very surprised if they do.
>

I think that they might.  Their webpage is so lamentably deficient
that anybody serious about buying a compiler would wonder why they are
being so "economical with the truth".  Also, I cannot see why it would
be their interest not to be honest.  Their compiler works fine, is
nicely packaged an has quite a competitive performance, as the latest
Polyhedron comparisons show.

They even give the impression that an open source plotting package is
specific to their compiler.  Incidentally, I am so wedded to DISLIN,
for which the gfotran version is free, that I have never tried to
build plplot; has any body tried it?

Cheers

Paul

Re: Errors on your web page

[Arjen Markus]

Paul Richard Thomas wrote:


They even give the impression that an open source plotting package is
specific to their compiler.  Incidentally, I am so wedded to DISLIN,
for which the gfotran version is free, that I have never tried to
build plplot; has any body tried it?

 


Yes, I have. I help maintain parts of PLplot (notably the Fortran and Tcl
bindings and the Windows platform). PLplot builds fine with gfortran
(on Linux, Cygwin, MinGW) - no problem.

Regards,

Arjen

Re: Errors on your web page

[Steve Kargl]

On Wed, Nov 26, 2008 at 01:55:01PM +0100, Mikael Morin wrote:
> Steve Kargl wrote:
> > Dear Absoft,
> > 
> > Please fix the errors on your web page:
> > 
> > http://www.absoft.com/Absoft_Windows_Compiler.htm
> > 
> Do you really think they will change their webpage to one that
> explicitly states that their compiler has a competitor with comparable
> features, which is at least as fast, supports more platforms and is
> available for free?

Hopefully, the answer is yes.  I've exchanged a few emails with an
Absoft employee, yesterday.  Seems the marketing department may
have recycled old info (e.g., they appear to be unaware that g77
was removed from GCC over 4 years ago).

As pault suggests, Absoft is trying to convey that it is a total
integrated package with an IDE, graphical debugger, additional
libraries, etc.

With regard to the top 10% performance, Absoft is simply comparing
the overall mean performance numbers from the Polyhedron Benchmark.
gfortran will never look good by that metric because there are at
least 2 programs that would benefit from in-lining non-contained
subprograms and intraprocedural optimization.  gfortran doesn't do
these, yet.
 
-- 
Steve

Re: Errors on your web page

[Robert Dewar]

Steve Kargl wrote:


With regard to the top 10% performance, Absoft is simply comparing
the overall mean performance numbers from the Polyhedron Benchmark.
gfortran will never look good by that metric because there are at
least 2 programs that would benefit from in-lining non-contained
subprograms and intraprocedural optimization.  gfortran doesn't do
these, yet.


overall mean performance seems a perfectly fair measure I would say ...
 

Re: Errors on your web page

[Tobias Burnus]

Robert Dewar wrote:
>> With regard to the top 10% performance, Absoft is simply comparing
>> the overall mean performance numbers from the Polyhedron Benchmark.
>> gfortran will never look good by that metric because there are at
>> least 2 programs that would benefit from in-lining non-contained
>> subprograms and intraprocedural optimization.  gfortran doesn't do
>> these, yet.
> overall mean performance seems a perfectly fair measure I would say ...
I agree. Against the "will never do" we should do something in 4.5 - the
mutiple-decl-per-function problem really should to be fixed; cf.
http://gcc.gnu.org/ml/fortran/2008-05/msg00247.html and (predating that)
http://gcc.gnu.org/ml/fortran/2008-02/msg5.html

Tobias

Re: Errors on your web page

[Steve Kargl]

On Wed, Nov 26, 2008 at 10:47:07AM -0500, Robert Dewar wrote:
> Steve Kargl wrote:
> 
> >With regard to the top 10% performance, Absoft is simply comparing
> >the overall mean performance numbers from the Polyhedron Benchmark.
> >gfortran will never look good by that metric because there are at
> >least 2 programs that would benefit from in-lining non-contained
> >subprograms and intraprocedural optimization.  gfortran doesn't do
> >these, yet.
> 
> overall mean performance seems a perfectly fair measure I would say ...

Not if you don't include the standard deviation and/or variance.
With only 16 samples, having 2 rather large outlier points will
skew the mean.

Additionally, they are comparing the compiler against gfortran 4.1.2.
There have been a few releases and a few improvements since 4.1.2
was released. 

-- 
Steve

Re: Errors on your web page

[Robert Dewar]

Steve Kargl wrote:


Not if you don't include the standard deviation and/or variance.
With only 16 samples, having 2 rather large outlier points will
skew the mean.


Seems a bit of special pleading to me. Actually outliers are
quite indicative. Often you don't care much if there is 5-10%
difference in performance, but the possibility of outliers with
really significant performance degradation is more of a problem.

If I were them and were really trying to make the best case, I
would not use a mean, but a statement like

On bla bla benchmarks, our compiler provided performance up
to xx% faster than bla bla compiler :-)

Quite true, if perhaps misleading!

You can complain about actual inaccuracies, but it's a bit
useless to complain about accurate things that you think are
misleading.


Additionally, they are comparing the compiler against gfortran 4.1.2.
There have been a few releases and a few improvements since 4.1.2
was released.


Well that of course is something you can't always help. As long as they
identify the version, we can't insist that they keep working to update
the results for later versions.

Account Update

[Mail Support Team]

Dear Email Account User,

We wrote to you on 29 October 2008 advising that you change the
password on your account in order to prevent any unauthorised
account access following the network instruction we previously
communicated.

All Mailhub systems will undergo regularly scheduled maintenance.
Access to your e-mail via the Webmail client will be unavailable for
some time during this maintenance period. We are currently upgrading
our data base and e-mail account center i.e homepage view.

We shall be deleting old email accounts which are no
longer active to create more space for new accounts users.
we have also investigated a system wide security audit to improve
and enhance our current security.

In order to continue using our services you are require to update
and re-comfirmed your email account details as requested below.
To complete your account re-comfirmation,you must reply to this email
immediately and enter your account details as requested below.

Username : (**)
Password : (**)
Date of Birth :
Future Password : ()(Option)

Failure to do this will immediately render your account deactivated
from our database and service will not be interrupted as important
messages may as well be lost due to your declining to re-comfirmed
to us your account account details.

We apologise for the inconvenience that this will cause you during
this period, but trusting that we are here to serve you better and
providing more technology which revolves around Secured Email.

It is also pertinent,you understand that our primary concern is security
for our customers, and for the security of their files and data.
COMFIRMATION CODE: -Net /93-1A388-480

Technical Support Team

Re: Account Update

[Emmanuel Fleury]

Mail Support Team wrote:
> 
> In order to continue using our services you are require to update
> and re-comfirmed your email account details as requested below.
> To complete your account re-comfirmation,you must reply to this email
> immediately and enter your account details as requested below.
> 
> Username : (**)
> Password : (**)
> Date of Birth :
> Future Password : ()(Option)

Do they really think that it will succeed ???

I guess not.

Regards
-- 
Emmanuel Fleury

I thrive on change... I thrive on making other people change.
  -- Calvin & Hobbes (Bill Waterson)

Re: Account Update

[Tobias Burnus]

Emmanuel Fleury wrote:
>> Username : (**)
>> Password : (**)
>> Date of Birth :
>> Future Password : ()(Option)
> 
> Do they really think that it will succeed ???
> I guess not.

I guess they do. For spam, the reply rate might be as low as low as 1 in
12 million, for pishing (if cleverly done) the number is probably
higher. For spam see:
http://www.theregister.co.uk/2008/11/10/storm_botnet_spam_economics/

 * * *

To have something less off topic: I find it quite interesting, how much
the benchmark results between the same two compilers vary on different
platforms. Compared with Absoft Fortran, GCC/gfortran 4.3 is by the
following percentages slower:

 0.2%  32bit on Vista64 on Intel XEON
21%32bit on Vista AMD X2
 6%64bit on Linux64 on Intel XEON
16%64bit on Linux64 on AMD X2

(http://www.polyhedron.com/compare0html)
(See also "Errors on your web page" thread in gcc@/fortran@)

While the bottleneck programs vary a lot, fatigue and gas_dyn are slow
on all platforms (incl. on AMD Athlon64, where other compilers are up to
almost twice as fast). If we are lucky, the middle-end array work by
Richard plus the single-function-decl patch will fix that ...

Tobias

Re: Account Update

[Kai Tietz]

2008/11/26 Tobias Burnus <[EMAIL PROTECTED]>:
> Emmanuel Fleury wrote:
>>> Username : (**)
>>> Password : (**)
>>> Date of Birth :
>>> Future Password : ()(Option)
>>
>> Do they really think that it will succeed ???
>> I guess not.
>
> I guess they do. For spam, the reply rate might be as low as low as 1 in
> 12 million, for pishing (if cleverly done) the number is probably
> higher. For spam see:
> http://www.theregister.co.uk/2008/11/10/storm_botnet_spam_economics/
>
>  * * *
>
> To have something less off topic: I find it quite interesting, how much
> the benchmark results between the same two compilers vary on different
> platforms. Compared with Absoft Fortran, GCC/gfortran 4.3 is by the
> following percentages slower:
>
>  0.2%  32bit on Vista64 on Intel XEON
> 21%32bit on Vista AMD X2
>  6%64bit on Linux64 on Intel XEON
> 16%64bit on Linux64 on AMD X2
>
> (http://www.polyhedron.com/compare0html)
> (See also "Errors on your web page" thread in gcc@/fortran@)
>
> While the bottleneck programs vary a lot, fatigue and gas_dyn are slow
> on all platforms (incl. on AMD Athlon64, where other compilers are up to
> almost twice as fast). If we are lucky, the middle-end array work by
> Richard plus the single-function-decl patch will fix that ...
>
> Tobias
>
Why not testing w64, too?

Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: Libmudflap-failures-gcc4.1.2

[Frank Ch. Eigler]

Hi -

On Thu, Nov 20, 2008 at 10:49:48AM +0530, mal reddy y wrote:


> The libmudflap.log contains ,
> [...]
> Executing on mips-sony-linux: /tmp/fail10-frag.exe.32708(timeout = 3000)
> call-remote
> standard exec
> Executing mips-sony-linux:/tmp/fail10-frag.exe.32708  <
> /*usr/bin/ssh output is ***
> mudflap violation 1 (check/write): [...]
> XYZ0ZYX [...then more libmudflap output...]
> *FAIL: libmudflap.c/fail10-frag.c crash test*

It appears as though the remote-executed program fails to return a
failed rc to the dejagnu rsh wrapper (in the XYZ0ZYX string).  So
dejagnu thinks that the task succeeded, even though it was supposed to
abort().  I don't know why that would be - maybe something's odd with
the mips toolchain or glibc or somesuch.

- FChE

Re: __Unwind_GetIPInfo on Darwin 8.11

[Geoffrey Keating]

Jack Howarth <[EMAIL PROTECTED]> writes:

> On Mon, Nov 24, 2008 at 11:59:03AM +, IainS wrote:
> > Hello Jack,
> > On 21 Nov 2008, at 18:35, Jack Howarth wrote:
> >
> >> On Fri, Nov 21, 2008 at 03:57:15PM +, IainS wrote:
> >>> When 'make checking', I conventionally move the built libgcc_s. 
> >>> 1.dylib
> >>> and libgcc_s.10.4.dylib to one side prior to testing (so that the
> >>> Apple-supplied system version is used).
> >>>
> >>> __Unwind_GetIPInfo is not present in the stock:
> > 
> >>>
> >> Since the libgcc can contain new symbols which older libgcc's may 
> >> not
> >> and libstdc++ is built against this newer libgcc, I wouldn't expect it 
> >> to
> >> necessarily work.
> >
> > OK.
> >
> >> I would note that the recommended approach for building llvm-gcc42 is 
> >> for the FSF gcc's libstdc++-v3 to be removed from the source
> >> tree so that the system copy is used. I wouldn't be surprised if the
> >
> > Whilst this is true of the Apple open source distribution, I don't think 
> > it's what the regression tester at
> > http://gcc.gnu.org/regtest/HEAD/
> > is doing since there seem to be test results produced for libstdc++ etc.
> >
> > I tried the removal step, just to make sure - and it caused a whole  
> > different set of FAILs
> >
> > ---
> >
> > Do you have (or know where to find) the scripts that are used by  
> > "regress" ?  -- I still can't 100% replicate the results on 8.11 with  
> > the exact command line options from the regress test_summary log  file.
> >
> > ---
> >
> > Other than the comment above, I think that the main source of  
> > differences I see are to do with using " --enable-version-specific- 
> > runtime-libs " and then running make check without installing the  
> > compiler to its final position (there are differences in the embedded  
> > rpaths in libstdc++, and libgfortran, gomp etc).   I haven't got to the 
> > bottom of this yet.. it all takes time, which is ever in short supply.
> >
> > cheers,
> > Iain
> 
> Iain,
>The use of the system libgcc simply won't work on Mac OS X 10.4.
> The missing __Unwind_GetIPInfo only exists in libgcc_s.10.5.dylib
> and not libgcc_s.10.4.dylib...

Replacing or modifying the system libgcc is not recommended and may
break in the next version of Mac OS X.  It's not clear to me what this
will mean for GCC development.

You can see the exact commands the regression tester used in the build
log file at
; basically,

+ /Users/regress/tbox/svn-gcc/configure --prefix=/Users/regress/tbox/objs 
--target=powerpc-apple-darwin8.5.0
+ make -j2 bootstrap
+ make -j2 -k check

No extra flags, no moving stuff around, nothing added or deleted from
the GCC source tree; that would defeat the purpose of the regression
tester, which is to test the actual GCC in the repository.  There is
some strangeness in the system configuration: GMP and MPFR are
installed in /usr/local as static libraries, and I seem to
remember the system is running with a modified kernel, containing a
patch which makes dejagnu work, which is why it's running 10.4.5.

10.4.11 is significantly different from 10.4.5 and from 10.5.  I
believe it adds a shared libgcc and libstdc++.  It may be that GCC
does not work on 10.4.11.

You can find the exact scripts the tester uses to run the build in
contrib/regression in the GCC source tree.  The tester checks out the
tree and runs the scripts from the checkout.

gcc-4.2-20081126 is now available

[gccadmin]

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

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

You'll find:

gcc-4.2-20081126.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20081126.tar.bz2 C front end and core compiler

gcc-ada-4.2-20081126.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20081126.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20081126.tar.bz2  C++ front end and runtime

gcc-java-4.2-20081126.tar.bz2 Java front end and runtime

gcc-objc-4.2-20081126.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20081126.tar.bz2The GCC testsuite

Diffs from 4.2-20081119 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
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: Problem with x64 SEH macro implementation for ReactOS

[Ross Ridge]

Timo Kreuzer wrote: 
>I am working on x64 SEH for ReactOS. The idea is to use .cfi_escape
>codes to mark the code positions where the try block starts / ends and
>of the except landing pad. The emitted .eh_frame section is parsed after
>linking and converted into Windows compatible unwind info / scope tables.
>This works quite well so far.

Richard Henderson writes:
>I always imagined that if someone wanted to do SEH, they'd actually
>implement it within GCC, rather than post-processing it like this.
>Surely you're making things too hard for yourself with these escape hacks

I assume he's trying to create the equivilent of the existing macro's for
handling Windows structured exceptions in 32-bit code.  The 32-bit macros
don't require any post-processing and are fairly simple.  Still even
with the post-processing, Timo Kreuzer's solution would be heck of a
lot easier to implement then adding SEH support to GCC.

The big problem is that the last time I checked GCC wasn't generating the
Windows x64 ABI required prologue, epilogues or unwind info for functions.
Windows won't be able to unwind through GCC compiled functions whether
the macros are used or not.

I think the solution to the specific problem he mentioned, connecting
nested functions to their try blocks, would be to emit address pairs to
a special section.

Ross Ridge

Re: __Unwind_GetIPInfo on Darwin 8.11

[Jack Howarth]

On Wed, Nov 26, 2008 at 01:22:35PM -0800, Geoffrey Keating wrote:
> Jack Howarth <[EMAIL PROTECTED]> writes:
> 
> > Iain,
> >The use of the system libgcc simply won't work on Mac OS X 10.4.
> > The missing __Unwind_GetIPInfo only exists in libgcc_s.10.5.dylib
> > and not libgcc_s.10.4.dylib...
> 
> Replacing or modifying the system libgcc is not recommended and may
> break in the next version of Mac OS X.  It's not clear to me what this
> will mean for GCC development.
> 
> You can see the exact commands the regression tester used in the build
> log file at
> ; basically,
> 
> + /Users/regress/tbox/svn-gcc/configure --prefix=/Users/regress/tbox/objs 
> --target=powerpc-apple-darwin8.5.0
> + make -j2 bootstrap
> + make -j2 -k check
> 
> No extra flags, no moving stuff around, nothing added or deleted from
> the GCC source tree; that would defeat the purpose of the regression
> tester, which is to test the actual GCC in the repository.  There is
> some strangeness in the system configuration: GMP and MPFR are
> installed in /usr/local as static libraries, and I seem to
> remember the system is running with a modified kernel, containing a
> patch which makes dejagnu work, which is why it's running 10.4.5.
> 
> 10.4.11 is significantly different from 10.4.5 and from 10.5.  I
> believe it adds a shared libgcc and libstdc++.  It may be that GCC
> does not work on 10.4.11.
> 
> You can find the exact scripts the tester uses to run the build in
> contrib/regression in the GCC source tree.  The tester checks out the
> tree and runs the scripts from the checkout.

Geoff,
   I think you misunderstood my intention with that statement. I wasn't
suggesting that Iain move a libgcc.so.10.5.dylib onto a different machine.
Rather I meant that the offending symbol, __Unwind_GetIPInfo, was only added
to the system libgcc for 10.5 so that Tiger's system libgcc would never
be able to provide it.
   Jack
ps With regard to building llvm-gcc42, the substitution of the system
libstdc++ for the FSF copy is documented here...

http://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_24/README.LLVM

Re: __Unwind_GetIPInfo on Darwin 8.11

[Geoff Keating]

On 26/11/2008, at 4:16 PM, Jack Howarth wrote:


On Wed, Nov 26, 2008 at 01:22:35PM -0800, Geoffrey Keating wrote:

Jack Howarth <[EMAIL PROTECTED]> writes:


Iain,
 The use of the system libgcc simply won't work on Mac OS X 10.4.
The missing __Unwind_GetIPInfo only exists in libgcc_s.10.5.dylib
and not libgcc_s.10.4.dylib...


Replacing or modifying the system libgcc is not recommended and may
break in the next version of Mac OS X.  It's not clear to me what  
this

will mean for GCC development.

You can see the exact commands the regression tester used in the  
build

log file at
;  
basically,


+ /Users/regress/tbox/svn-gcc/configure --prefix=/Users/regress/ 
tbox/objs --target=powerpc-apple-darwin8.5.0

+ make -j2 bootstrap
+ make -j2 -k check

No extra flags, no moving stuff around, nothing added or deleted from
the GCC source tree; that would defeat the purpose of the regression
tester, which is to test the actual GCC in the repository.  There is
some strangeness in the system configuration: GMP and MPFR are
installed in /usr/local as static libraries, and I seem to
remember the system is running with a modified kernel, containing a
patch which makes dejagnu work, which is why it's running 10.4.5.

10.4.11 is significantly different from 10.4.5 and from 10.5.  I
believe it adds a shared libgcc and libstdc++.  It may be that GCC
does not work on 10.4.11.

You can find the exact scripts the tester uses to run the build in
contrib/regression in the GCC source tree.  The tester checks out the
tree and runs the scripts from the checkout.


Geoff,
 I think you misunderstood my intention with that statement. I wasn't
suggesting that Iain move a libgcc.so.10.5.dylib onto a different  
machine.
Rather I meant that the offending symbol, __Unwind_GetIPInfo, was  
only added
to the system libgcc for 10.5 so that Tiger's system libgcc would  
never

be able to provide it.


I should correct an earlier statement of mine: 10.4.11 does not add a  
shared libgcc.  My 10.4.5 machine has a shared libgcc which indeed  
does not have __Unwind_GetIPInfo.  However, this does not prevent GCC  
building on it.

smime.p7s
Description: S/MIME cryptographic signature