RE: Basic block infrastructure after dbr pass
Hi Boris, The cfg is not updated during the dbr pass (you might have edges to non-existing blocks etc.). Furthermore, the BB rules do not apply after the dbr pass (you might have labels inside BBs and not only before the bb_note insn or jump-insns in the middle of the BB and not at BB_END). What you might want to do is reconstruct the cfg after the dbr pass: 1. Clear existing edges using clear_edges () 2. Split the BBs in case there's a label/jump insns in the middle of it (using split_block ()) 3. Reconstruct edges between bbs using make_edge () This would create a new cfg and bb structure. Hope this helps, Tomer -Original Message- From: Richard Guenther [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 19:47 To: Boris Boesler Cc: Jim Wilson; GCC Subject: Re: Basic block infrastructure after dbr pass On Tue, Mar 18, 2008 at 6:40 PM, Boris Boesler <[EMAIL PROTECTED]> wrote: > Am 18.03.2008 um 16:21 schrieb Jim Wilson: > > > Boris Boesler wrote: > >> The following code generators use FOR_EACH_BB[_REVERSE] in the > >> target machine dependent reorg pass: > >> - bfin > >> - frv > >> - ia64 > >> - mt > >> - s390 > > > > The very first thing that ia64_reorg does is > > compute_bb_for_insn (); > > For a few seconds I thought you saved my day. > > I'm not talking about BLOCK_FOR_INSN (insn) > > I haven't specified my problem properly? If I traverse basic blocks > via FOR_EACH_BB (used in compute_bb_for_insn, too) I get insns which > are not in the insn-stream for(insn = get_insns(), insn; insn = > NEXT_INSN(insn)) .. > > B1 ---> B2 --> B3 > /\ /\ /\ > / \/ \ / \ >vv vv vv > i1 -> i2i3 -> i4 i5 -> i6 > | ^ > +-+ > > How can I say this? In a first pass I dump each insn as a node in a > VCG-file, each node is identified by its memory address (I used the > UID, but insns appear multiple times if they were copied, but UID or > address makes no difference). In a second pass I dump each basic > block as a node with edges to the head insn and to the end insn of > the basic block, which should be emitted in the first pass. But > sometimes some of the basic blocks have edges to insns which do not > exits. > > Possible solutions (from OK to horrific): > 1) These insns are dead code. > 2) Bug in my output (but I checked it quite often) > 3) Bug in GCC You are probably mix-matching functions for use in cfg_layout mode vs. non-cfg_layout mode. Richard.
Re: [trunk] Addition to subreg section of rtl.text.
Thanks again to everyone who commented. In sumnmary:
- There was disagreement about whether subregs of hard registers
should be phased out. However, we still have some code to handle
them, and they are still used today (at least by SPE).
- A MODE_PARTIAL_INT mode behaves like the corresponding MODE_INT mode.
Does the updated documentation below look OK?
Richard
@findex subreg
@item (subreg:@var{m1} @var{reg:m2} @var{bytenum})
@code{subreg} expressions are used to refer to a register in a machine
mode other than its natural one, or to refer to one register of
a multi-part @code{reg} that actually refers to several registers.
Each pseudo register has a natural mode. If it is necessary to
operate on it in a different mode, the pseudo register must be
enclosed in a @code{subreg}. It is seldom necessary to wrap
hard registers in @code{subreg}s; such registers would normally
reduce to a single @code{reg} rtx.
@code{subreg}s come in two distinct flavors, each having its own
usage and rules:
@table @asis
@item Paradoxical subregs
When @var{m1} is strictly wider than @var{m2}, the @code{subreg}
expression is called @dfn{paradoxical}. The canonical test for this
class of @code{subreg} is:
@smallexample
GET_MODE_SIZE (@var{m1}) > GET_MODE_SIZE (@var{m2})
@end smallexample
Paradoxical @code{subreg}s can be used as both lvalues and rvalues.
When used as an rvalue, the low-order bits of the @code{subreg} are
taken from @var{reg} while the high-order bits are left undefined.
When used as an lvalue, the low-order bits of the source value are
stored in @var{reg} and the high-order bits are discarded.
@var{bytenum} is always zero for a paradoxical @code{subreg}, even on
big-endian targets.
For example, the paradoxical @code{subreg}:
@smallexample
(set (subreg:SI (reg:HI @var{x}) 0) @var{y})
@end smallexample
stores the lower 2 bytes of @var{y} in @var{x} and discards the upper
2 bytes. A subsequent:
@smallexample
(set @var{z} (subreg:SI (reg:HI @var{x}) 0))
@end smallexample
would set the lower two bytes of @var{z} to @var{y} and set the upper two
bytes to an unknown value.
@item Normal subregs
When @var{m1} is at least as narrow as @var{m2} the @code{subreg}
expression is called @dfn{normal}.
Normal @code{subreg}s restrict consideration to certain bits of @var{reg}.
There are two cases. If @var{m1} is smaller than a word, the
@code{subreg} refers to the least-significant part (or @dfn{lowpart})
of one word of @var{reg}. If @var{m1} is word-sized or greater, the
@code{subreg} refers to one or more complete words.
When used as an lvalue, @code{subreg} is a word-based accessor.
Storing to a @code{subreg} modifies all the words of @var{reg} that
overlap the @code{subreg}, but it leaves the other words of @var{reg}
alone.
When storing to a normal @code{subreg} that is smaller than a word,
the other bits of the referenced word are usually left in an undefined
state. This laxity makes it easier to generate efficient code for
such instructions. To represent an instruction that preserves all the
bits outside of those in the @code{subreg}, use @code{strict_low_part}
or @code{zero_extract} around the @code{subreg}.
@var{bytenum} must identify the offset of the first byte of the
@code{subreg} from the start of @var{reg}, assuming that @var{reg} is
laid out in memory order. The memory order of bytes is defined by
two target macros, @code{WORDS_BIG_ENDIAN} and @code{BYTES_BIG_ENDIAN}:
@itemize
@item
@cindex @code{WORDS_BIG_ENDIAN}, effect on @code{subreg}
@code{WORDS_BIG_ENDIAN}, if set to 1, says that byte number zero is
part of the most significant word; otherwise, it is part of the least
significant word.
@item
@cindex @code{BYTES_BIG_ENDIAN}, effect on @code{subreg}
@code{BYTES_BIG_ENDIAN}, if set to 1, says that byte number zero is
the most significant byte within a word; otherwise, it is the least
significant byte within a word.
@end itemize
@cindex @code{FLOAT_WORDS_BIG_ENDIAN}, (lack of) effect on @code{subreg}
On a few targets, @code{FLOAT_WORDS_BIG_ENDIAN} disagrees with
@code{WORDS_BIG_ENDIAN}. However, most parts of the compiler treat
floating point values as if they had the same endianness as integer
values. This works because they handle them solely as a collection of
integer values, with no particular numerical value. Only real.c and
the runtime libraries care about @code{FLOAT_WORDS_BIG_ENDIAN}.
Thus,
@smallexample
(subreg:HI (reg:SI @var{x}) 2)
@end smallexample
on a @code{BYTES_BIG_ENDIAN}, @samp{UNITS_PER_WORD == 4} target is the same as
@smallexample
(subreg:HI (reg:SI @var{x}) 0)
@end smallexample
on a little-endian, @samp{UNITS_PER_WORD == 4} target. Both
@code{subreg}s access the lower two bytes of register @var{x}.
@end table
A @code{MODE_PARTIAL_INT} mode behaves as if it were as wide as the
corresponding @code{MODE_INT} mode, except that it has an unknown
number of undefined bits. For example:
@smallexample
(subreg:PSI (reg:SI 0) 0)
@end smallexamp
Re: [trunk] Addition to subreg section of rtl.text.
Richard Sandiford <[EMAIL PROTECTED]> writes: > - A MODE_PARTIAL_INT mode behaves like the corresponding MODE_INT mode. ...except that (as the docs said) an unknown number of bits read as undefined. Richard
Re: [trunk] Addition to subreg section of rtl.text.
Richard Sandiford wrote: Richard Sandiford <[EMAIL PROTECTED]> writes: - A MODE_PARTIAL_INT mode behaves like the corresponding MODE_INT mode. ...except that (as the docs said) an unknown number of bits read as undefined. Richard I would add two things to the section. One is to recommend in the text that subregs of hard regs not be used if possible. The advantages that these provide are marginal and there is a reasonable chance that they will be outlawed in the future. The second is to say explicitly that subregs of subregs are not legal. I know that the df code will ignore the "middle" subreg. Kenny
Re: How to understand gcc source code?
On Sun, Mar 23, 2008 at 3:04 PM, Abhijat Vichare <[EMAIL PROTECTED]> wrote: > On Sat, 2008-03-22 at 16:59 +0800, =?GB2312?B?wbqI0g==?= wrote: > > > But still, I cannot manage the source code of gcc. > > I don't know how to start reading it. > > You can try: http://www.cfdvs.iitb.ac.in/~amv/gcc-int-docs/#gccdocs This link is amazing! Who maintains it?
Re: [trunk] Addition to subreg section of rtl.text.
The second is to say explicitly that subregs of subregs are not legal. Yes, you should always use (directly or indirectly) simplify_gen_subreg. Paolo
Re: How to understand gcc source code?
NightStrike wrote: On Sun, Mar 23, 2008 at 3:04 PM, Abhijat Vichare <[EMAIL PROTECTED]> wrote: On Sat, 2008-03-22 at 16:59 +0800, =?GB2312?B?wbqI0g==?= wrote: > But still, I cannot manage the source code of gcc. > I don't know how to start reading it. You can try: http://www.cfdvs.iitb.ac.in/~amv/gcc-int-docs/#gccdocs This link is amazing! Who maintains it? Did you try looking at the bottom of the referenced page? It would appear that the information you desire is there. David Daney
Re: http://gcc.gnu.org/onlinedocs/libstdc++/ needs a bit of help
Thanks Paolo for fixing up the links as requested by Gerald. > Working on the link consistency of the http://gcc.gnu.org, I ran into > a couple of links on the libstdc++ side that are in need of a bit > love. It would be great could one of you libstdc++ guys look into > those. All the links your reference later in your email are actually dead links, from the documentation pre-Docbook. IMHO they should not be part of the libstdc++ online docs at all, but I don't know how to remove them. The current libstdc++ html docs are in the sources here: gcc/libstdc++-v3/doc/html I don't know what should be done about the gcc online web pages. You can either remove the dead links, and just use the generated html pages, or try to come up with some mapping between the old links and the new layout. best, benjamin
GSoC - Multithreaded linker
Hi all, I'm interested in applying for Google Summer of Code and wanted to work in some project in the area of parallel/multi-core programming. Looking through the GCC GSoC Wiki page I found a subject that sounds really interesting to me in the "Speed Up" section: Multithreaded linker. Could anyone give me more information about this: a) what is the idea (to parallel the current linker or build one from scratch) b) how complicated it is c) what are the requirements I just completed my undergraduate course in Computer Science and had just started a graduate course, so I have some background in compilers and also parallel programing. Thanks, Daniel
Re: GSoC - Multithreaded linker
On Mon, Mar 24, 2008 at 12:18:47PM -0300, [EMAIL PROTECTED] wrote: > I'm interested in applying for Google Summer of Code and wanted to work in > some project in the area of parallel/multi-core programming. Looking > through the GCC GSoC Wiki page I found a subject that sounds really > interesting to me in the "Speed Up" section: Multithreaded linker. The linker has long been a bottleneck, but Ian Taylor has contributed a new ELF-only linker, "gold", which is more than five times faster than GNU ld (though for now it only works on x86 and x86-64). It reduces the CPU requirement so much that the task is pretty much completely I/O dominated, so the opportunity for speedup by multi-threading is greatly reduced. See http://sourceware.org/ml/binutils/2008-03/msg00162.html (and thanks, Ian!) The item you saw is in the "pie in the sky" category, meaning ideas that are taken less seriously. Also, the linker is part of GNU binutils, not GCC, so a project to speed up the linker wouldn't qualify as a GCC SoC project AFAIK. But anyone who wants to go over to binutils and help get gold running on more platforms would have my personal respect and thanks.
Regenerating configure scripts
I'm trying to include a fix for the recurring GCC_NO_EXECUTABLES problem. Refs: http://gcc.gnu.org/ml/gcc/2007-11/msg00790.html http://gcc.gnu.org/ml/gcc/2008-03/msg00515.html I get no errors when I run 'aclocal' but I do get two error messages when I run autoconf: $ autoconf configure.ac:177: error: possibly undefined macro: AC_LC_MESSAGES If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:185: error: possibly undefined macro: AC_DEFINE /usr/share/aclocal contains lcmessage.m4. Any suggestions? (BTW I'm running aclocal v. 1.10, autoconf v. 2.61) -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Regenerating configure scripts
On Mon, Mar 24, 2008 at 7:04 PM, Michael Eager <[EMAIL PROTECTED]> wrote: > I'm trying to include a fix for the recurring GCC_NO_EXECUTABLES problem. > Refs: > http://gcc.gnu.org/ml/gcc/2007-11/msg00790.html > http://gcc.gnu.org/ml/gcc/2008-03/msg00515.html > > I get no errors when I run 'aclocal' but I do get two > error messages when I run autoconf: > > $ autoconf > configure.ac:177: error: possibly undefined macro: AC_LC_MESSAGES >If this token and others are legitimate, please use m4_pattern_allow. >See the Autoconf documentation. > configure.ac:185: error: possibly undefined macro: AC_DEFINE > > /usr/share/aclocal contains lcmessage.m4. > > Any suggestions? (BTW I'm running aclocal v. 1.10, autoconf v. 2.61) You should use aclocal 1.9.6 and autoconf 2.59 instead. Richard.
Re: Regenerating configure scripts
Hello Michael, * Michael Eager wrote on Mon, Mar 24, 2008 at 07:04:40PM CET: > I'm trying to include a fix for the recurring GCC_NO_EXECUTABLES problem. > Refs: > http://gcc.gnu.org/ml/gcc/2007-11/msg00790.html > http://gcc.gnu.org/ml/gcc/2008-03/msg00515.html FWIW, I was going to post a couple of patches for that eventually, but I don't mind if you beat me to it. > I get no errors when I run 'aclocal' but I do get two > error messages when I run autoconf: > > $ autoconf > configure.ac:177: error: possibly undefined macro: AC_LC_MESSAGES > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure.ac:185: error: possibly undefined macro: AC_DEFINE In which directory? It looks like you forgot some -I options to aclocal. See ACLOCAL_AMFLAGS in the Makefile.am in the directory where the respective configure.ac lives. > /usr/share/aclocal contains lcmessage.m4. > > Any suggestions? (BTW I'm running aclocal v. 1.10, autoconf v. 2.61) You should have automake 1.9.6 and autoconf 2.59 in $PATH, for GCC, not current versions. Cheers, Ralf
GCC : how to add VFPU to PSP Allegrex (MIPS target) ?
Hello,
As i don't really know where to send this email, I thought you may help
to redirect it to the right place.
I have some questions about vectorization which I would like to have for
a special MIPS architecture : Allegrex w/ VFPU.
First, an explanation about what allegrex is :
Allegrex is based on MIPS II with some MIPS III additions and has a
standard FPU. It has no 64-bit ISA for both CPU and FPU (so long
long and double need to be done though a software method).
There is also some instructions usually found in OPCODE3 map to be
in OPCODE2 map for Allegrex (min, max, madd(u), msub(u), etc.).
Allegrex also has a coprocessor 2 we called VFPU. This coprocessor is
quite powerful and easy to use and can even be used as a replacement for
FPU :
Details about VFPU :
It has 128 32-bit single precision floating point registers, which
are organized in 8 banks of 4x4 matrixes :
$0
$1
$2
$3
$32
$33
$34
$35
$64
$65
$66
$67
$96
$97
$98
$99
$4
$5
$6
$7
$36
$37
$38
$39
$68
$69
$70
$71
$100
$101
$102
$103
$8
$9
$10
$11
$40
$41
$42
$43
$72
$73
$74
$75
$104
$105
$106
$107
$12
$13
$14
$15
$44
$45
$46
$47
$76
$77
$78
$79
$108
$109
$110
$111
$16
$17
$18
$19
$48
$49
$50
$51
$80
$81
$82
$83
$112
$113
$114
$115
$20
$21
$22
$23
$52
$53
$54
$55
$84
$85
$86
$87
$116
$117
$118
$119
$24
$25
$26
$27
$56
$57
$58
$59
$88
$89
$90
$91
$120
$121
$122
$123
$28
$29
$30
$31
$60
$61
$62
$63
$92
$93
$94
$95
$124
$125
$126
$127
$0..$127 : 32-bit scalar floats.
those registers can be accessed in scalar format, in row or column
vector format, in matrix or transposed format.
when accessing as a row or a column, we can deal with 2, 3 or 4
components as long as the numbers of those registers are inside the
bank.
when accessing as a matrix, we can deal with 2, 3 or 4 rows or
columns as long as theirs numbers are inside the bank.
Basically, operations on VFPU may look this way :
vadd.s S000, S010, S020 : $0 = $1 + $2
vadd.t R000, R001, C030 : {$0, $1, $2} = {$32, $33, $34} + {$3, $35,
$67} <=> par { $0 = $32 + $3; $1 = $33 + $35; $2 = $34 + $67; }
vtfm.p R200, M000, C010 : {$8, $9} = {{$0, $1}, {$32, $33}} x {$4,
$36} <=> par { $8 = $0 * $4 + $1 * $36; $9 = $32 * $4 + $33 * $36 }
etc.
The questions now :
I would like to extend the use of VFPU in psp-gcc, the free PSP port of
gcc through the vectorization
* How can I make coexist the SF mode between the FPU registers and
the VFPU registers in the argument list of a function ? there is
no direct tranfer between them, you need to use a GPR register or
a memory slot as an intermediate to do so, which is very slow. I
would like to be able to distinguish them through an attribute. Is
there any examples which address this problem ?
* Another way to distinguish a VFPU scalar is to use "typedef float
__attribute__((vector_size(4))) V1SF;". Is that difficult to make
it possible (right now, gcc refuses it) ?
* Same question for V3SF, is that difficult to make it possible ?
* V2SF and V4SF are possible (they are respectively row vector of
two or four components). If I choose to let gcc allocate only the
first 32 VFPU registers, the other being associated with one of
first 32 registers, would it be difficult to have combined V2V1SF,
V3V1SF, V4V1SF to define column vectors of two, three or four
components ? and to have V2V2SF, V3V3SF, V4V4SF as matrixes ?
Right now, a vector needs a binary multiple of components. It doesn't
allow autovectorization for 3D.
V4SF means allocation of 4 contigous registers amongst the first 32
registers : { i, i+1, i+2, i+3} with 0 <= i < 32 and i%4 = 0. Its size
is 4*sizeof(float). For VFPU, it would describe a typical 4D row vector.
V4V1SF means allocation of 1 register amongst the first 32 registers : {
i, i+32, i+64, i+96 } with 0 <= i < 32. But its size is 4*sizeof(float).
For VFPU, it would describe a typical 4D column vector.
V2V2SF means allocation of 2 contigous registers amongst
Re: Regenerating configure scripts
Ralf Wildenhues wrote: $ autoconf configure.ac:177: error: possibly undefined macro: AC_LC_MESSAGES If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:185: error: possibly undefined macro: AC_DEFINE In which directory? It looks like you forgot some -I options to aclocal. See ACLOCAL_AMFLAGS in the Makefile.am in the directory where the respective configure.ac lives. /usr/share/aclocal contains lcmessage.m4. Any suggestions? (BTW I'm running aclocal v. 1.10, autoconf v. 2.61) You should have automake 1.9.6 and autoconf 2.59 in $PATH, for GCC, not current versions. I back-reved automake and autoconf to these versions by installing the corresponding rpms. I'm trying to update configure in gcc/libstdc++-v3. When I run with the options from Makefile.in, I get a bunch of messages: $ aclocal -I . -I .. -I ../config configure.ac:175: error: m4_require: circular dependency of AC_LANG_COMPILER(C++) configure.ac:175: AC_LANG_COMPILER(C++) is required by... autoconf/lang.m4:295: AC_LANG_COMPILER_REQUIRE is expanded from... autoconf/general.m4:2215: AC_LINK_IFELSE is expanded from... ../libtool.m4:886: _LT_SYS_MODULE_PATH_AIX is expanded from... ../libtool.m4:5191: _LT_LANG_CXX_CONFIG is expanded from... ../libtool.m4:773: _LT_LANG is expanded from... ../libtool.m4:756: LT_LANG is expanded from... configure.ac:175: AC_PROG_CXX is required by... autoconf/c.m4:653: AC_LANG_COMPILER(C++) is expanded from... configure.ac:175: AC_LANG_COMPILER(C++) is required by... autoconf/lang.m4:295: AC_LANG_COMPILER_REQUIRE is expanded from... autoconf/general.m4:2215: AC_LINK_IFELSE is expanded from... autoconf/general.m4:2223: AC_TRY_LINK is expanded from... autoconf/general.m4:1799: AC_CACHE_VAL is expanded from... ../config/unwind_ipinfo.m4:4: GCC_CHECK_UNWIND_GETIPINFO is expanded from... configure.ac:175: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: autom4te failed with exit status: 1 RPM says that autoconf-2.61-9 is not installed, but rpm -qf /usr/share/autoconf/autoconf/lang.m4 says that is provided by both autoconf-2.61-9 and autoconf-2.59-12. So I really don't know whether 2.61 has been replaced by 2.59 or not. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Regenerating configure scripts
Michael Eager wrote: I'm trying to update configure in gcc/libstdc++-v3. Provided you have the correct versions of autoconf and automake, as indicated, just running autoreconf certainly works. Paolo.
Re: Regenerating configure scripts
Paolo Carlini wrote: Michael Eager wrote: I'm trying to update configure in gcc/libstdc++-v3. Provided you have the correct versions of autoconf and automake, as indicated, just running autoreconf certainly works. Not for me. :-( Autoreconf gives the same errors from aclocal. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] linux/fs.h - Convert debug functions declared inline __attribute__((format (printf,x,y) to statement expression macros
On Sun, 2008-03-23 at 16:22 +0100, Denys Vlasenko wrote: > On Friday 29 February 2008 02:09, Joe Perches wrote: > > But the function place_entity doesn't use it directly or indirectly. > > If the lines above are removed, the generated code for place_entity changes. > I see it all the time. Whenever I add/remove/change something > to a header, some functions grow a tiny bit, some shrink a bit. > gcc 4.2.1. Report is here: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950 This seems more like a machine descriptions or target pass defect than an RTL problem. Should this defect be classified in group "Target" rather than "RTL"?
Re: Regenerating configure scripts
I have built autoconf259-2.59-12.0.fc7.noarch.rpm and automake19-1.9.6-2.1.0.fc7.noarch.rpm for Fedora 7/8 so that I can run autoconf/automake for gcc and binutils. H.J. On Mon, Mar 24, 2008 at 12:53 PM, Michael Eager <[EMAIL PROTECTED]> wrote: > > Paolo Carlini wrote: > > Michael Eager wrote: > >> I'm trying to update configure in gcc/libstdc++-v3. > > Provided you have the correct versions of autoconf and automake, as > > indicated, just running autoreconf certainly works. > > Not for me. :-( > > Autoreconf gives the same errors from aclocal. > > > > > -- > Michael Eager[EMAIL PROTECTED] > 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 >
Re: Regenerating configure scripts
* Michael Eager wrote on Mon, Mar 24, 2008 at 08:53:22PM CET: > Paolo Carlini wrote: >> Michael Eager wrote: >>> I'm trying to update configure in gcc/libstdc++-v3. >> Provided you have the correct versions of autoconf and automake, as >> indicated, just running autoreconf certainly works. > > Not for me. :-( > > Autoreconf gives the same errors from aclocal. Since you had problems using RPMs for the older tools, I suggest you download and install vanilla autotools into a different --prefix; get them from ftp.gnu.org/gnu/autoconf and /automake. To avoid yourself hassles, use the same prefix for both of them. Cheers, Ralf
gcc-4.1-20080324 is now available
Snapshot gcc-4.1-20080324 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080324/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 133491 You'll find: gcc-4.1-20080324.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080324.tar.bz2 C front end and core compiler gcc-ada-4.1-20080324.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080324.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080324.tar.bz2 C++ front end and runtime gcc-java-4.1-20080324.tar.bz2 Java front end and runtime gcc-objc-4.1-20080324.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080324.tar.bz2The GCC testsuite Diffs from 4.1-20080317 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Regenerating configure scripts
Ralf Wildenhues wrote:
* Michael Eager wrote on Mon, Mar 24, 2008 at 08:53:22PM CET:
Paolo Carlini wrote:
Michael Eager wrote:
I'm trying to update configure in gcc/libstdc++-v3.
Provided you have the correct versions of autoconf and automake, as
indicated, just running autoreconf certainly works.
Not for me. :-(
Autoreconf gives the same errors from aclocal.
Since you had problems using RPMs for the older tools, I suggest you
download and install vanilla autotools into a different --prefix;
get them from ftp.gnu.org/gnu/autoconf and /automake. To avoid yourself
hassles, use the same prefix for both of them.
After building/installing autoconf-2.59 and automake-1.6.9 into
version-specific directories, I'm able to regenerate the configure
scripts. Thanks all for the help.
I've noticed a problem with the patch:
if test "${with_newlib+set}" = set; then
AC_LIBTOOL_DLOPEN
fi
The test always succeeds. When $with_newlib is "yes",
${with_newlib+set} is "set".
If I change this to the old style test
if test "x$with_newlib" = x; then
AC_LIBTOOL_DLOPEN
fi
then it works as expected.
This is weird. I see the former idiom everywhere in configure.
The tests can't all be failing.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Regenerating configure scripts
Michael Eager wrote:
> I've noticed a problem with the patch:
> if test "${with_newlib+set}" = set; then
> AC_LIBTOOL_DLOPEN
> fi
>
> The test always succeeds. When $with_newlib is "yes",
> ${with_newlib+set} is "set".
>
> If I change this to the old style test
> if test "x$with_newlib" = x; then
> AC_LIBTOOL_DLOPEN
> fi
> then it works as expected.
In the message you gave a url to at the start of this thread I see:
if test "x${with_newlib}" != "xyes"; then
AC_LIBTOOL_DLOPEN
fi
Which would seem to be correct.
If you are unsure of what ${var+set} does, see
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
Peter
--
Peter O'Gorman
http://pogma.com
Re: Regenerating configure scripts
Michael Eager wrote:
> I've noticed a problem with the patch:
>if test "${with_newlib+set}" = set; then
> AC_LIBTOOL_DLOPEN
>fi
>
> The test always succeeds. When $with_newlib is "yes",
> ${with_newlib+set} is "set".
>
> If I change this to the old style test
>if test "x$with_newlib" = x; then
> AC_LIBTOOL_DLOPEN
>fi
> then it works as expected.
>
> This is weird. I see the former idiom everywhere in configure.
> The tests can't all be failing.
I think both are wrong. You should be testing whether it equals the
value "yes", not whether or not the variable is set, because
$with_newlib can equally be blank or set to "no" in a non-newlib case.
Brian
Re: Regenerating configure scripts
Brian Dessent wrote:
Michael Eager wrote:
I've noticed a problem with the patch:
if test "${with_newlib+set}" = set; then
AC_LIBTOOL_DLOPEN
fi
The test always succeeds. When $with_newlib is "yes",
${with_newlib+set} is "set".
If I change this to the old style test
if test "x$with_newlib" = x; then
AC_LIBTOOL_DLOPEN
fi
then it works as expected.
This is weird. I see the former idiom everywhere in configure.
The tests can't all be failing.
I think both are wrong. You should be testing whether it equals the
value "yes", not whether or not the variable is set, because
$with_newlib can equally be blank or set to "no" in a non-newlib case.
That's a good point and an easy change.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Regenerating configure scripts
Peter O'Gorman wrote:
Michael Eager wrote:
I've noticed a problem with the patch:
if test "${with_newlib+set}" = set; then
AC_LIBTOOL_DLOPEN
fi
The test always succeeds. When $with_newlib is "yes",
${with_newlib+set} is "set".
If I change this to the old style test
if test "x$with_newlib" = x; then
AC_LIBTOOL_DLOPEN
fi
then it works as expected.
In the message you gave a url to at the start of this thread I see:
if test "x${with_newlib}" != "xyes"; then
AC_LIBTOOL_DLOPEN
fi
Which would seem to be correct.
If you are unsure of what ${var+set} does, see
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
You're right. I copy/pasted from the wrong place.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: How should _Decimal64 and _Decimal128 be aligned on stack?
On Sun, Mar 23, 2008 at 8:09 AM, H.J. Lu <[EMAIL PROTECTED]> wrote: > > On Sun, Mar 23, 2008 at 11:41:00PM +1100, Ben Elliston wrote: > > > DFP is beyond i386 psABI. Gcc aligns _Decimal32 to 4 byte, _Decimal64 to > 8 bytes > > > and _Decimal128 to 16bytes. The question is what is the best alignment > for them > > > when passing to a functions. > > > > The original work I did for the x86-64 backend placed them at that > > alignment because that is the required alignment for loading those > > values into SSE registers. Right? > > That is a good question. For x86, _Decimal128 is passed on stack > and aligned at 4 byte. For x86-64, _Decimal128 is passed in SSE > registers. An implementation of _Decimal128 in 32bit may want > to use SSE registers. > I think we should align _Decimal64 and _Decimal128 to their natural alignments when passing a function. The same should apply to x86-64 when they are passed on stack. H.J.
Un-deprecating CRX: Request to review and commit
Hello All, Refer: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00306.html I had submitted a patch to undeprecate CRX port in 4.3 branch. The port itself has not changed. I have also submitted the tests results. So far I have not recevied any comments for GCC community. Can someone please review the patch and suggest if this is OK for 4.3 branch? I will submit another patch for TRUNK as well. Thanks, Pompa
