[Bug c/32314] New: for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[Bug c/32314] New: for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[malitzke at metronets dot com]

disable-decimal-float not working on i686, powerpc, sparc neither gcc-4.2.1 nor
gcc-4.3.0

Proof; below is a compossite from directory libdecnumber(top of config.status
and ls -l)

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by cpplib configure  , which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $ /var/tmp/gcc_r43/gcc-4.3.0/libcpp/configure --cache-file=./config.cache
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-nls
--disable-multilib --disable-werror --disable-libunwind-exceptions
--disable-checking --disable-decimal-float --enable-shared --enable-tls
--enable-threads=posix --enable-bootstrap --enable-__cxa_atexit
--enable-clocale=gnu --with-cpu=pentium3 --with-system-zlib
--enable-languages=c,c++,fortran --program-transform-name=s,y,y,
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
--srcdir=../../gcc-4.3.0/libcpp --with-build-libsubdir=.

## --------- ##
## Platform. ##
## --------- ##
......................

total 620
-rw-r--r-- 1 root root   7902 2007-06-12 18:40 Makefile
-rw-r--r-- 1 root root  18924 2007-06-12 18:40 charset.o
-rw-r--r-- 1 root root   7826 2007-06-12 18:40 config.cache
-rw-r--r-- 1 root root   8674 2007-06-12 18:40 config.h
-rw-r--r-- 1 root root  77880 2007-06-12 18:40 config.log
-rwxr-xr-x 1 root root  44155 2007-06-12 18:40 config.status
-rw-r--r-- 1 root root  21976 2007-06-12 18:40 directives.o
-rw-r--r-- 1 root root   2976 2007-06-12 18:40 errors.o
-rw-r--r-- 1 root root  17068 2007-06-12 18:40 expr.o
-rw-r--r-- 1 root root  14284 2007-06-12 18:40 files.o
-rw-r--r-- 1 root root   2216 2007-06-12 18:40 identifiers.o
-rw-r--r-- 1 root root   6364 2007-06-12 18:40 init.o
-rw-r--r-- 1 root root  17848 2007-06-12 18:40 lex.o
-rw-r--r-- 1 root root 152672 2007-06-12 18:40 libcpp.a
-rw-r--r-- 1 root root   3472 2007-06-12 18:40 line-map.o
-rw-r--r-- 1 root root     38 2007-06-12 18:40 localedir.h
-rw-r--r-- 1 root root     10 2007-06-12 18:40 localedir.hs
-rw-r--r-- 1 root root  17048 2007-06-12 18:40 macro.o
-rwxr-xr-x 1 root root 130464 2007-06-12 18:40 makedepend
-rw-r--r-- 1 root root   3848 2007-06-12 18:40 makedepend.o
-rw-r--r-- 1 root root   4652 2007-06-12 18:40 mkdeps.o
-rw-r--r-- 1 root root   7448 2007-06-12 18:40 pch.o
-rw-r--r-- 1 root root     10 2007-06-12 18:40 stamp-h1
-rw-r--r-- 1 root root   3980 2007-06-12 18:40 symtab.o
-rw-r--r-- 1 root root   9948 2007-06-12 18:40 traditional.o

What follows is __not__ directed against Mr. Cowlishaw; as he did a very
workman-like programming job.

It is directed against people within the gcc community who jointly perpetrated
a bad joke on the C language. If they insist on mixing C and decimal
arithmetic; plus adding insult to injury by making the disable not work; I
would suggest adding a new language to the GNU Compiler Collection as follows:

PL1-C or Cobol-ng.

Disclosure: I have a "Certificate in Data Processing". I got it about 35 years
ago while doing real-time assembly language body-shopping for a
"Beltway-Bandit" type outfit. I learned COBOL From the COBOL chapter in Jean E.
Sammet's  excellent book Book "Programming Languages: History and Fundamentals.
Enough Said"


-- 
           Summary:  for gcc-4.2gcc-4disable-decimal-float not working on
                    i686, powerpc, sparc.   gcc-4.3.0
           Product: gcc
           Version: 4.2.1
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: malitzke at metronets dot com
 GCC build triplet: i686-pc-linux-gnugcc-4disable-decimal-float not working
                    on i686,
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-06-13 05:44 -------
Even if you disable dfp, libdecnumber is still needed to compile gcc as
disable-decimal-float really just disables the C interface.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal
            Summary| for gcc-4.2gcc-4disable-   |for gcc-4.2gcc-4disable-
                   |decimal-float not working on|decimal-float not working on
                   |i686, powerpc, sparc.   gcc-|i686, powerpc, sparc.   gcc-
                   |4.3.0                       |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-06-13 05:46 -------
The main reason why you still need libdecnumber is because other front-ends
could support dfp even without the C/C++ front-ends supporting it.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[malitzke at metronets dot com]

-- 

malitzke at metronets dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pluto at agmk dot net
           Severity|normal                      |blocker
      Known to work|                            |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[malitzke at metronets dot com]

------- Comment #3 from malitzke at metronets dot com  2007-06-13 06:06 -------
Maybe some people should read __carefully__ both the C standard and the new
GPL3


-- 

malitzke at metronets dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-06-13 06:26 -------
> Maybe some people should read __carefully__ both the C standard and the new GPL3

What does that mean?   There is a working draft of dfp in the C standards
committee
See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1137.pdf

Also GPLv3 does not apply yet so what do you mean?

Again --disiable-decimal-float just disables the C interface and not the
support library.

Can you give more hints at what you really want from GCC?  If you want to
disable unused code, you have to do it manually because it is only partly
unused in the sense it will not be invoked but if you add a front-end that uses
it, you can still use it without recompiling the whole GCC.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[malitzke at metronets dot com]

------- Comment #5 from malitzke at metronets dot com  2007-06-13 07:09 -------
All I want for gcc is that it meets both the letter __and__ the spirit of
applicable contracts and specifications.

First, the GPL is a contract, do __not__  take my word for it but consult a
lawyer.

Second, the C standard can be and should be made part of a contract like a chip
manufacturer would sign with a major purchaser like Ford or GM  for embedded
chips and the included support software like gcc. After working 80 hours with
paid overtime) as a highly regarded real-time assembly programmer (before C
became available) I tripled my income (no paid overtime) as an international
telecommunications consultant (really RFP writer, contract negotiator,
acceptance tester), project engineer, co-writer of ITU (International
Telecommunications Union) specifications, and US-representative on technical
supervisory committees. I caused significant economic harm to contractors
(benefiting my employer or organizations I consulted for) by incorporating ITU
standards in contracts. Therefore I have some knowledge of these matters.

Three; gcc-4.3.0 and gcc-4.2.2 will most likely be released under the GPL3
(which not only is intended to replace GPL2 but also the lesser GPL for
libraries)

Four: under the C specification compiler writers can furnish extensions. But,
these extensions are required to have disablers.

Five: Yes, gcc is furnished by gnu.org mithout any warranty, or even being fit
for merchantability. However, __hidden__ items like libgcc might constitute
borderline cases. In the hands of a skillful lawyer, like Mr Edwards, these
hidden items could cause a lot of grief to gnu.org and the maintainers as a
group. Microsoft could even file an amicus curieae brief.





-- 

malitzke at metronets dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2007-06-13 07:30 -------
The C extensions are disabled with --disable-decimal-float.  I never said they
were not, in fact here is a quote from me:
Even if you disable dfp, libdecnumber is still needed to compile gcc as
disable-decimal-float really just disables the C interface

Again --disiable-decimal-float just disables the C interface and not the
support library.


----- cut ------
What don't you understand about "C interface"?

Also the library libdecnumber is licensed under GPL+extension and not LGPL. 
Please read the header and source files before saying they are under a license
when they are not.  This is just like libgcc's license.

GPLv3 is not going to replace GPL+ exception, the exception is still going to
be there, nothing is going to change.

To answer your points:
1) It is a copyright license, it gives you rights which you don't have before
with the code.

2) Use -pedantic-errors if you want full C90 complaint (or -std=c99
-pedantic-errors for C99).

3) see above about GPL+exception.

4) See above about my comments about disabling the C interface with
--disable-decimal-float and about -pedantic-errors in 1).

5) wtf, I really mean WHAT THE FUCK.  Come on, this is a joke, right?  But
really see my point about GPL+ exception, if you don't understand the
exception, then get a laywer to read it.  It is not like we are all lawyers
here.


So again --disable-decimal-float disables the C interface.  The version of the
library which is being compiled is really the library that gets linked into
GCC.


The code in c-decl.c shows that -pedantic-errors will disable this extension:
              if (!targetm.decimal_float_supported_p ())
                error ("decimal floating point not supported for this target");
              if (pedantic)
                pedwarn ("ISO C does not support decimal floating point");

And it also shows it will disable it for --disable-decimal-float as the default
(and only one) decimal_float_supported_p does:
bool
default_decimal_float_supported_p (void) 
{     
  return ENABLE_DECIMAL_FLOAT;
}

and ENABLE_DECIMAL_FLOAT is set to 0 by configure:
dfp=`if test $enable_decimal_float != no; then echo 1; else echo 0; fi`
AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_FLOAT, $dfp,
[Define to 1 to enable decimal float extension to C.])

Where enable_decimal_float is set:
AC_ARG_ENABLE(decimal-float,
[  --enable-decimal-float={no,yes,bid,dpd}
                        enable decimal float extension to C.  Selecting 'bid'
                        or 'dpd' choses which decimal floating point format
                        to use],
[
  case $enable_decimal_float in
    yes | no | bid | dpd) ;;
    *) AC_MSG_ERROR(['$enable_decimal_float' is an invalid value for
--enable-decimal-float.
Valid choices are 'yes', 'bid', 'dpd', and 'no'.]) ;;
  esac
],
[
  case $target in
    powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux*)
      enable_decimal_float=yes
      ;;
    *)
      AC_MSG_WARN(decimal float is not supported for this target, ignored)
      enable_decimal_float=no
      ;;
  esac
])


What more do you want to say? 


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[malitzke at metronets dot com]

------- Comment #7 from malitzke at metronets dot com  2007-06-16 13:08 -------
It is good to be challenged, as it forces clarification of the issues. It is
also good to let some grass grow instead of just charging ahead.

Putting the legal and philosophical ramifications aside and considering only
the technical issues; but, in a larger context, the following seems to apply.

The ICE issue in PR 32314 were a consequence of pursuing the decimal float
issue, but, it helps to also consider it here.

The closure is provided by the introduction of POINTER_PLUS.

While this might not be ideal forum for what follows I ask for indulgence in
order to put things into perspective.

There are really three levels to keep in mind and they are exemplified by:

1) POINTER_PLUS

2) Altivec and SSE

3) decimal float.

POINTER_PLUS is clearly an internal matter for GCC and the involved
specialists.
A user, like my self, has no right to question it or its merits.
Parenthetically, I consider it great because it makes GCC more transparent and
comprehensible. Size of the compilers, efficiency of both compiler and
generated code are clearly secondary (within even generous limits). Enough
said.

Altivec and SSE are borderline. Personally, I would love to have control over
how analysis, optimization, and code generation for a specialized instruction
set and data types, not mandated the the C standard, affect the compiler I use
for perhaps life threatening code.

However, as a practical matter, I realize that the build machinery for gcc may
make it well nigh impossible to eliminate Altivec of SSE from the areas of
analysis, optimization and code generation. I also doubt that the likes of
Altivec and SSE can be segregated  into libraries with minimal impact on the
compiler proper.

As a consequence, I might have only the choice of having the compiler built for
a model CPU not having altivec or SSE, and foregoing any concomitant
architectural improvements; or, taking any penalties in compiler complexity and
quality of generated code for data types that I have no intention of using.

Decimal_float: My analysis has shown that the only readily visible difference  
resulting from disable-decimal-float or enable-decimal-float is the doubling in
size of libgcc.a. Libgcc.so seems unaffected either way. I can only hope that
the impact on compiler complexity, ad-hoc code and propensity for bugs is
minimal. I hate the idea of having to use gcc versions prior to gcc-4.2.0 just
to completely avoid decimal float.

I will leave potential legal implications and inconsistencies resulting from
using COPYING.LIB and the gcc-specific disclaimer paragraph to another posting. 


-- 

malitzke at metronets dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenther at suse dot de,
                   |                            |janis187 at us dot ibm dot
                   |                            |com
           Severity|blocker                     |normal
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2007-06-17 06:54 -------
> Size of the compilers, efficiency of both compiler and generated code are clearly secondary
Do you even know why I added POINTER_PLUS_EXPR?  Did you even read my reply to
Jeff Law on why I started working on this project? My reply to Jeff explains
that generated code was my reason.  On SPU, you have only loads that are only
128 bit long and the alignment is 128 bits only.  So we need better alignment
information prograted down from the tree level to the RTL level.

http://gcc.gnu.org/ml/gcc/2007-05/msg00691.html

I guess you did not look at the other bug reports or commented on due to
pointer_plus either?  Where the code gen has been improved.  I guess you are
making comments to just make comments.

 And what does pointer_plus, SSE, Altivec have in common.  Besides me caring
about 2 of those.  Nothing.  In fact the later two have less in common than you
think.  Yes they are both vector extensions.  

I will mention about Altivec (VMX for me), I work on the PS3 toolchain and I
really really do care about code generation and performance of the compiler.  I
work mostly on the PPU (PowerPC) side of things but every once in a while I
work on the SPU side.

If you want to compile only standards conforming code, then use
-pedantic-errors as documented in the GCC manual which it seems you don't read.

This is not a bug as --disable-decimal-float disables the C/C++ interfaces to
the underlaying GCC support.  Guess you don't understand that GCC is more than
a C/C++ compiler.  GCC stands for GNU Compiler Collection and NOT GNU C
Compiler.  

One more thing about pointer plus, have you seen how much time I actually spent
on working on this project?  It took more around 6.5 months (including time
working on other stuff).  I guess you don't care that I needed approval from my
manager to work on this project and then get approval to apply it and also
review time also?  If you don't see the last two, then you need to read the GCC
lists better.  I was very open about what currently works and what I could
test.  I don't think you have a right to tell me that my work is shit when you
obviously did not read anything I have done about being straight forward about
this project.  Yes pointer plus was a big project, it was needed to allow GCC
to complete with other compilers, even to get code generation back to where it
was in 3.4 in many many cases. 

Take a look at PR 18412, PR 29708, PR 32273, PR 16913 (which still has issues
but the main issue is solved by pointer_plus), PR 20643 (which is improved by
pointer_plus but I don't know if it is all the way fixed), PR 21485 (where the
original testcase fixed by pointer_plus), PR 28690 is helped by pointer plus
(got SPEC results for Power6 with pointer plus vs without).  So what more do
you want?  that is 7 code generation issues, some of them are regressions
fixed/helped by pointer_plus.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[malitzke at metronets dot com]

------- Comment #9 from malitzke at metronets dot com  2007-06-17 18:01 -------
Thank you for your very informative post.

What we have between us is really a philosophical difference.

To me C is a portable assembler and my extensive review of Ritchie's writings
and acceptance speech for the Turing award leads me to believe that the correct
code generation under absolute control of the programmer was paramount. Even
the portability issue came much later at Bell Labs. That was when to my
reckoning Ritche handed over C to the PCC (portable C compiler) crowd using LEX
YACC etc.

Yes, to me there is profound truth in "Optimize, don't". Instead look for a
better algorithm. And, as as an engineer a soldering iron and a screwdriver (a
better CPU and support chips like the Cell processor) are among the best
optimization tools. 

FORTRAN was actually my first high level language and my first significant
FORTRAN (formula translation) ran on the day President Kennedy was murdered,
and the computer center closed. I worked on systems with triple computer
redundancy and and majority voting. Boy, would I have loved a Ritchie type C
compiler. One of my best accomplishments was cutting the interrupt line and and
making that central office telephone exchange into scanning system and handle
the contractual  specified 95000 calls per hour instead of 67000. It lso made
me the best hated guy in that development lab and led to a very profitable job
change.  

Yes, I consider JAVA an abomination, I still harbor a remnant of respect for
SUN because of the NFS (network file system). When Dr. hc. William Gates
admitted that C++ set back Microsoft two years; it my made  not only my day but
my whole month. His genius is in motivating nerds to work 12-16 hours a day
producing lousy code and not as progamer (somebody else wrote a vital part of
the BASIC interpreter). C with classes is fantastic to somebody whose thesis
contained a discrete event simulation package written in FORTRAN and assembly.
Microsoft and Academia reduced C++ to the recent quip "When your tool is C++,
the world is reduced to thumbs" (half-assed quote).

K&R second program "Fahrenheit-Celsius" uses integers and not floating point.
Based on that and knowing that existed no decent FORTRAN compilers on the early
UNIX machines I take it that floating point was more a political necessity than
  a technical requirement. I would love to eliminate floating point from C  and
use fortran-95 for my numerical solutions of stiff partial differential
equations. 

Now your first four paragraphs and my previous comment realy express the same
thing, but from different perspective. Let me quote   
"great because it makes GCC more transparent and comprehensible" What I meant
with this is that GCC now has one more leg built on sound principle instead of
a
(perheaps jumble of ad-hoc stuff. This in creases my confidence the addresses
generated point to the right object. This put you as the lead guy into the same
league as Diego Novillo, Sebastian Pop, Palo Carlini, Zdenek Dvorak I had the
priviledge of helping in a small way. In my book this a big step up from
bug-man. To system houses, chip manufacturers, gcc collegues obsessed with
optimization you had to stress the speed-up. I want assurance that the code
generated produces the right result, even if it makes the compiled bigger and
the code generated for small arrays a tad slower. To me POINTER_PLUS affects
code throughout the compiler collection and not just some instruction on some
architecture. I am quite willing to write you a glowing recommendations should
you think it appropriate. That we rub each other at times the wrong way is
unfortunate bu no really relevant.

Proof that you are doing great, from my perspective, Is that when I checked the
Changelog after svn I searched and found your technical write-up, understood
that this good stuff and immediately did a a bootstrap. It certainly produced
no discernable degradation which is great no a new fundamental step.

Altivec and SSE really produce benefits in a relatively small corner of the
overal picture, They are, again in my book, part of their architectures more
for competive reason than producing fundamental improvements. However changes
to the config tree and to code generation to me far outweigh the benefits
overall. But it seems imppossible to quarantine them.

I have to admit that DFA really rubs me the wrong way for C.

Finally, there exists huge, to me bloated, file  called cc1. This is the C
compiler and not GCC. Again I admit that I really only care about cc2 and f951,
I tolerate cc1plus, and the rest have no place on my machines, I own those
machines and aunder the GNU and UNIX philosophy that is up to me. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[malitzke at metronets dot com]

------- Comment #10 from malitzke at metronets dot com  2007-06-17 23:29 -------
Let me reiterate: I am not admitted to the bar in any USA state, nor
the District of Columbia. Hence, I can not and I am not offering
any legal advice. For legal advice see a lawyer admitted to the bar.
Yes, I have worked extensively with lawyers preparing contracts, briefs
and filings to regulatory agencies and also provided sworn depositions
and know some of the jargon.

Lets us start with a package, GLIBC, that I consider consistent and
which gives me corresponding reassurance.

First a randomly selected introductory paragraph and the the paragraph
that comes close to the stated GCC exception because of the reference
to the GNU Lesser General Public License.

   Copyright (C) 1991, 1995, 1996, 1997, 2002 Free Software Foundation, Inc.
   This file is part of the GNU C Library.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.

COPYING and COPYING.LIB are in the root directory of the package, and I
assume these two apply to the package as a whole. 

COPYING has as its title "GNU General Public License" and COPYING.LIB
has as its tile "GNU Lesser General Public License".

Section 6 I take as the essence of is termed the GGC-exception. But, 
to me it is section 13:


  13. The Free Software Foundation may publish revised and/or new
versions of the Lesser General Public License from time to time.
Such new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.

that really gives me confort and that is missing in the GCC verbiage.

Now even in the directory gcc, ever since gcc-3.3.6

gcc-3.3.6_except_libgcc_c

In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file.  (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine (sic)
executable.)


gcc-3.3.6_except_libgcc_h

As a special exception, if you link this library with other files,
some of which are compiled with GCC, to produce an executable,
this library does not by itself cause the resulting executable
to be covered by the GNU General Public License.
This exception does not however invalidate any other reasons why
the executable file might be covered by the GNU General Public License.

the two cited parapgraphs are not equal and they imperfectly
convey some of the idea of COPYING.LIB, which should then be
removed from the root directory.

As each release is really a new work the exception paragraph
could be removed with a simple sed script. This then would
bring back the dreaded viral property as advocated by Mr.
Stallman.


However, when a library provides a significant unique capability, like GNU
Readline, that's a horse of a different color. The Readline library implements
input editing and history for interactive programs, and that's a facility not
generally available elsewhere. Releasing it under the GPL and limiting its use
to free programs gives our community a real boost. At least one application
program is free software today specifically because that was necessary for
using Readline.


In conclusion, the GCC_exception paragraph needs the something like section 13
quoted above


-- 

malitzke at metronets dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2007-06-17 23:34 -------
Actually no it does not, anyways the exception was written by lawyers.  If you
want to change the exception, go talk to the FSF (and RMS) and not us as we
don't control the license. 


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[malitzke at metronets dot com]

------- Comment #12 from malitzke at metronets dot com  2007-06-18 00:06 -------
Did you even read comment 9?


-- 

malitzke at metronets dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WORKSFORME                  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314

[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2007-06-18 00:26 -------
>Altivec and SSE really produce benefits in a relatively small corner of the overal picture

Why do you think that?  It is not true.

This is all getting offtopic from the original issue.  The original question
has to do with --disable-decimal-float not turning off dfp.  If we look at that
issue alone, the option does turn off the C/C++ interface which is what it is
documented as doing, from the install docs:
Enable (or disable) support for the C decimal floating point extension that is
in the IEEE 754R extension to the IEEE754 floating point standard. This is
enabled by default only on PowerPC, i386, and x86_64 GNU/Linux systems. Other
systems may also support it, but require the user to specifically enable it.
You can optionally control which decimal floating point format is used (either
`bid' or `dpd'). The `bid' (binary integer decimal) format is default on i386
and x86_64 systems, and the `dpd' (densely packed decimal) format is default on
PowerPC systems. 

It never said disable the internal support for dfp, yes you might assume that
is true but it would make things more complex inside GCC.

So going back to the orignal issue, this bug is invalid based on what the
option does exactly what the documentation says it does.

Next time please read the documentation and check that stuff is working
correctly before submitting a bug report.

PS now you are using this bug report, I have no idea what and to complain about
who can understand what any more.  Also C is and has never been a high level
assembly.  Please read the C standard to understand that was never true.  

If you want a real small cc1, go back to the days of GCC 1.x where GCC actually
stood for GNU C Compiler.  Even back then GCC was bloated.  Also POinter Plus
reduced the size of cc1 :)  The diffstat on the patch would have told you that.
 But all of this offtopic from the original issue.

If you want to complain about not disabling the internal part for dfp, please
either submit a patch (read http://gcc.gnu.org/contribute.html for more info)
or submit a new bug but note it will be marked as an enchement because it is
actually hard to do (I already looked into doing it after you and someone else
noticed it).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314