headers
Joseph S. Myers | 1 Sep 2009 01:05

Re: --enable-languages=c --enable-build-with-cxx

On Mon, 31 Aug 2009, Ralf Wildenhues wrote:

> Currently, --enable-languages=c --enable-build-with-cxx fails because
> neither the C++ compiler nor libstdc++-v3 are built in Stage 1, but in
> Stage 2, CXX is set to .../prev-gcc/g++ and other variables are set
> accordingly.  Is this combination supposed to work?
> 
> If yes, is it supposed to only build the C++ compiler and associated
> library in Stage 1 but not in later stages?
> 
> If no (to the first question), then shouldn't configure fail early?

It seems to me to be a perfectly valid configuration for building a cross 
compiler or an non-bootstrapped native toolchain; it's only in the 
bootstrap case that it doesn't make sense.

--

-- 
Joseph S. Myers
joseph <at> codesourcery.com
Permalink | Reply | 3 comments |
headers
Richard Henderson | 1 Sep 2009 02:06
Picon
Favicon

Re: asm goto vs simulate_block

> My guess, witjout seeing the testcase.
> In ccp_initialize we have:
>
>       for (i = gsi_start_bb (bb); !gsi_end_p (i); gsi_next (&i))
>         {
>           gimple stmt = gsi_stmt (i);
>           bool is_varying = surely_varying_stmt_p (stmt);
>
>           if (is_varying)
>             {
>               tree def;
>               ssa_op_iter iter;
>
>               /* If the statement will not produce a constant, mark
>                  all its outputs VARYING.  */
>               FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter, SSA_OP_ALL_DEFS)
>                 set_value_varying (def);
>             }
>           prop_set_simulate_again (stmt, !is_varying);
>
> This code looks clearly broken if the statement is control altering
> (like your asm), since it will cause us to never simulate it and add
> the outgoing edges (since the outgoing edges are only added in
> simulate_stmt).

Your guess is absolutely correct.  We already correctly
handle this case in init_copy_prop, but do not in two
other places.

And I just ran into this with my exception rewrite too,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kaveh R. GHAZI | 1 Sep 2009 03:04
Picon
Favicon

Call for testers: MPC 0.7 prerelease tarball

Hello,

A prerelease tarball of the upcoming MPC 0.7 is available here:
http://www.multiprecision.org/mpc/download/mpc-0.7-dev.tar.gz

Please help test it for portability and bugs by downloading and compiling
it on systems you have access to.  I'd like a report to contain your
target triplet and the versions of your compiler, GMP and MPFR used when
building MPC.  Also please include your results from "make check".  You
can report your results here in this thread or on the MPC mailing list:
http://lists.gforge.inria.fr/mailman/listinfo/mpc-discuss

Note I encourage reports of all platforms on which GCC bootstraps, but I'm
especially interested in the GCC primary and secondary list from our
release criteria listed here: http://gcc.gnu.org/gcc-4.5/criteria.html

As previously discussed, MPC will become a mandatory library for building
GCC prior to the 4.5 release, so your help in ensuring a smooth transition
is greatly appreciated.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi
Permalink | Reply | 14 comments |
headers
Jean Christophe Beyler | 1 Sep 2009 04:20
Picon

Re: Bit fields

On Mon, Aug 31, 2009 at 5:27 PM, Richard Henderson<rth <at> redhat.com> wrote:
> On 08/31/2009 02:07 PM, Jean Christophe Beyler wrote:
>>
>> I am going to try this but shouldn't it be :
>>
>> (set (reg:QI new-scratch))
>>       (zero_extract:DI ...))
>
> No.

Ok, I think I understand why not:

>> (insn 9 8 10 3 struct4.c:24 (set (subreg:DI (reg:QI 76) 0)
>>         (zero_extract:DI (reg:DI 75)
>>             (const_int 1 [0x1])
>>             (const_int 0 [0x0]))) -1 (nil))

Is basically saying :

(set (reg:DI new-scratch)
        (zero_extract:DI (reg:DI 75)
            (const_int 1 [0x1])
            (const_int 0 [0x0]))) -1 (nil))

and then apply the subreg:

(set (reg:QI 76) (subreg:QI (reg:DI new-scratch)))

which is what you were saying. I was reading the subreg the other way around.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jakub Jelinek | 1 Sep 2009 12:37
Picon
Favicon

Trunk frozen for VTA merge

Subject says it all, I guess.

	Jakub
Permalink | Reply | 2 comments |
headers
Dave Korn | 1 Sep 2009 13:15

Re: Call for testers: MPC 0.7 prerelease tarball

Kaveh R. GHAZI wrote:
> Hello,
> 
> A prerelease tarball of the upcoming MPC 0.7 is available here:
> http://www.multiprecision.org/mpc/download/mpc-0.7-dev.tar.gz
> 
> Please help test it for portability and bugs by downloading and compiling
> it on systems you have access to.

  Fell at the first hurdle for me:

 gcc-4 -shared-libgcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D_FORTIFY_SOURCE=2 -p
edantic -Wall -Wextra -Werror -O2 -pipe -MT inp_str.lo -MD -MP -MF .deps/inp_str
.Tpo -c inp_str.c  -DDLL_EXPORT -DPIC -o .libs/inp_str.o
cc1: warnings being treated as errors
inp_str.c: In function 'extract_string':
inp_str.c:113:10: error: array subscript has type 'char'
inp_str.c:114:10: error: array subscript has type 'char'
inp_str.c:115:10: error: array subscript has type 'char'
inp_str.c:118:13: error: array subscript has type 'char'
inp_str.c:119:13: error: array subscript has type 'char'
inp_str.c:120:13: error: array subscript has type 'char'
make[2]: *** [inp_str.lo] Error 1
make[2]: *** Waiting for unfinished jobs....

>  I'd like a report to contain your
> target triplet and the versions of your compiler, GMP and MPFR used when
> building MPC.  

$ /gnu/gcc/gcc/config.guess
(Continue reading)

Permalink | Reply | 8 comments |
headers
Dave Korn | 1 Sep 2009 13:19

Re: Call for testers: MPC 0.7 prerelease tarball

Dave Korn wrote:

>   Fell at the first hurdle for me:
> 
>  gcc-4 -shared-libgcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D_FORTIFY_SOURCE=2 -p
> edantic -Wall -Wextra -Werror -O2 -pipe -MT inp_str.lo -MD -MP -MF .deps/inp_str
> .Tpo -c inp_str.c  -DDLL_EXPORT -DPIC -o .libs/inp_str.o
> cc1: warnings being treated as errors
> inp_str.c: In function 'extract_string':
> inp_str.c:113:10: error: array subscript has type 'char'
> inp_str.c:114:10: error: array subscript has type 'char'
> inp_str.c:115:10: error: array subscript has type 'char'
> inp_str.c:118:13: error: array subscript has type 'char'
> inp_str.c:119:13: error: array subscript has type 'char'
> inp_str.c:120:13: error: array subscript has type 'char'
> make[2]: *** [inp_str.lo] Error 1
> make[2]: *** Waiting for unfinished jobs....

  Attached allowed it to build, and seems to be what the function was already
doing for isspace earlier.  Test results will follow.

    cheers,
      DaveK
Attachment (inp_str_c_fix.diff): text/x-c, 952 bytes
Permalink | Reply | 7 comments |
headers
Dave Korn | 1 Sep 2009 13:38

Re: Call for testers: MPC 0.7 prerelease tarball

Dave Korn wrote:

>   Attached allowed it to build, 

  And with that patch:

> ===================
> All 45 tests passed
> ===================

    cheers,
      DaveK
Permalink | Reply | 6 comments |
headers
Gabriel Paubert | 1 Sep 2009 14:11
Picon

Re: Why no strings in error messages?

On Wed, Aug 26, 2009 at 03:02:44PM -0400, Bradley Lucier wrote:
> On Wed, 2009-08-26 at 20:38 +0200, Paolo Bonzini wrote:
> > 
> > > When I worked at AMD, I was starting to suspect that it may be more beneficial
> > > to re-enable the first schedule insns pass if you were compiling in 64-bit
> > > mode, since you have more registers available, and the new registers do not
> > > have hard wired uses, which in the past always meant a lot of spills (also, the
> > > default floating point unit is SSE instead of the x87 stack).  I never got
> > > around to testing this before AMD and I parted company.
> > 
> > Unfortunately, hardwired use of %ecx for shifts is still enough to kill 
> > -fschedule-insns on AMD64.
> 
> The AMD64 Architecture manual I found said that various combinations of
> the RSI, RDI, and RCX registers are used implicitly by ten instructions
> or prefixes, and RBX is used by XLAT, XLATB.  So it appears that there
> are 12 general-purpose registers available for allocation.

XLATB is essentially useless (well maybe had some uses back in 16 bit days, 
when only a few registers could be used for addressing) and never generated
by GCC. 

However %ebx is used for PIC addressing in 32 bit mode so it is not 
always free either (I don't know about PIE code).

In 64 bit mode, PIC/PIE use PC relative addressing, so this gives 
you actually 9 more free registers than in 32 bit mode.

However for some reason you glossed over the case of integer division
which always use %edx and %eax. This is true even when dividing by a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Godmar Back | 1 Sep 2009 16:08
Picon

question about -mpush-args -maccumulate-outgoing-args on gcc for x86

Hi,

I'm using gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) for a x86
target. The info page says:

`-mpush-args'
`-mno-push-args'
     Use PUSH operations to store outgoing parameters.  This method is
     shorter and usually equally fast as method using SUB/MOV
     operations and is enabled by default.  In some cases disabling it
     may improve performance because of improved scheduling and reduced
     dependencies.

`-maccumulate-outgoing-args'
     If enabled, the maximum amount of space required for outgoing
     arguments will be computed in the function prologue.  This is
     faster on most modern CPUs because of reduced dependencies,
     improved scheduling and reduced stack usage when preferred stack
     boundary is not equal to 2.  The drawback is a notable increase in
     code size.  This switch implies `-mno-push-args'.

This information is also found on
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html
----------------

Is this information up-to-date?

It appears to me that '-mno-push-args' is the enabled by default (*),
and not '-mpush-args'.  Moreover, since -maccumulate-outgoing-args
implies -mno-push-args, it appears that the only way to obtain
(Continue reading)

Permalink | Reply | 3 comments |

Gmane