Re: Configure test hangs on powerpc64-linux
On Sat, Nov 25, 2006 at 09:36:00PM -0500, Daniel Jacobowitz wrote: > It never returns from ppc64_elf_gc_mark_hook (spins looking things up > in a hash table, I don't have the matching source handy). I expect > this is fixed in later binutils 2006-01-17 > Is there some way we can avoid an infinite loop in configure for this > case? Not without making _start look like a proper ppc64 function descriptor, ie. defined in .opd. But then the test would pass, and you want it to fail on 2.16.1 otherwise you'll get the hang later when building libstdc++. Ideally configure ought to be able to test for a hang in ld. If that's too hard, then I suppose you could fail this test for powerpc64 based on ld version. -- Alan Modra IBM OzLabs - Linux Technology Centre
Some clarifications regarding GIMPLE and LTO
Hi there i'm looking for a way to emit (dump) complete global and local symbol table entries for any given (C) program. For now, it would be satisfactory if this was properly handled for single-source-file programs. But what i would like to do basically is to store the entire information that would be needed in order to "interpret" a GIMPLE dump. A HLL (high-level language) program would probably map into something like this by any compiler: record Program is record GlobalSymbolTable is // global symbol entries end record; list FunctionList is // a linked list of Function records as defined below end list; end record; record Function is record LocalSymbolTable is // local symbol entries end record; record StatementList is // list of low-GIMPLE-level statements end record; end record; What I can see now is that GlobalSymbolTable is not dumped at all and LocalSymbolTable entries are not dumped to full extent (e.g. no initializations). For example, struct cgraph_varpool_node does not carry all the required information, for global variables and maybe it wasn't designed for that either. Does the LTO branch try to achieve that the complete information for a "Program" can be sufficiently stored (in a file)? If this is already there, could anyone provide some pointers to the API? Thank you in advance. Kind regards Nikolaos Kavvadias
Re: MPFR 2.2.1 Release Candidate (sparc-sun-solaris2.10)
On Wed, 22 Nov 2006, Vincent Lefevre wrote: > Hi, > > I'm posting this announce to this list as GCC now uses MPFR... > > The release of MPFR 2.2.1 is imminent. Please help to make this > release as good as possible by downloading and testing this > release candidate: > > Changes from version 2.2.0 to version 2.2.1: > - Many bug fixes. > - Updated mpfr-longlong.h from the GMP 4.2 longlong.h file. > - Moved some internal declarations from mpfr.h to mpfr-impl.h. > - Use -search_paths_first on Darwin (Mac OS X) to fix linking behavior. > - Improved MPFR manual. > > Please send success and failure reports to <[EMAIL PROTECTED]>. I had success with mpfr-2.2.1-rc1 on sparc-sun-solaris2.10. I used gmp-4.2.1 compiled with gcc-3.4.6 and configured mpfr using the flags --disble-shared --with-gmp-build=/blah/blah/... I was also able to pass my various tests using this mpfr hooked up to gcc mainline to evaluate transcendentals at compile-time. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
what about a compiler probe?
Dear All,
I am considering implementing the following feature into GCC using the
patch on http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01769.html : a
compiler probe which permits to probe the run of a compilation,
e.g. by displaying in emacs or a graphical GTK application the current
pass, Gimple representations, etc... which effectivly probes inside
the compiler; this could be useful for long-lasting compilations (in
particular those considered in the globalGCC project
http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html which will probably
"compile" tens time slower than current gcc) of more than several
minutes, or for GCC hackers which want to debug or understand its
internal by experimenting it. For example, it could be useful to know
the currently compiled function, or the current Gimple trees for it,
etc... In general do you feel that such a feature could be useful? (it
somehow generalize Sebastian Pop's gcc/tree-browser.c)
I propose a --enable-compiler-probe flag to configure which by default
is disabled. When GCC is configured with --enable-compiler-probe
(which is only possible on some Posix or Unix hosts like linux & BSD &
Solaris), the resulting compiler
accepts a -fcompiler-probe flag; in the usual case where this flag
is not passed, the compiler does not behave differently than usual,
except probably a minor performance hit (which won't happen when
configured with --disable-compiler-probe).
when given the -fcompiler-probe flag, it should get an a string
option with it. If this string is a (Unix) file path it indicate a
Unix socket or FIFO; if it starts with a vertical pipe bar | it
starts the command and communicate with it thru pipes. Typically the
command is some client application (either a GTK graphical
interface, or an Emacs, or perhaps a FastCGI) which communicates
with GCC thru a textual protocol to be defined and documented.
The textual protcol should permit to examine, but not change, the
compilation state. For a lenghtly static analysis, it could be used to
show the properties the compiler currently know about a given
(compiled) source point.
Since I don't want to add multi-threading into GCC, my plan is to
implement this (only on Linux & BSD hosts!) by using old asynchronous
I/O, ie the F_SETOWN fcntl, the select system call, so that when some
input arrives on the channel, some routine might parse the input and
respond accordingly. The dirty trick is to have some volatile
sig_atomic_t varible which is set (by a SIGPOLL handler) and routinely
checked
/* set by SIGPOLL on input */
extern volatile sig_atomic_t comprob_interrupted;
The difficult part is to implement the probing routine
void comprob_compiler_probing(const char*file, int line);
I assume that the probed state is in some global GCC
variables. Otherwise, we need more arguments to pass them.
Then at appropriate places within the compiler the following macro is
called
#define comprob_maybe_probe() do{if (comprob_interrupted) \
comprob_compiler_probing(__FILE__,__LINE__): } while(0)
And then we could add many calls to the above macros. This is not
pretty, but in my experience on other software works quite well. and
is not that much intrusive (except in the source by addition of many
occurrences to this macrfo, and which executing by testing quite often
a volatile variable).
Feel free to tell me that it is a crazy idea. But remember that the
context is long-lasting compilations.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: what about a compiler probe?
> when given the -fcompiler-probe flag, it should get an a string > option with it. If this string is a (Unix) file path it indicate a > Unix socket or FIFO; if it starts with a vertical pipe bar | it > starts the command and communicate with it thru pipes. Typically the > command is some client application (either a GTK graphical > interface, or an Emacs, or perhaps a FastCGI) which communicates > with GCC thru a textual protocol to be defined and documented. > > The textual protcol should permit to examine, but not change, the > compilation state. For a lenghtly static analysis, it could be used to > show the properties the compiler currently know about a given > (compiled) source point. Sounds like something a decent debugger and a small about of scripting should already be able to do. Paul
Bug in multiple register reload inheritance?
I'm having a problem where choose_reload_regs() calls
subreg_regno_offset() with invalid parameters for my 16-bit ix86 port. It
starts out fine in emit_reload_insns():
Breakpoint 6, emit_reload_insns (chain=0x882b5a8) at reload1.c:7506
reg_last_reload_reg[nregno] = rld[r].reg_rtx;
piecemeal = (nregno < FIRST_PSEUDO_REGISTER
&& nr == nnr
&& inherit_piecemeal_p (r, nregno));
if (nregno < FIRST_PSEUDO_REGISTER)
for (k = 1; k < nnr; k++)
reg_last_reload_reg[nregno + k]
= (piecemeal
? regno_reg_rtx[REGNO (rld[r].reg_rtx) + k]
: 0);
(gdb) print nregno
$443 = 10
(gdb) call debug_rtx (rld[r].reg_rtx)
(reg:SI 8 si)
Registers are Himode: 8 = si, 9 = di, 10 = bp and 11 = es.
(gdb) call debug_rtx (chain->insn)
(insn:HI 35 159 36 4 (set (mem:SI (pre_dec:HI (reg/f:HI 12 sp)) [0 S4 A8])
(reg/v:SI 10 bp [orig:24 arg_a ] [24])) 32 {*pushsi1} (nil)
(insn_list:REG_LIBCALL 39 (nil)))
(gdb) call debug_reload ()
Reload order: 0
Reload 0: reload_in (SI) = (reg/v:SI 10 bp [orig:24 arg_a ] [24])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 0)
reload_in_reg: (reg/v:SI 10 bp [orig:24 arg_a ] [24])
reload_reg_rtx: (reg:SI 8 si)
The piecemeal path is taken and works fine:
(gdb) call debug_rtx (reg_last_reload_reg[10])
(reg:SI 8 si)
(gdb) call debug_rtx (reg_last_reload_reg[11])
(reg:HI 9 di)
So far, so good. Later, this happens in choose_reload_regs at
reload1.c:5640:
else if (GET_CODE (rld[r].in_reg) == SUBREG
&& REG_P (SUBREG_REG (rld[r].in_reg)))
{
byte = SUBREG_BYTE (rld[r].in_reg);
regno = REGNO (SUBREG_REG (rld[r].in_reg));
if (regno < FIRST_PSEUDO_REGISTER)
regno = subreg_regno (rld[r].in_reg);
mode = GET_MODE (rld[r].in_reg);
}
(gdb) frame 2
#2 0x084ec860 in choose_reload_regs (chain=0x882bbc4) at reload1.c:5674
(gdb) call debug_rtx (rld[r].in_reg)
(subreg:HI (reg/v:SI 10 bp [orig:24 arg_a ] [24]) 2)
(gdb) print byte
$472 = 2
(gdb) print regno
$473 = 11
(gdb) print mode
$474 = HImode
if (regno >= 0 && reg_last_reload_reg[regno] != 0)
{
enum reg_class class = rld[r].class, last_class;
rtx last_reg = reg_last_reload_reg[regno];
enum machine_mode need_mode;
i = REGNO (last_reg);
i += subreg_regno_offset (i, GET_MODE (last_reg), byte, mode);
(gdb) call debug_rtx (last_reg)
(reg:HI 9 di)
Here something has gone wrong, and the parameters to
subreg_regno_offset() are invalid:
(gdb) frame 1
#1 0x08504786 in subreg_regno_offset (xregno=9, xmode=HImode, offset=2,
ymode=HImode) at rtlanal.c:3017
If I take out the lines 5643 and 5644
if (regno < FIRST_PSEUDO_REGISTER)
regno = subreg_regno (rld[r].in_reg);
it will instead get regno = 10, mode = SImode and last_reg = (reg:SI 8 si)
and call subreg_regno_offset (xregno=8, xmode=SImode, offset=2, ymode=HImode)
which is fine and returns 1.
--
Rask Ingemann Lambertsen
Re: what about a compiler probe?
On Nov 26, 2006, at 3:20 PM, Basile STARYNKEVITCH wrote: The textual protcol should permit to examine, but not change, the compilation state. Sounds like a bad idea. I agree with the debugger comment. You're free to start up the compilation process with ptrace from your GUI and query/display/modify the state in whatever way you like. The problems I see are that any internal details that are exposed to the protocol fixes those details forever, or, should they not be fixed, breaks the stability of the protocol. Another suggestion would be to, if you want just a few status bits, add them to -Q and just read those bits on the output.
Re: what about a compiler probe?
> I am considering implementing the following feature into GCC using > the patch on http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01769.html > : a compiler probe which permits to probe the run of a compilation, > e.g. by displaying in emacs or a graphical GTK application the > current pass, Gimple representations, etc.. What you're describing sounds a bit like the VISTA interactive compilation environment which allows users to dynamically adjust the optimisation regime of individual functions and examine the effect: http://citeseer.ist.psu.edu/433065.html Ben
Differences in c and c++ anon typedefs
Hi all,
I have just come across a small difference in the way the C an C++ front
ends handle anonymous struct types which is causing me some grief. In
particular the following code:
typedef struct
{
int b1;
int b2;
} Blah;
void Function(Blah* b) {}
When i get the Blah type in the function above (After removing the
pointer) i then use TYPE_MAIN_VARIANT on it and do some special
processing on the resulting main varient type. In the C++ front end
TYPE_MAIN_VARIANT returns the type "Blah" where as in the C front end
this returns an anonymous RECORD_TYPE node.
If i then change the code to look like:
typedef struct
{
int b1;
int b2;
} Blah, Another;
And apply the TYPE_MAIN_VARIANT on "Another", C++ returns Blah and C
again returns the anonymous RECORD_TYPE. In my situation this is causing
some grief as i need a consistent name for the main varient type across
translation units. The C++ front end will allow me to do this by the
fact that it returns "Blah" as the main varient, however the C front end
does not.
Is there some way in the C front end of obtaining "Blah" from the
anonymous RECORD_TYPE node?
I was thinking of looking at the first TYPE_NEXT_VARIANT of the
anonymous RECORD_TYPE node which may give me "Blah", but I am not
certain it will do so all the time... Does anyone know if this will work
or if there is a better way?
Thanks,
Brendon.
Re: Differences in c and c++ anon typedefs
On Mon, 2006-11-27 at 12:02 +1100, Brendon Costa wrote: > And apply the TYPE_MAIN_VARIANT on "Another", C++ returns Blah and C > again returns the anonymous RECORD_TYPE. In my situation this is causing > some grief as i need a consistent name for the main varient type across > translation units. C and C++ have different rules about compatibilty of structs. C++ just mentions that the names have to be the same (and if the elements are different, the code violates the One Definition rule which means the code is invalid). For C, it does not talk about names, instead it mentions compatibility of struct based on the element layout. So what you are asking for is really not going to be the right thing. For full C rules you might able to read the function comptypes_internal in c-typeck.c or the C standard. In fact IIRC C99 has slightly different rules than C89. Thanks, Andrew Pinski
Re: AVR byte swap optimization
On Saturday 18 November 2006 00:30, Shaun Jackman wrote: > The following macro expands to some rather frightful code on the AVR: > > #define BSWAP_16(x) \ > x) >> 8) & 0xff) | (((x) & 0xff) << 8)) Sometimes gcc is generating better code if you cast values instead of masking. Try: ( (uint8_t)((x) >> 8) | ((uint8_t)(x)) << 8 ) -- vda
Re: Some clarifications regarding GIMPLE and LTO
[EMAIL PROTECTED] wrote: > Does the LTO branch try to achieve that the complete information for a > "Program" > can be sufficiently stored (in a file)? If this is already there, could anyone > provide some pointers to the API? Yes, on the LTO branch, we are working to store the entire translation unit in a form that can then be read back into the compiler. The global symbol table is stored using DWARF3, so you can read it back with a standard DWARF reader. See lto/lto.c on the LTO branch for the code that does this. At present, there are a few things that are not yet written out to the DWARF information (like GCC machine modes), but most things (types, functions, variables) are present. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Differences in c and c++ anon typedefs
Brendon Costa <[EMAIL PROTECTED]> writes:
| Hi all,
|
| I have just come across a small difference in the way the C an C++
| front ends handle anonymous struct types which is causing me some
| grief. In particular the following code:
|
| typedef struct
| {
| int b1;
| int b2;
| } Blah;
|
| void Function(Blah* b) {}
|
| When i get the Blah type in the function above (After removing the
| pointer) i then use TYPE_MAIN_VARIANT on it and do some special
| processing on the resulting main varient type.
C++ defines a notion of "class name for linkage purpose" -- that is a
notion used to define the One Definition Rule.
In general the TYPE_NAME of TYPE_MAIN_VARIANT is the class name for
linkage purpose.
The behaviour you reported on implements the rule 7.1.3/5:
If the typedef declaration defines an unnamed class (or enum), the
first typedef-name declared by the declaration
to be that class type (or enum type) is used to denote the class type
(or enum type) for linkage purposes only (3.5).
-- Gaby
Re: Problem with listing i686-apple-darwin as a Primary Platform
On Nov 6, 2006, at 7:49 PM, Andrew Pinski wrote: Right now after patches by the Apple folks causes you to need a newer dwarfutils I think that is a bug, and that bug has now been fixed. Let me know if there is any other badness I missed (or introduced along the way). Right now on the PowerPC side, Darwin before 8 (so Panther and before) are broken bootstrapping the mainline Fixed.
Re: AVR byte swap optimization
Denis Vlasenko wrote: The following macro expands to some rather frightful code on the AVR: #define BSWAP_16(x) \ x) >> 8) & 0xff) | (((x) & 0xff) << 8)) Sometimes gcc is generating better code if you cast values instead of masking. Try: ( (uint8_t)((x) >> 8) | ((uint8_t)(x)) << 8 ) gcc > 3.4.x always generates better code for casted values. This is PR middle-end/29749, and it affects i386 linux too. Uros.
