Re: Official GCC git repository

[Andreas Schwab]

Harvey Harrison <[EMAIL PROTECTED]> writes:

> I've been waiting until I had the time to rewrite my import with proper
> author names.  Does anyone have a correspondence file mapping the login
> name to Author?

I have a list that is about 4 months old.  Should be pretty complete.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

[Andreas Schwab]

Till Straumann <[EMAIL PROTECTED]> writes:

> In any case, bad code is also produced by gcc-4.3.0 if I omit the
> memory output operand and use an example that comes pretty
> close to what is in the gcc info page (example illustrating
> a memory input in the 'extended asm' section):

Would you mind creating a bug report at ?

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Official GCC git repository

[Samuel Tardieu]

> "Paolo" == Paolo Bonzini <[EMAIL PROTECTED]> writes:

>> I was only suggesting it as a nicity, if people are happy with the
>> login name alone.

Paolo> What about "Real Name <[EMAIL PROTECTED]>"?  The overseers have
Paolo> the mapping, or you can sort of guess it from the names in the
Paolo> ChangeLog. This has to be decided before the first push, so
Paolo> it's kind of urgent to decide it.

I also think adding the Real Name is nice.

Maybe we should also consider adding the login as an additional field
in the MAINTAINERS file, as AFAIK every MAINTAINERS as a @gcc.gnu.org
address.

  Sam
-- 
Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/

Re: larger default page sizes...

[J.C. Pizarro]

On 2008/3/26, J.C. Pizarro <[EMAIL PROTECTED]> i wrote:
> On 2008/3/26, J.C. Pizarro <[EMAIL PROTECTED]> i wrote:
>   > On Tue, 25 Mar 2008 16:22:44 -0700 (PDT), David Miller wrote:
>   >  > > On Mon, 24 Mar 2008, David Miller wrote:
>   >  > >
>   >  > > > There are ways to get large pages into the process address space 
> for
>   >  > > > compute bound tasks, without suffering the well known negative side
>   >  > > > effects of using larger pages for everything.
>   >  > >
>   >  > > These hacks have limitations. F.e. they do not deal with I/O and
>   >  > > require application changes.
>   >  >
>   >  > Transparent automatic hugepages are definitely doable, I don't know
>   >  > why you think this requires application changes.
>   >  >
>   >  > People want these larger pages for HPC apps.
>   >
>   >  But there is a general problem of larger pages in systems that
>   >  don't support them natively (in hardware) depending in how it's
>   >  implemented the memory manager in the kernel:
>   >
>   >"Doubling the soft page size implies
>   >   halfing the TLB soft-entries in the old hardware".
>   >
>   >"x4 soft page size=> 1/4 TLB soft-entries, ... and so on."
>   >
>   >  Assuming one soft double-sized page represents 2 real-sized pages,
>   >  one replacing of one soft double-sized page implies replacing
>   >  2 TLB's entries containing the 2 real-sized pages.
>   >
>   >  The TLB is very small, its entries are around 24 entries aprox. in
>   >  some processors!.
>   >
>   >  Assuming soft 64 KiB page using real 4 KiB pages => 1/16 TLB 
> soft-entries.
>   >  If the TLB has 24 entries then calculating 24/16=1.5 soft-entries,
>   >the TLB will have only 1 soft-entry for soft 64 KiB pages!!! Weird!!!
>   >
>   >  The normal soft sizes are 8 KiB or 16 KiB for non-native
>  processors, not more.
>   >   So, the TLB of 24 entries of real 4 KiB will have 12 or 6
>   >  soft-entries respect.
>
>
>  The problem is that x86 and x64 is a "crap" when we want larger page sizes
>   (as 8, 16, 32 or 64 KiB) for HPC but not unusual excesive huge pages
>   (2, 4, 1024 MiB).
>
>   Stop the buying of the current PCs or Laptops, and wait until the well made
>   PCs or Laptops "Intel Code Quad 3" or "AMD Athlon AM3" with the following
>   cleaner features (lesser gates and more liable circuitry):
>   1. Instructions x86-64-II only to address usual cheaper 4 or 8 GiB of DDR 
> RAM,
> but changed the hierarchy of bytecodes of x86-64 for better performance.
>   2. Removed old 16-bit 8086 and old 32-bit 80386 instructions.
>   3. Removed unusual BCD instructions too.
>   4. Removed PAE and Hugepages of old 32-bit 80386 instructions.
>   5. Configurable TLB to only 8, 16, 32 and 64 KiB pages.
>   6. Configurable 3-level or 4-level MMU depending in the cfg'ble page sizes.
>   7. Removed 32-bit and 80-bit float points.
>   8. Added 64-bit as float point and 128-bit as double point, IEEE754.
>   9. Removed MMX/3DNow+ instructions.
>   10. Integrated SSEx instructions (auto saved/restrored to/from task's 
> stack).
>   11. Improved PIC (Position Independent Code) for shared libraries.
>   12. Improved hardware x86-64 virtualization.
>   13. Improved hardware x86-64 debuggability.
>   14. Improved CPU counters and timestampers in variabled-frequencies.
>   15. Realtime UTC (leap ctrl,DST,tz) clockers in ns for CPU-profilings.
>   16. Improved flushers (caches, TLB, MMU, ...).
>   17. Improved hardware futexes, semaphores, signals, .. for multicores.
>   18. MOESI protocol for multicores in SMPs & clusters.
>   19. Better integrated DMAs in processors.
>   20. Faster buses not always in fixed frequencies as said in the specs.
>   21. Reliable exceptions's handlings in out-of-order termination 
> architectures.
>   22. More capabilities for soft multi-threading of the O.S. in SMPs & 
> clusters.
>   23. More capabilities for processes's migrating of the O.S. in SMPs & 
> clusters.
>   24. More capabilities for JIT/AOT emulators of different hw as Qemu, Java, 
> ..
>   25. And more acknowledge of connected devices as ACPI, e820, ...
>
>   I don't see reasons of why Intel/AMD follow to release new x86-compatible
>   processors when they follow still being a crap in the reasonable practiques.
>
>
> I can't be sorry of the error in Mail Delivery Subsystem of LKML when i was
>  terminating soon of my comments.

Why are there in almost microprocessors only one smallest TLB instead
of hierarchied TLB L1, TLB L2, TLB L3 as equal as Cache L1, Cache L2, Cache L3?

That fool are the hw engineers!!!

It's a good idea to have a quick flusher of combined TLB-Cache L1-L2-L3 for
OSes of style unix, linux, *bsd, ...

I think that many hw engineers and non-engineers will need dozens of
gigant FPGAs (hundred millions of cells and macrocells) to simulate
the new and modern unreleased microprocessors.

   J.C.Pizarro.

gcc participation in C standards process

[Hallvard B Furuseth]

Thread "What's the deal with C99?" in comp.lang.c discusses the C99
standard, and people are among other things speculating about why gcc
was never represented in the committee.  I'd be interesting if you'd
reply there, e.g. to to message <[EMAIL PROTECTED]> from
lawrence.jones in the C committee:

> (...) I suspect it's the usual open source problem: no one is
> sufficiently interested to do it on their own and it's not a high
> enough priority for the steering committee to encourage/direct someone
> to do it.  (...)

Searching the gcc.gnu.org site I found a few anti-C-committe postings
from apparent C++ committee members, but not much else.

Another exchange from the thread:

Paul Hsieh (criticizing the C99 standard and the committee):
> Well, in the case of gcc, apparently the variable length arrays are
> fatal, because some critical amount of the code out there that uses
> gcc relies on the specific gcc semantics which conflict with C99's
> VLAs.
Jones:
> It's interesting to note that GCC is the only major compiler that has
> never been represented in the standardization process.  I consider that
> a major loss for GCC, the C standard, and the C community in general.
Hsieh:
> I agree.  So what the hell is the committee planning on doing about
> it?
Jones:
> That's not the committee's job.  In fact, it would probably go against
> the rules.  Participation is open to all, but actively soliciting one
> vendor would open the committee to complaints from other vendors who
> were not solicited and raise questions about the fairness of the
> process.

-- 
Hallvard

Re: RFH: testers for ieee test

[Derek M Jones]

Joern ,

You could try using softfloat:
http://www.jhauser.us/arithmetic/SoftFloat.html

--
Derek M. Jones  tel: +44 (0) 1252 520 667
Knowledge Software Ltd  mailto:[EMAIL PROTECTED]
Applications Standards Conformance Testinghttp://www.knosof.co.uk

Re: RFH: testers for ieee test

[Geert Bosch]

On Mar 27, 2008, at 02:58, Joern Rennecke wrote:

I'm trying to write a test to check I get all the subnormal
corner cases for ieee-754 double precision floating point division  
right.

The usual thing to do with a new test is to try it on a known good
platform.  Unfortunately, the x86 processor of my workstation is  
actually

known to get these calculations wrong.  Could someone with a fully
ieee compliant FPU try this test?


Just use -mfpmath=sse -msse2 to force use of SSE instructions
for double precision math. Should be the default nowadays, IMO.

  -Geert

Re: SSA Vs unSSA

[Diego Novillo]

On 03/26/08 14:07, Fran Baena wrote:

Hi,

what are the advantages and inconvenients of get RTL from SSA rather
than GIMPLE (previously translated from SSA)?
It has no implication in the next optimizations, isn't it?


Depends on what SSA form you want.  A rewriting form is problematic 
because backends are allowed to modify the IL behind the back of the 
optimizers and can emit instructions that are difficult/impossible to 
represent in SSA form (parallel).


A non-rewriting form, however, is not hard to implement.  We've 
discussed this a few weeks ago.  At some point we will build a FUD-chain 
representation from the currently dense UD links in the DF code.



Diego.

Re: RFH: testers for ieee test

[Joern Rennecke]

On Thu, Mar 27, 2008 at 04:27:32PM +0100, Geert Bosch wrote:
> >known to get these calculations wrong.  Could someone with a fully
> >ieee compliant FPU try this test?
> 
> Just use -mfpmath=sse -msse2 to force use of SSE instructions
> for double precision math. Should be the default nowadays, IMO.

Thanks, that works fine.  (The code I posted had the wrong size for a, though.)
I was searching in the gcc --help -v output before for stuff with sse, but
that didn't find the -mfpmath option, since there is no description of its
possible parameters, so I though my gcc installation didn't support sse math.

gcc-4.3-20080327 is now available

[gccadmin]

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

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

You'll find:

gcc-4.3-20080327.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080327.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080327.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080327.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080327.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080327.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080327.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080327.tar.bz2The GCC testsuite

Diffs from 4.3-20080320 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
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.

gimple

[Dasarath Weeratunge]

Is it possible to map simplified source statements back to the
original source code in GCC?

If this is not possible is it possible to stop the simplification
altogether and just retain the original
source tree in say DECL_SAVED_TREE(...) ? I tried removing tree
lowering passes but gcc still
seems to simplify the source.

My analysis computes program slices and I prefer if it outputs
original source code.

thanks,
-- dasarath

please add DFP to gcc-4.3/changes.html

[Benjamin Kosnik]

HJ asked this in June 2007:
http://gcc.gnu.org/ml/gcc/2007-06/msg00144.html

It seems as if delaying the announcement was what was desired then. Is
this still the case?

I was just as surprised as HJ was to not find this documented anywhere.
I'd rather have it documented, and marked experimental if it be.

The situation right now is very confusing.

-benjamin

Re: please add DFP to gcc-4.3/changes.html

[Janis Johnson]

On Thu, 2008-03-27 at 19:13 -0500, Benjamin Kosnik wrote:
> 
> HJ asked this in June 2007:
> http://gcc.gnu.org/ml/gcc/2007-06/msg00144.html
> 
> It seems as if delaying the announcement was what was desired then. Is
> this still the case?
> 
> I was just as surprised as HJ was to not find this documented anywhere.
> I'd rather have it documented, and marked experimental if it be.
> 
> The situation right now is very confusing.

Oh, sorry, I submitted a patch to do that and was asked for it
to include an example, and didn't get back to it.  I'll do it
real soon unless someone beats me to it.

I had asked that it wait for 4.3 since what was in 4.2 was very
preliminary.

Janis

Re: gimple

[Diego Novillo]

On Thu, Mar 27, 2008 at 19:55, Dasarath Weeratunge <[EMAIL PROTECTED]> wrote:
> Is it possible to map simplified source statements back to the
>  original source code in GCC?

Yes, using the debugging information associated with every statement.
Every statement has the file and line number of the original
statement.  See EXPR_FILENAME and EXPR_LINENO.

>  If this is not possible is it possible to stop the simplification
>  altogether and just retain the original
>  source tree in say DECL_SAVED_TREE(...) ? I tried removing tree
>  lowering passes but gcc still
>  seems to simplify the source.

No.  This is not possible.


Diego.

Successful native mingw build gcc 4.3.0

[Jonathan Blanchard]

Dunno if i should report it or not.

I successfully bootstrapped gcc 4.3.0 under mingw.

Env :

MinGW on WinXP SP2
GCC 4.3.0-tdm-2  with sjlj exceptions
Standard MinGW installation apart that

Output from the built gcc -v :

Using built-in specs.
Target: i686-pc-mingw32
Configured with: ./gcc-4.3.0/configure --prefix=/mingw
--enable-bootstrap --target=i686-pc-mingw32 --with-local-prefix=/mingw
--program-prefix= --with-as=/mingw/bin/as.exe
--with-ld=/mingw/bin/ld.exe --with-gcc --with-gnu-ld --with-gnu-as
--enable-languages=c,c++,objc,fortran --disable-nls
--disable-win32-registry --disable-werror --enable-sjlj-exceptions
--enable-threads=win32 --disable-symvers --disable-libstdcxx-pch
--enable-version-specific-runtime-libs
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
--enable-fully-dynamic-string --enable-libgomp
--enable-checking=release
Thread model: win32
gcc version 4.3.0 (GCC)

Note :

I had to copy include files and /bin directory to a temporary
/prefix/{target}/ directory because libgcc didn't configured
otherwise.
Without this configure was rambling about the sanity of my build environment...

Acknowledgment :

I took part of the building instructions from scripts used for the tdm
gcc cross-build.


-- 
Jonathan Blanchard