[PATCH 0/4] Docs: extend.texi
See the following emails for a few inlined patches to /trunk/gcc/doc/extend.texi: [1] Docs: extend.texi: Add missing semicolon for consistency [2] Docs: extend.texi: Remove trailing blanks from lines [3] Docs: extend.texi: Rearrange nodes; no text was removed or added [4] Docs: extend.texi: Reword and rearrange attribute node introductions trunk/gcc/doc/extend.texi | 5449 +++-- 1 files changed, 2730 insertions(+), 2719 deletions(-) -- 1.7.4.18.g68fe8
[PATCH 1/4] Docs: extend.texi: Add missing semicolon for consistency
--- trunk/gcc/doc/extend.texi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi index eddff95..c154958 100644 --- a/trunk/gcc/doc/extend.texi +++ b/trunk/gcc/doc/extend.texi @@ -3997,7 +3997,7 @@ @smallexample __attribute__((noreturn)) void d0 (void), __attribute__((format(printf, 1, 2))) d1 (const char *, ...), - d2 (void) + d2 (void); @end smallexample @noindent -- 1.7.4.18.g68fe8
[PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
sed -i "s/[ $(printf '\t')]\{1,\}\$//" trunk/gcc/doc/extend.texi
---
trunk/gcc/doc/extend.texi | 82 ++--
1 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi
index c154958..cdbf69f 100644
--- a/trunk/gcc/doc/extend.texi
+++ b/trunk/gcc/doc/extend.texi
@@ -37,7 +37,7 @@
* Complex:: Data types for complex numbers.
* Floating Types:: Additional Floating Types.
* Half-Precision:: Half-Precision Floating Point.
-* Decimal Float:: Decimal Floating Types.
+* Decimal Float:: Decimal Floating Types.
* Hex Floats:: Hexadecimal floating-point constants.
* Fixed-Point:: Fixed-Point Types.
* Named Address Spaces::Named address spaces.
@@ -455,7 +455,7 @@
safe.
GCC implements taking the address of a nested function using a technique
-called @dfn{trampolines}. This technique was described in
+called @dfn{trampolines}. This technique was described in
@cite{Lexical Closures for C++} (Thomas M. Breuel, USENIX
C++ Conference Proceedings, October 17-21, 1988).
@@ -619,7 +619,7 @@
@}
return open (path, oflag, __builtin_va_arg_pack ());
@}
-
+
if (__builtin_va_arg_pack_len () < 1)
return __open_2 (path, oflag);
@@ -942,7 +942,7 @@
@cindex @code{__fp16} data type
On ARM targets, GCC supports half-precision (16-bit) floating point via
-the @code{__fp16} type. You must enable this type explicitly
+the @code{__fp16} type. You must enable this type explicitly
with the @option{-mfp16-format} command-line option in order to use it.
ARM supports two incompatible representations for half-precision
@@ -963,7 +963,7 @@
The @code{__fp16} type is a storage format only. For purposes
of arithmetic and other operations, @code{__fp16} values in C or C++
expressions are automatically promoted to @code{float}. In addition,
-you cannot declare a function with a return value or parameters
+you cannot declare a function with a return value or parameters
of type @code{__fp16}.
Note that conversions from @code{double} to @code{__fp16}
@@ -971,14 +971,14 @@
of rounding, this can sometimes produce a different result than a
direct conversion.
-ARM provides hardware support for conversions between
+ARM provides hardware support for conversions between
@code{__fp16} and @code{float} values
as an extension to VFP and NEON (Advanced SIMD). GCC generates
code using these hardware instructions if you compile with
-options to select an FPU that provides them;
+options to select an FPU that provides them;
for example, @option{-mfpu=neon-fp16 -mfloat-abi=softfp},
in addition to the @option{-mfp16-format} option to select
-a half-precision format.
+a half-precision format.
Language-level support for the @code{__fp16} data type is
independent of whether GCC generates code using hardware floating-point
@@ -1995,7 +1995,7 @@
@cindex @code{alloc_size} attribute
The @code{alloc_size} attribute is used to tell the compiler that the
function return value points to memory, where the size is given by
-one or two of the functions parameters. GCC uses this
+one or two of the functions parameters. GCC uses this
information to improve the correctness of @code{__builtin_object_size}.
The function parameter(s) denoting the allocated size are specified by
@@ -2004,7 +2004,7 @@
of the two function arguments specified. Argument numbering starts at
one.
-For instance,
+For instance,
@smallexample
void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)))
@@ -2213,7 +2213,7 @@
attribute also implies ``default'' visibility. It is an error to
explicitly specify any other visibility.
-In previous versions of GCC, the @code{dllexport} attribute was ignored
+In previous versions of GCC, the @code{dllexport} attribute was ignored
for inlined functions, unless the @option{-fkeep-inline-functions} flag
had been used. The default behaviour now is to emit all dllexported
inline functions; however, this can cause object file-size bloat, in
@@ -2424,10 +2424,10 @@
are @code{printf_unlocked} and @code{fprintf_unlocked}.
@xref{C Dialect Options,,Options Controlling C Dialect}.
-For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
+For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
recognized in the same context. Declarations including these format attributes
will be parsed for correct syntax, however the result of checking of such
format
-strings is not yet defined, and will not be carried out by this version of the
+strings is not yet defined, and will not be carried out by this version of the
compiler.
The target may also provide additional types of format checks.
@@ -2752,7 +2752,7 @@
synonyms, and cause the compiler to always call
the function by first loading its address into a register, and then using
the contents of that register. The @code{near} attri
[PATCH 4/4] Docs: extend.texi: Reword and rearrange attribute node introductions
The arrangement performed in the previous patch left the text in
somewhat of an inconsistent state; this returns the flow of concepts
to something more sane.
---
trunk/gcc/doc/extend.texi | 53 +++-
1 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi
index 3b453e5..a9611de 100644
--- a/trunk/gcc/doc/extend.texi
+++ b/trunk/gcc/doc/extend.texi
@@ -1962,10 +1962,22 @@
@cindex attribute syntax
This section describes the syntax with which @code{__attribute__} may be
-used, and the constructs to which attribute specifiers bind, for the C
+used, and the constructs to which attribute specifiers bind for the C
-language. Some details may vary for C++ and Objective-C@. Because of
+language and (to a limited degree) some of its descendants.
+
+The keyword @code{__attribute__} allows you to specify special
+attributes when making a declaration. This keyword is followed by an
+attribute specification inside double parentheses.
+
+You may also specify attributes with @samp{__} preceding and following
+each keyword. This allows you to use them in header files without
+being concerned about a possible macro of the same name. For example,
+you may use @code{__noreturn__} instead of @code{noreturn}.
+
+GCC plugins may provide their own attributes.
+
-infelicities in the grammar for attributes, some forms described here
-may not be successfully parsed in all cases.
+Because of infelicities in the grammar for attributes, some forms
+described here may not be successfully parsed in all cases.
There are some problems with the semantics of attributes in C++. For
example, there are no manglings for attributes, although they may affect
@@ -2191,6 +2203,9 @@
@cindex attribute of types
@cindex type attributes
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
+
The keyword @code{__attribute__} allows you to specify special
attributes of @code{struct} and @code{union} types when you define
such types. This keyword is followed by an attribute specification
@@ -2583,6 +2598,9 @@
@cindex attribute of variables
@cindex variable attributes
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
+
The keyword @code{__attribute__} allows you to specify special
attributes of variables or structure fields. This keyword is followed
by an attribute specification inside double parentheses. Some
@@ -3214,14 +3232,17 @@
@cindex functions that have different optimization options
@cindex functions that are dynamically resolved
-In GNU C, you declare certain things about functions called in your program
-which help the compiler optimize function calls and check your code more
-carefully.
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
-The keyword @code{__attribute__} allows you to specify special
-attributes when making a declaration. This keyword is followed by an
-attribute specification inside double parentheses. The following
-attributes are currently defined for functions on all targets:
+The keyword @code{__attribute__} allows you to specify special attributes
+of function declarations in order to help the compiler optimize function
+calls and check your code more carefully. This keyword is followed by
+an attribute specification inside double parentheses. Other attributes
+are available for types (@pxref{Type Attributes}) and for variables
+(@pxref{Variable Attributes}).
+
+The following attributes are currently defined for functions on all targets:
@code{aligned}, @code{alloc_size}, @code{noreturn},
@code{returns_twice}, @code{noinline}, @code{noclone},
@code{always_inline}, @code{flatten}, @code{pure}, @code{const},
@@ -3237,16 +3258,6 @@
including @code{section} are supported for variables declarations
(@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
-GCC plugins may provide their own attributes.
-
-You may also specify attributes with @samp{__} preceding and following
-each keyword. This allows you to use them in header files without
-being concerned about a possible macro of the same name. For example,
-you may use @code{__noreturn__} instead of @code{noreturn}.
-
-@xref{Attribute Syntax}, for details of the exact syntax for using
-attributes.
-
@table @code
@c Keep this table alphabetized by attribute name. Treat _ as space.
--
1.7.4.18.g68fe8
Re: [PATCH 3/4] Docs: extend.texi: Rearrange nodes; no text was removed or added
> However, the same effect of applying this patch can be produced by running > the following commands on revision 172911 ... That's not exactly correct; it is naturally assumed that the previous patches: [1] Docs: extend.texi: Add missing semicolon for consistency [2] Docs: extend.texi: Remove trailing blanks from lines have been applied to revision 172911.
Re: [PATCH 0/4] Docs: extend.texi
On Wed, Apr 27, 2011 at 18:42, Jonathan Wakely wrote: > On 28 April 2011 00:32, Michael Witten wrote: >> See the following emails for a few inlined patches >> to /trunk/gcc/doc/extend.texi: >>... > > Patches should go to gcc-patches, not this list. > > http://gcc.gnu.org/lists.html > I apologize!
Re: [PATCH 0/4] Docs: extend.texi
On Wed, Apr 27, 2011 at 18:50, Jonathan Wakely wrote: > You also need to explain the reason for your patches. > > http://gcc.gnu.org/contribute.html#patches > > 1 and 2 might be self-explanatory, but what are 3 and 4 for? Why are > your changes useful? Thank you for the help; however, I believe they are more than adequately explained by the subjects and contents of those particular emails.
Re: [PATCH 0/4] Docs: extend.texi
On Wed, Apr 27, 2011 at 18:48, Michael Witten wrote: > On Wed, Apr 27, 2011 at 18:42, Jonathan Wakely wrote: >> On 28 April 2011 00:32, Michael Witten wrote: >>> See the following emails for a few inlined patches >>> to /trunk/gcc/doc/extend.texi: >>>... >> >> Patches should go to gcc-patches, not this list. >> >> http://gcc.gnu.org/lists.html >> > > I apologize! I am intending to send them again to the proper list; is this considered the correct move now that the patches have been sent here?
Re: MPC required in one week.
On Mon, Nov 30, 2009 at 12:04 AM, Kaveh R. GHAZI wrote: > The patch which makes the MPC library a hard requirement for GCC > bootstrapping has been approved today. Out of curiosity and ignorance: Why, specifically, is MPC going to be a hard requirement? On the prerequisites page, MPC is currently described with: "Having this library will enable additional optimizations on complex numbers." Does that mean that such optimizations are now an important requirement? or is MPC being used for something else?
Re: Support for export keyword to use with C++ templates ?
On Fri, Jan 29, 2010 at 8:05 PM, Paolo Carlini wrote: > Even for implementors knowing *very* well both the details of the C++ > standard and the internals of a specific front-end, implementing export > is an *highly* non-trivial task. However, I have a gut feeling that at least a restricted version of 'export' (or a cousin of 'export') could be both useful and trivial to implement: Perhaps a limited form could simply automate the not-infrequently employed practice of creating a translation unit specifically for explicit template instantiations. Sincerely, Michael Witten
Re: Support for export keyword to use with C++ templates ?
On Sun, Jan 31, 2010 at 6:38 PM, Paolo Carlini wrote: > it's extremely > unlikely that the C++ front-end maintainers could even consider > reviewing patches from a novice for such an hard to implement feature. That says more about the tangled mess that is gcc then about any particular programmer's ability.
Re: Code assistance with GCC
On Wed, Apr 21, 2010 at 12:49, Andrew Haley wrote: > On 04/21/2010 06:35 PM, Chris Lattner wrote: >> This approach seems highly, uh, "inspired" from the exact same >> functionality in Clang. Any reason not to contribute to that >> effort? > > Surely trying to persuade people to contribute to some other project > rather than gcc is off-topic here. Even if not, it's pretty hostile. Chris Lattner of Apple Chief architect of the LLVM project and Clang. Andrew Haley of Red Hat Maintainer of the GCC's Java frontend. Michael Witten Preparer of Popcorn. :-D
Re: Why not contribute? (to GCC)
On Fri, Apr 23, 2010 at 14:10, Richard Kenner wrote: > I've happened to be looking at a number of other free-software projects > recently (having nothing to do with compilers) and find the quality of the > code ABSOLUTELY APALLING. The formatting is random and very hard to read. > There are almost no comments. There are few, if any, indications of what > each function is supposed to do. And many of these projects have no > documentation AT ALL except for some small FAQs or Wikis. Funny. I've always felt the same way about gcc and most GNU codebases... In fact, I've always felt the same way about the vast majority of codebases that aren't my own :-D
Re: Why not contribute? (to GCC)
On Fri, Apr 23, 2010 at 13:39, Manuel López-Ibáñez wrote: > What reasons keep you from contributing to GCC? I'm really quite the outsider (I don't even deserve to be called a "lurker"), but my impression is that the common wisdom among the proles is that gcc is bloated and crufty and everyone is just waiting for a switch-over to something "new and clean and efficient" like the LLVM/Clang. Maybe GCC needs a good Public Relations campaign.
Re: Why not contribute? (to GCC)
On Fri, Apr 23, 2010 at 15:36, Manuel López-Ibáñez wrote: > In any case, I think coming from you it is a bit hurtful because I > have personally fixed many of your bugs and I haven't seen a > single beer yet! Where is my beer? Where's his beer for finding bugs?
Re: Why not contribute? (to GCC)
Richard Kenner wrote: >>> I've happened to be looking at a number of other >>> free-software projects recently (having nothing to >>> do with compilers) and find the quality of the code >>> ABSOLUTELY APALLING. The formatting is random and very >>> hard to read. There are almost no comments. There are >>> few, if any, indications of what each function is >>> supposed to do. And many of these projects have no >>> documentation AT ALL except for some small FAQs or >>> Wikis. Michael Witten wrote: >> Funny. I've always felt the same way about gcc and most >> GNU codebases... >> >> In fact, I've always felt the same way about the vast >> majority of codebases that aren't my own :-D Manuel López-Ibáñez wrote: > Maybe contributing will teach you some team skills and > style-tolerance? ;-) > > I felt a bit silly writing in GNU style at the > beginning, but you get used to it because it is > consistent. Now I can switch more easily between > different styles and I don't feel the urge to rewrite > everything in my style. I guess is like learning > different languages. I can play along fine with different styles (even if I disagree with most of them); indeed, GNU's style can be very logical (indenting the braces, for instance, makes a lot of sense to me---though I don't normally do so). My main problem is largely with identifier naming and file/code organization (which *can* involve style via the use of whitespace). Most people don't put too much thought into these issues (particularly the matter of organization), which betrays a lack of appreciation for abstraction that ultimately taints the design and code itself. My rule of thumb: good code is largely self-documenting. Let me make that statement stronger: If people are complaining that the documentation for the code is horrible, then they are essentially complaining that the code is horrible; it should be trivial: [0] to find any definition without grepping or using something like ctags. [1] to find the highest-level of abstraction from which to begin a top-down reading. [2] to understand what any block of code is doing (this follows from [0] and [1], and essentially promotes maintaining the proper level of abstraction for each such block). Following these ideals basically forces a programmer to write code as though it is meant to be read and understood by *others*; that's crucial to being able to work within a team (especially one distributed around the world). Unfortunately, the signal usually gets lost in the noise produced by people who don't care as much, and I call those noisy people "hackers"; the world is full of hackers---they are great for the short-term but terrible for the long term. Sincerely, Michael Witten
Re: Why not contribute? (to GCC)
On Fri, Apr 23, 2010 at 15:58, Manuel López-Ibáñez wrote: > On 23 April 2010 22:44, Michael Witten wrote: >> On Fri, Apr 23, 2010 at 15:36, Manuel López-Ibáñez >> wrote: >>> In any case, I think coming from you it is a bit hurtful because I >>> have personally fixed many of your bugs and I haven't seen a >>> single beer yet! Where is my beer? >> >> Where's his beer for finding bugs? > > I don't complain that he doesn't find more and better bugs. I don't > request him to find *my* bugs. I was pointing out that he too has provided a service to the project. > > Anyway, this is off-topic, and stop trying to incite people to fight, > in this and other threads, please. It is not the first time you do it. > If you just hate gcc so much, just leave. Thanks, I don't know what you're talking about. If anything, your comments have been off-topic and inciteful.
Re: Why not contribute? (to GCC)
On Fri, Apr 23, 2010 at 17:12, Richard Kenner wrote: > I there's no substitute for proper comments. Oh I agree! However, I proffer that the need to write a comment is often an indication for the need to write the code better (and to choose another programming language). > good code can't give the SPECIFICATIONS of a function... This may largely be a sign that the formal language is not expressive enough; in particular, the language should at least try to support abstraction formally (hence, binary < assembly < C < C++). Unfortunately, we still have a long way to go before our formal languages are capable enough to replace comments significantly. > Also, an important thing to put in comments is WHY something > is done the way it is and (more importantly) why it ISN'T done > another way. No amount of good quality code can contain that > information. Indeed!
Re: Why not contribute? (to GCC)
On Sun, Apr 25, 2010 at 11:33, Richard Kenner wrote: > There's nothing to have a problem WITH! No assignment has taken place. > The statement on the web has no legal significance whatsoever. Unless > the company SIGNS something, they still own the copyright on the code > and can, at any time, decide they don't want it distributed. If I submit a patch to the GCC project---necessitating an assignment of the copyright to the FSF---then can the people of the FSF decide that they don't want me to distribute my own work in another project (proprietary or otherwise)? That is, could I actually become liable for infringing on the copyright of my own original work? Are we just trusting RMS not to be a troll (tongue-in-cheek)?
Re: Why not contribute? (to GCC)
On Sun, Apr 25, 2010 at 21:12, Manuel López-Ibáñez wrote: > On 26 April 2010 02:12, Mark Mielke wrote: >> >> All in all, pretty minor. GCC wants FSF copyright assignment and employer >> disclaimers? GCC will not have as many contributors. Your choice. >> >> There are plenty of projects that we (lurkers / non contributors) can >> contribute to other projects that are not as mature and require more >> attention, or even other compilers (LLVM?). > > Are you 100% sure that the fact that LLVM does not ask for your > employer disclaimer means that you do not need to ask your employer > for some paper to legally contribute code? Are you sure you are not > exposing yourself to a legal risk? I would check with a lawyer if that > is the case. A real lawyer, not some computer guy that says "Oh, just > give us your code, it will be fine. Don't worry! We don't ask for > anything." And a lawyer that is not interested in keeping you at risk > just in case they need to sue you at some moment. I thought it was decided in the course of this thread that the liability of an individual contributor is ultimately NOT changed by the assignment of the copyrights to the FSF. Also, Mark's point (I think) is that a copyright lawsuit against the FSF is much more likely than a lawsuit against some no-name contributor, and (more importantly) a lawsuit against the FSF is likely to trigger the FSF to launch a lawsuit against the individual contributor. Thus, it sort of seems to the individual contributor that assigning copyrights to the FSF while maintaining 'unlimited liability' is less safe than not assigning copyrights to the FSF.
Re: Why not contribute? (to GCC)
On Mon, Apr 26, 2010 at 21:03, Mark Mielke wrote: > They can take a copy of your code and modify it, but at no time does your > original code become non-free. As long as people continue to copy from your > "free" version of the code, they can continue to use it for "free". > > The GPL isn't free though. The GPL is a limited use license that restricts > freedoms in such a way that there is some expectation that the lost freedoms > can purchase future freedom, and this compromise is justified. > > Many of us don't agree that the compromise is justified. You keep missing the fact that the GPL is meant to protect the USER's right to play with the software. Read about Tivoization. As far as the rights of the author, the GPL basically just protect's the author's wish that his software be distributed under the GPL.
Re: anonymous struct
On Sun, May 2, 2010 at 22:47, wuyin wrote: > Please support this grammar. > http://sourceforge.net/projects/coo/ My advice is to use a language with proper abstraction facilities, like C++.
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 11:22, Diego Novillo wrote: > Now that the SC and the FSF have agreed to this. When did this come up and why? Where can I read more about this? Was there a thread I missed?
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 13:21, Michael Witten wrote: > On Mon, May 31, 2010 at 11:22, Diego Novillo wrote: >> Now that the SC and the FSF have agreed to this. > > When did this come up and why? Where can I read more about this? Was > there a thread I missed? Nevermind! It's a fairly recent thread :-)
"Bootstrap comparison failure!"
I wanted to create a bugzilla bug report, but I seem to have forgotten my password; moreover, it would seem that bugzilla isn't actually sending out password-change emails. Here's the build error: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/reg-stack.o differs gcc/i386.o differs gcc/reload.o differs gcc/recog.o differs gcc/dwarf2out.o differs libiberty/hashtab.o differs Source Information: Revision 162274 No modifications. Build Environment: GNU/Linux 2.6.35-rc5 Intel(R) Pentium(R) M processor 2.13GHz GenuineIntel (32-bit, i686) $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-gnu-unique-object --enable-lto --enable-plugin --disable-multilib --disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info Thread model: posix gcc version 4.5.0 20100610 (prerelease) (GCC) Build Configuration Built outside of SVN working directory (in a separate build directory) - config.log - This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ ../repo/configure --prefix=/usr/local --program-suffix=-svn --disable-multilib --enable-threads=posix --enable-maintainer-mode --enable-languages=c,c++ --enable-gnu-unique-object --with-lto ## - ## ## Platform. ## ## - ## uname -m = i686 uname -r = 2.6.35-rc5 uname -s = Linux uname -v = #34 Wed Jul 14 16:02:05 CDT 2010 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /opt/autoconf/2.64/bin PATH: /bin PATH: /usr/bin PATH: /sbin PATH: /usr/sbin PATH: /opt/NX/bin PATH: /usr/bin/perlbin/site PATH: /usr/bin/perlbin/vendor PATH: /usr/bin/perlbin/core ## --- ## ## Core tests. ## ## --- ## configure:2429: checking build system type configure:2443: result: i686-pc-linux-gnu configure:2490: checking host system type configure:2503: result: i686-pc-linux-gnu configure:2523: checking target system type configure:2536: result: i686-pc-linux-gnu configure:2590: checking for a BSD-compatible install configure:2658: result: /bin/install -c configure:2669: checking whether ln works configure:2691: result: yes configure:2695: checking whether ln -s works configure:2699: result: yes configure:2706: checking for a sed that does not truncate output configure:2770: result: /bin/sed configure:2779: checking for gawk configure:2795: found /bin/gawk configure:2806: result: gawk configure:4060: checking for gcc configure:4076: found /usr/bin/gcc configure:4087: result: gcc configure:4316: checking for C compiler version configure:4325: gcc --version >&5 gcc (GCC) 4.5.0 20100610 (prerelease) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:4336: $? = 0 configure:4325: gcc -v >&5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-gnu-unique-object --enable-lto --enable-plugin --disable-multilib --disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info Thread model: posix gcc version 4.5.0 20100610 (prerelease) (GCC) configure:4336: $? = 0 configure:4325: gcc -V >&5 gcc: '-V' option must have argument configure:4336: $? = 1 configure:4325: gcc -qversion >&5 gcc: unrecognized option '-qversion' gcc: no input files configure:4336: $? = 1 configure:4356: checking for C compiler default output file name configure:4378: gcc -march=i686 -mtune=pentium-m -O2 -pipe -Wl,--hash-style=gnu -Wl,--as-needed conftest.c >&5 configure:4382: $? = 0 configure:4419: result: a.out
Re: Turn on -fomit-frame-pointer by default for 32bit Linux/x86
On Sun, Aug 8, 2010 at 09:56, Uros Bizjak wrote: > > IMO, we have to bite the bullet from time to time in order to improve > the generated code. What's your performance function? I like backtraces.
Re: Turn on -fomit-frame-pointer by default for 32bit Linux/x86
On Sun, Aug 8, 2010 at 10:08, Uros Bizjak wrote: > On Sun, Aug 8, 2010 at 5:00 PM, Michael Witten wrote: >> On Sun, Aug 8, 2010 at 09:56, Uros Bizjak wrote: >>> >>> IMO, we have to bite the bullet from time to time in order to improve >>> the generated code. >> >> What's your performance function? > > See measurements at [1]. The point is that *my* performance function may be a measure of the availability of decent backtraces. > So, you will be able to use --enable-frame-pointer configure option. Most of the computing world would probably benefit far more from usable backtraces than from increases in efficiency; those individuals who fret about efficiency are likely better suited to fiddling with non-default flags.
Re: Turn on -fomit-frame-pointer by default for 32bit Linux/x86
On Sun, Aug 8, 2010 at 10:30, Andi Kleen wrote: >> > I like backtraces. >> > >> >> So, you will be able to use --enable-frame-pointer configure option. >> >> [1] http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02034.html > > ... or use backtrace() What kind of black magic would you expect backtrace() to use? >From the `info backtrace' text: Note that certain compiler optimizations may interfere with obtaining a valid backtrace. Function inlining causes the inlined function to not have a stack frame; tail call optimization replaces one stack frame with another; frame pointer elimination will stop `backtrace' from interpreting the stack contents correctly. Specifically, note the last sentence: frame pointer elimination will stop `backtrace' from interpreting the stack contents correctly. Sincerely, Michael Witten
Please document `contrib/download_prerequisites'
It would probably be a good idea to mention: contrib/download_prerequisites on this page: http://gcc.gnu.org/install/prerequisites.html and probably on this page: http://gcc.gnu.org/install/download.html Sincerely, Michael Witten
Re: Please document `contrib/download_prerequisites'
On Thu, 30 May 2013 11:04:55 +0800, Chung-Ju Wu wrote: > 2013/5/30 Michael Witten : >> It would probably be a good idea to mention: >> >> contrib/download_prerequisites >> >> on this page: >> >> http://gcc.gnu.org/install/prerequisites.html >> >> and probably on this page: >> >> http://gcc.gnu.org/install/download.html >> >> Sincerely, >> Michael Witten > > Is this the page you are looking for?? > > http://gcc.gnu.org/wiki/InstallingGCC > > See 'Support libraries' section. I'm not looking for anything. That wiki information should be incorporated into what that wiki page calls `the official installation docs', and the rest of it should probably be thrown out as superfluous.
Re: clang and FSF's strategy
On Wed, Jan 22, 2014 at 2:33 PM, Jordi Gutiérrez Hermoso wrote: > The fact that these non-free tools are not based on gcc are a > testament to how proprietary software developers cannot plug into gcc, > and how clang is fostering non-free software. What does it matter whether clang fosters non-free software if clang *also* fosters free software? Indeed, non-free software inspires a lot of free software, anyway. Apparently, gcc isn't fostering much of anything, except for a desire to replace it with llvm/clang. Where there is the least friction, there is the most freedom.
Re: clang and FSF's strategy
On Thu, Jan 23, 2014 at 11:04 AM, Duncan Sands wrote: > the... list is for technical rather than political discussion That's just it; that's the whole point. The *political* aspects are dictating the *technical* aspects. So... like it or not, that makes this list exactly the right place to have this discussion.
Re: [bool wrapping] Request for warnings on implicit bool to int conversions
goto ;
}
D.1090 = 0;
return D.1090;
}
As you can see, the loop simply keeps assigning to `b' the value `1':
:
b = 1;
goto ;
As for decrementing a _Bool, according to C99.6.5.3.1
"Prefix increment and decrement operators":
The prefix -- operator is analogous to the prefix ++
operator, except that the value of the operand is
decremented.
So, the prefix `--' operator expression in the following:
#include
bool b = 0;
--b;
should assign to `b' the value of the following expression:
(bool)((int)b - (int)1)
(bool)((int)0 - (int)1)
(bool)-1
1
That is, the value of `b' can wrap on decrement, which is
corroborated when the following program:
#include
int main(void)
{
bool b = 0;
for (;;) --b;
}
is compiled with:
gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c
thereby yield the following GIMPLE representation:
main ()
{
int D.1090;
{
_Bool b;
b = 0;
:
b = !b;
goto ;
}
D.1090 = 0;
return D.1090;
}
As you can see, the loop simply keeps assigning to `b' the logical
negation of `b':
:
b = !b;
goto ;
Similar arguments can be made for `b+=1' and `b-=1' (even for C++);
however, the GIMPLE representation is sometimes not as optimized:
For `b+=1' (and similarly for `b-=1'), gcc produces the following
more general computation:
:
D.1090 = (int) b;
D.1091 = D.1090 + 1;
b = D.1091 != 0;
goto ;
Also, while g++ does the simple logical negation for `b-=1', it
instead forgos a simple assignment of `1' in favor of the following
bizarre gymnastics for `b+=1':
:
D.984 = (int) b;
b = D.984 != -1;
goto ;
Maybe there's room for a patch?
Anyway, I'm done with my mental pleasuring for the day.
Ta ta!
Michael Witten
Re: [bool wrapping] Request for warnings on implicit bool to int conversions
On Wed, Mar 28, 2012 at 20:30, mathog wrote: > Since b-- is equivalent to [assigning] !b, > and b++ is equivalent to [assigning] 1, if > that action is intended, there is no reason > to use either the increment or decrement > operators on a bool. However, it seems to me that toggling the value with the idiom: --b; is aesthetically preferable to the more elaborate: b = !b; In fact, I've seen at least one person make this complaint in freenode's ##c++ IRC channel. Given the potential usefulness of `--b' and the relative uselessness of `++b', it would seem more practical for the C++ standard to have deprecated (if not allowed) `--b' and instead forbidden `++b' (rather than the other way around).
Re: Request for warnings on implicit bool to int conversions
On Wed, Mar 28, 2012 at 20:30, David Mathog wrote: > ... > >> gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c > > > That's a trick worth knowing. Thanks! > Ran that on a test program and in every case but one there was an implicit > > (int) b > > on sections of code which I though should generate warnings. (Math ops on > bools, comparison operations of > bool with ints.) The one exception in that little program was: > > b=2; > > which came out as > > b=1; > > In that case the compiler must have performed an implicit > > 1 = (bool) 2 > > Also these forms all generated implicit int conversions > > if(b==1) > if(b==2) > if(b==0) > > whereas > > if(b) > > did not. > > So let's turn this around. If the compiler warned on all implicit > conversions of bool <-> int, > what program lines would it warn on that it shouldn't? It would warn on: > > if(b==1) > if(b==0) > > but I would argue that line is inappropriate for a bool type, and should be > written as: > > if(b) > > With two bool variables, this also did not generate an implicit conversion > (and so would not warn, > which is appropriate): > > if(b1 || b2) > > Whereas this less preferred form would have generated an implicit (int) [and > a well deserved warning] > > if(b1 + b2) Your suggestion is probably a good idea, but as with all good ideas, it will probably not get implemented because most people don't care. Therefore, I'd suggest writing a patch and submitting it; people will no doubt be a lot more receptive when you convey your thoughts in hard-nosed, precise code, ESPECIALLY because that means the work has already been done! Sincerely, Michael Witten
Re: [Progress] Tiny GCC: Pure, Unadulterated, Object Code
On 25 Jan 2008, at 6:11 PM, Michael Witten wrote: On 25 Jan 2008, at 8:16 AM, Michael Witten wrote: On 24 Jan 2008, at 7:20 AM, Brian Dessent wrote: Michael Witten wrote: Can I build gcc in this way? I've been trying for quite some time now to achieve such a stripped down gcc, but it would seem that the gcc build process insists on building these libraries, which I think is wholly unnecessary. You might be able to approximate this by "make all-gcc" and then "make install-gcc" (or just manually copying the xgcc to the destination.) I'm a little uncomfortable just taking the xgcc that's left over when the build fails. I apologize. For some reason, when I tried make all-gcc the build failed. Aha! Apparently the build DOES FAIL when building on Mac OS X 10.5 (darwin 9.1.0) for the PowerPC (there is no problem with the x86 version): cc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno- variadic-macros -Wold-style-definition -Wmissing-format-attribute- DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/ gcc/../include -I../../src/gcc/../libcpp/include -I. -I. -I../../ src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/ gcc/../libcpp/include ../../src/gcc/config/rs6000/host-darwin.c -o host-ppc-darwin.o ../../src/gcc/config/rs6000/host-darwin.c:38: warning: ‘struct sigaltstack’ declared inside parameter list ../../src/gcc/config/rs6000/host-darwin.c:38: warning: its scope is only this definition or declaration, which is probably not what you want ../../src/gcc/config/rs6000/host-darwin.c:38: error: conflicting types for ‘sigaltstack’ /usr/include/signal.h:89: error: previous declaration of ‘sigaltstack’ was here ../../src/gcc/config/rs6000/host-darwin.c: In function ‘segv_handler’: ../../src/gcc/config/rs6000/host-darwin.c:71: error: ‘struct __darwin_mcontext’ has no member named ‘ss’ ../../src/gcc/config/rs6000/host-darwin.c:120: error: ‘struct __darwin_mcontext’ has no member named ‘es’ ../../src/gcc/config/rs6000/host-darwin.c:120: error: ‘struct __darwin_mcontext’ has no member named ‘ss’ ../../src/gcc/config/rs6000/host-darwin.c: In function ‘darwin_rs6000_extra_signals’: ../../src/gcc/config/rs6000/host-darwin.c:134: warning: passing argument 1 of ‘sigaltstack’ from incompatible pointer type make[1]: *** [host-ppc-darwin.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [all-gcc] Error 2 It can be compiled thusly: MACOSX_DEPLOYMENT_TARGET=10.4 make all-gcc
