Re: Building GCC using C++
On Tue, Jan 15, 2013 at 11:36:53AM +0530, Uday P. Khedker wrote:
>
>
> Basile Starynkevitch wrote, On Tuesday 15 January 2013 11:34 AM:
> >My belief is that it is no more possible to configure a recent GCC straight
> >(non-cross) compiler without --enable-language=c++
> >(that is, if you ask only for --enable-languages=c either configure
> >should bark, or it should also implicitly add C++).
>
> I was able to build gcc-4.7.2 with --enable-languages=c only :-)
But does the build and installed binaries contain some g++ ? I guess they do!
In other words --enable-languages=c should silently imply
--enable-languages=c,c++
But I am not entirely sure.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Building GCC using C++
On Tue, Jan 15, 2013 at 6:46 AM, Uday P. Khedker wrote:
> I was trying to understand the exact meaning of a loose statement
> floating around ("gcc has moved to C++ from version 4.7 onwards).
>
> I reckon from http://gcc.gnu.org/wiki/gcc-in-cxx that now gcc is
> compiled using C++. However, the very first line of the description
> confused me. It says:
>
>> GCC has been building stages 2 and 3 in C++ mode for a while.
>
>
> My understanding was that stage 2 is built using the compiler created
> in stage 1 and stage 3 is built using the compiler created in stage 2.
> (Please see slide 17/53 in
> http://www.cse.iitb.ac.in/grc/gcc-workshop-12/downloads/slides/gccw12-config-build.pdf).
>
> Can someone tell me what is the meaning of building stage 2 in C++
> mode? If I restrict my languages (using --enable-languages) to C,
> how can stage 2 be built in C++ mode? Or is it that regardless of
> the choice given using --enable-languages option, internally C and
> C++ compiler are created anyway? The build logs do not seem to bear
> out the above statement.
The C++ compiler is created anyway since 4.7 and is used to build
stage2+. Starting with GCC 4.8 stage1 requires a C++ host compiler.
Richard.
> Thanks and regards,
>
> Uday.
> --
> --
> Dr. Uday Khedker
> Professor
> Department of Computer Science & Engg.
> IIT Bombay, Powai, Mumbai 400 076, India.
> Email : u...@cse.iitb.ac.in
> Homepage: http://www.cse.iitb.ac.in/~uday
> Phone :
> Office -91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct)
> Res. -91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct)
>
>
Re: Building GCC using C++
Richard Biener wrote: On Tue, Jan 15, 2013 at 6:46 AM, Uday P. Khedker wrote: GCC has been building stages 2 and 3 in C++ mode for a while. The C++ compiler is created anyway since 4.7 and is used to build stage2+. Starting with GCC 4.8 stage1 requires a C++ host compiler. In GCC 4.7 you can use --disable-build-poststage1-with-cxx to build Stage 2 and 3 also with C instead of C++. (I think in 4.6 it was the other way round: You could optionally build Stage 2/3 with C++. Which sometimes failed due to C-isms - despite -Wc++-compat. Similarly, due to the C++ default-build switch over in 4.7, some C++isms caused sometimes build failures in Stage 2/3 when using a C compiler. When found, either issue was fixed.) Since 4.8, some C++-only code is used. Thus, you already need a C++ compiler for Stage 1. Tobias
stabs/dwarf size comparison on CSiBE (Was: stabs support in binutils, gcc, and gdb)
Hello, In this stabs vs. dwarf discussion, so far it's more been about assumptions than numbers. So let's throw in some numbers! The following debug sizes are for CSiBE-v2.1.1 on mipsisa64-elf, with the LRA branch at r195108. All CSiBE test cases are packages written in C. Debug size is computed as the total size of all ".stabs*" or ".debug*" sections as computed by "size -A" (sysv style size output) on individual object files (so before linking) and summed up by awk (*). Tested debug formats are "none", "stabs", "dwarf2", and "dwarf4". Compiler options were "-Os" for all four tested debug formats. Debug info was output with "-gstabs", "-gdwarf-2", and "-gdwarf-4". And the results are: package stabs dwarf2 dwarf4 bzip2-1.0.2 372772 289386 279670 cg_compiler... 1355948 1381734 1314676 compiler152178 156644 148458 flex-2.5.31 665588 511856 488256 jikespg-1.3 944126 773358 749050 jpeg-6b 3285854 2186640 2110290 libmspack 602692 421792 407070 libpng-1.2.51064722 1017116 975098 linux-2.4.23... 536172304092124638353402 lwip-0.5.3... 576260 402830 381902 mpeg2dec-0.3.1 492918 336912 327072 mpgcut-1.1 46956 51854 49490 OpenTCP-1.0.4 873008 223646 212822 replaypc-0.4... 1009322 445296 424136 teem-1.6.0-src 133744367259308 6954802 ttt-0.10.1... 208516 113828 109776 unrarlib-0.4.0 91236 79396 75256 zlib-1.1.4 280272 201392 193506 TOTAL 790140345677423453554732 DEBUG/TEXT 16.49 11.85 11.18 (*) the test script actually takes the sum of sizes for all ".text*", ".stabs*", and ".debug*" sections, and the ".text*" size is subtracted to get the debug info sizes. Unless someone can shoot holes in this test approach, the results suggest that DWARF debug size is *smaller* than stabs, at least for mipsisa64. Ciao! Steven
Re: bug report: not-a-number not recognized when compiling for x86_64
On 01/14/2013 03:50 PM, Marc Glisse wrote: On Mon, 14 Jan 2013, Mischa Baars wrote: When running the example attached, you can see the compiler fails to recognize not-a-number's properly. Bug reports go to bugzilla. NaN doesn't compare equal to anything. x==x is actually the usual way to test if x is NaN. Oops, sorry :) I see, I will have a different example for you later... Regards, Mischa.
not-a-number's
This is what I was trying to point out: When disregarding the 'isnan()', the function is returning a '2' when one or both the arguments is a NaN. Do you suppose this is correct? If you ask me, it should exit on the first compare and thus return a not-a-number. Regards, Mischa. 2010100706 - series expansion - inverse tangent.tar.gz Description: GNU Zip compressed data
Re: not-a-number's
> When disregarding the 'isnan()', the function is returning a '2' when > one or both the arguments is a NaN. Do you suppose this is correct? > > If you ask me, it should exit on the first compare and thus return a > not-a-number. You cannot "exit" a comparison in C, one of the branches is always taken, which means that npx_dr11_inverse_tangent_series can never return -NAN. -- Eric Botcazou
Re: stabs/dwarf size comparison on CSiBE (Was: stabs support in binutils, gcc, and gdb)
On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote: > Unless someone can shoot holes in this test approach, While the sum of *.o files sizes may make sense in some cases I would find more useful to measure it only for the final executables and after they have been processed by dwz. Besides dwz also .debug_* sections relocations have large size and all these relocations get removed in the final executable. Thanks, Jan
Re: microblaze unroll loops optimization
On 01/11/2013 07:20 PM, Michael Eager wrote:
I still think it's a bit odd. Other targets use the comparison
operator (e.g., lt, ge, etc.). Microblaze should as well.
Microblaze can't use the raw comparison operator because of how
the results of the cmp{,u} instructions are defined, especially
placing the result of < in the *high* bit.
You could, however, use two CCmodes for the result of the compares:
(set (reg:CC r) (compare:CC (reg:SI x) (reg:SI y)))
=> cmp r, x, y
(set (reg:CCU r) (compare:CCU (reg:SI x) (reg:SI y)))
=> cmpu r, x, y
and then the branch insns consume CC and CCU mode inputs:
(set (pc)
(if_then_else
(match_operator 1 "mb_signed_cmp_op" // eq, lt, le
[(match_operand:CC 2 "register_operand" "r")
(const_int 0)]0
(label_ref (match_operand 0))
(pc)))
and similar for "mb_unsigned_cmp_op" (eq, ltu, leu) with CCUmode.
I believe you'll find that MODE_CC modes default to word size
already, so if you arrange for mov{cc,ccu} patterns, reload will
spill/reload these values as required and everything will Just Work.
r~
Re: stabs/dwarf size comparison on CSiBE (Was: stabs support in binutils, gcc, and gdb)
On Tue, Jan 15, 2013 at 6:53 PM, Jan Kratochvil wrote:
> On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote:
>> Unless someone can shoot holes in this test approach,
>
> While the sum of *.o files sizes may make sense in some cases I would find
> more useful to measure it only for the final executables and after they have
> been processed by dwz.
>
> Besides dwz also .debug_* sections relocations have large size and all these
> relocations get removed in the final executable.
I know, but that's not how CSiBE is set up. My numbers bias against
DWARF for the reasons you mention, and the size of the DWARF info
*still* is not nearly an order of magnitude greater than stabs info.
I've posted these numbers in part also to challenge others to show
some benchmarking. I'd like to hear from others how stabs and DWARF
debug sizes compare for $YOUR_FAVORITE_APPLICATION...
Here's some more numbers, this time for gzip-1.5 on
powerpc64-unknown-linux-gnu, compiled with RedHat GCC 4.6.3-2,
compiler options "-O2 -g...".
size of flags used
debug info for gzip build
202329 -O2 -gstabs
233109 -O2 -gdwarf-2
218257 -O2 -gdwarf-4
116035 -O2 -gdwarf-4 -fno-var-tracking
171211 -O2 -gdwarf-4 -fno-var-tracking-assignments
Size of debug info is the output of:
size -A gzip \
| egrep "\.debug|\.stab" \
| awk 'BEGIN{sum=0}{sum=sum+$2}END{print sum}'
i.e. on the final executable.
Again, DWARF is nowhere near an order of magnitude larger than stabs
info, as reported by the OP.
Note, I'm not using dwz because I don't think it's a fair comparison
against non-compressed stabs until dwz is made part of the default
tool chain.
Ciao!
Steven
Re: not-a-number's
On 01/15/2013 05:24 PM, Eric Botcazou wrote: When disregarding the 'isnan()', the function is returning a '2' when one or both the arguments is a NaN. Do you suppose this is correct? If you ask me, it should exit on the first compare and thus return a not-a-number. You cannot "exit" a comparison in C, one of the branches is always taken, which means that npx_dr11_inverse_tangent_series can never return -NAN. Well, I have an Intel manual here that states that any operation on a QNaN should return a QNaN, which means that also the compare should return a QNaN when one or both of the arguments is a QNaN.
Re: not-a-number's
On 01/15/2013 05:24 PM, Eric Botcazou wrote: When disregarding the 'isnan()', the function is returning a '2' when one or both the arguments is a NaN. Do you suppose this is correct? If you ask me, it should exit on the first compare and thus return a not-a-number. You cannot "exit" a comparison in C, one of the branches is always taken, which means that npx_dr11_inverse_tangent_series can never return -NAN. Furthermore, since 'fxam' will return a 'non-comparable' during the first compare, I suppose the function should then enter the first 'else' and return a '4'. Mischa.
Re: Stellaris Non-Word-Aligned Write to SRAM Erratum
On Fri, Jan 11, 2013 at 2:29 AM, Louis-Philippe Brais wrote: > Hi all, > > The latest errata for Texas Instruments' Cortex-M3 family, updated > last October [1], contains a disturbing new problem triggered by > non-word-aligned writes to SRAM. This is the kind of errata that is > effectively addressed with a compiler work-around. FWIW, it has > already been addressed by a popular commercial toolchain vendor [2]. I > was wondering if the GCC ARM maintainers were aware of this bug, and > if somebody implemented or was working on a compiler work-around for > this problem. I had a look at recent discussions and patches on the > GCC mailing lists, but could not find anything. I'm looking for > something along the lines of the -mfix-cortex-m3-ldrd fix, but for > that new alignment write erratum. > > [1] http://www.ti.com/lit/er/spmz642b/spmz642b.pdf > [2] > http://netstorage.iar.com/SuppDB/Public/UPDINFO/007040/arm/doc/infocenter/iccarm.ENU.html > > Thanks for your attention, > LP Brais I don't see any patch for this erratum. It should be a new option rather than -mfix-cortex-m3-ldrd. - Joey
Re: not-a-number's
> Well, I have an Intel manual here that states that any operation on a > QNaN should return a QNaN, which means that also the compare should > return a QNaN when one or both of the arguments is a QNaN. No, that isn't how comparisons work. The correct result is 2 according to the comparison rules of IEEE-754. I'd suggest reading page 8 of "Lecture Notes on the Status of IEEE 754" by Kahan: http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF -- Eric Botcazou
