Even if you disable dfp, libdecnumber is still needed to compile gcc as disable-decimal-float really just disables the C interface.

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.

Maybe some people should read __carefully__ both the C standard and the new GPL3

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

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.


   

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? 

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.  

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

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. 

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

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. 

Did you even read comment 9?

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