Re: 4.1 status?
On 9/9/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: Kenny Simpson wrote: > What is the status of the 4.1 branch? Any word on 4.1.2? My current plan is to do a 4.1.2 along with 4.2.0. My concern has been that with 4.2.0 moving slowly, trying to organize another release might just distract the developer community. However, I realize that's a pretty wide gap between 4.1.1 and 4.1.2. We could also do 4.1.2 sooner, and then do 4.1.3 along with 4.2.0. (I want to do a 4.1.x release along with 4.2.0 so as to avoid the problems we have in past with quality "going backwards" between releases from different branches.) I'm sure that, a priori, people would prefer a 4.1.2 release, but it does take effort. On the other hand, many 4.1 bugs are also in 4.2. Any thoughts? With my vendor hat on I'd prefer a 4.1.2 release sooner than I expect 4.2.0 - which would make the time we branch for 4.2.0 a good candidate. From a pure GCC development side I do not care very much about 4.1.2 (or even 4.0.4 which I don't expect at all). I guess a release of 4.1.2 together with branching for 4.2.0 might encourage to backport regression fixes from 4.2 to 4.1, as with stage1 starting, 4.1.2 will get even less attention than 4.2.0. Richard.
RE: libgfortran build broken on Darwin ppc
My original attempt to build gcc trunk yesterday used the cctools from Xcode 2.3 and produced the failure... /bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin _objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gc c/ -B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin 8/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin8/include -isystem /sw/lib/gcc4 /powerpc-apple-darwin8/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.2-200609 08/libgfortran -I. -iquote../../../gcc-4.2-20060908/libgfortran/io -I../../../g cc-4.2-20060908/libgfortran/../gcc -I../../../gcc-4.2-20060908/libgfortran/../gc c/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmis sing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -c -o maxloc0_4_r16.lo `test -f 'generated/maxloc0_4_r16.c' || echo '../../../gcc-4.2 -20060908/libgfortran/'`generated/maxloc0_4_r16.c /sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gcc/xgcc -B/sw/src/fink .build/gcc4-4.1.999-20060908/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-d arwin8/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem /sw/lib/gcc4/powe rpc-apple-darwin8/include -isystem /sw/lib/gcc4/powerpc-apc-4.2-20060908/libgfor tran/../gcc -I../../../gcc-4.2-20060908/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-st yle-definition -Wextra -Wwrite-strings -O2 -g -O2 -c ../../../gcc-4.2-20060908/l ibgfortran/generated/maxloc0_4_r16.c -fno-common -DPIC -o .libs/maxloc0_4_r16.o /var/tmp//ccPhvheT.s:905:Unknown pseudo-op: .literal16 Using the cctools from Xcode 2.4, the failure changes and moves to the linkage of libgfortran itself... ld: .libs/maxloc0_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxloc0_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxloc1_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxloc1_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxval_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc0_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc0_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc1_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc1_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minval_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/write.o unknown flags (type) of section 4 (__TEXT,__literal16) in load command 0 /usr/bin/libtool: internal link edit command failed So if there is a usable cctools, it doesn't exist outside of Apple. I wonder if the literal16 patch was meant for Darwin intel only as I understand they don't use stabs, etc at the moment. Jack
a new pass, "globalization", for user-space virtualization
hi,
I am looking into implementing a new instrumentation pass in gcc
called a "globalizer" and I would be really grateful for feedback
on whether or not such a pass could be considered for inclusion
(from a purely technical perspective).
1) Rationale
I work on network simulation tools. These tools are used to
describe network topologies, simulate traffic flows through
them and analyze the behavior of the network during the
simulation. One of the things the network guys would like
to be able to do is run a number of instances of an
existing user-space routing daemon in the simulator. To
be able to do this, you need, among others, to run
multiple virtual processes in a single user-space process
and each of these virtual processes must access a private
version of its global variables (static or not). In a perfect
world, we should be able to deal correctly with TLS variables
and make each simulation process maintain as many instances
of its TLS variables as needed.
TLS variables aside, there are a number of ways to implement
that globalization process:
1) implement a C/C++ globalizer which edits the source code.
2) on ELF systems, recompile all the code as PIC and play
crazy tricks with the dynamic loader
3) add an option to the compiler to perform the transformations
done by 1).
1) has already been implemented but only deals with C source
code. Adding support for C++ is a matter of ripping out an
existing c++ parser and hack transformations in it. I feel
this path is a dead end so, I would like to avoid going down
that road
2) I implemented this solution but it is pretty icky, and
requires hacking a copy of the glibc dynamic loader. There
are also a bunch of issues related to debugging (gdb needs
to be taught about multiple versions of the same function
in memory at different virtual addresses) which make
this solution rather unatractive.
So, I am looking into getting 3) to work
2) Proposed pass solution:
--
The idea is to change the way the address of a global
variable is calculated: rather than merely access a memory
area directly or through the GOT, we need to add another
level of indirection.
The simplest way to add another level of indirection is
to replace every declaration and definition of a static
variable by another static variable which would be an
array of the original variables:
static int a;
void foo (void)
{
a = 1;
}
would be transformed into:
static int a[MAX_PROCESS_NUMBER];
void foo (void)
{
a[process_id] = 1;
}
Another solution would be to do something like this:
extern void *magic_function (void *variable_uid);
static int a;
void foo (void)
{
void *ptr = magic_function (&a);
int *pa = (int *)ptr;
*pa = 1;
}
and then make the user provide magic_function at link time,
just like __cyg_profile_func_enter. magic_function
would need to lookup the variable uniquely
identified by its address within the context of the current
simulation process. This solution solves the problem of
a fixed-size array (no need to rebuild when the number of
processes changes) because it is then up to the
simulator's magic_function to do the right thing. However,
this would be much slower. Would the speed difference
really matter in my use-cases ? I doubt it.
3) questions
So, I have many questions but the main one is that I
would like to know whether or not there would be interest
in integrating such a pass in gcc proper or if this is
deemed to be too domain-specific to be considered.
thank you,
Mathieu
RE: a new pass, "globalization", for user-space virtualization
On 09 September 2006 16:34, mathieu lacage wrote:
> The idea is to change the way the address of a global
> variable is calculated: rather than merely access a memory
> area directly or through the GOT, we need to add another
> level of indirection.
>
> The simplest way to add another level of indirection is
> to replace every declaration and definition of a static
> variable by another static variable which would be an
> array of the original variables:
>
> static int a;
> void foo (void)
> {
> a = 1;
> }
>
> would be transformed into:
>
> static int a[MAX_PROCESS_NUMBER];
> void foo (void)
> {
> a[process_id] = 1;
> }
>
> Another solution would be to do something like this:
>
> extern void *magic_function (void *variable_uid);
>
> static int a;
> void foo (void)
> {
> void *ptr = magic_function (&a);
> int *pa = (int *)ptr;
> *pa = 1;
> }
>
> and then make the user provide magic_function at link time,
> just like __cyg_profile_func_enter.
I think this would be a great feature to have, even if it did only work with
simple globals and couldn't handle TLS.
Disclaimer: I haven't thought it through thoroughly yet :) Nor am I sure
whether the better solution might not be to just force all globals to be
accessed via the GOT and allow multiple GOT pointers? That would also keep
all the per-process data together, as opposed to grouping all the data for
each individual object across all processes together in an array, which might
be preferable.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: a new pass, "globalization", for user-space virtualization
On Sat, 2006-09-09 at 16:52 +0100, Dave Korn wrote: > I think this would be a great feature to have, even if it did only work with > simple globals and couldn't handle TLS. > > Disclaimer: I haven't thought it through thoroughly yet :) Nor am I sure > whether the better solution might not be to just force all globals to be > accessed via the GOT and allow multiple GOT pointers? That would also keep I am not sure what you are suggesting but unless we change in major ways the way ELF PIC works, we cannot allow multiple GOT pointers since the GOT is necessarily located at a fixed delta from the code base address. To have multiple GOT pointers, you need to have multiple code base addresses, that is, you need to map multiple times the same binary at multiple base addresses and make sure the dynamic loader also loads multiple times each library these binaries depend on. This is basically what some ELF systems implement as "loader namespaces". This is the solution I alluded when I refered to using magic ELF PIC tricks. There are 2 ways to implement this if you rebuild everything as PIC: 1) use dlmopen. The only problem is that the glibc version of dlmopen cannot accomodate more than 16 namespaces which would give me roughly 16 simulation processes per unix process. Nothing close to what I need. 2) rip out the glibc loader and change the dlmopen implementation to use a higher number of namespaces In both cases, the big problem is that the same function will then be located at two places in the virtual address space so, if you want to place a breakpoint in such a function, it will be cumbersome to make sure you break in every instance of that function. And it appears that this use-case is pretty common. i.e., the network guys I talked to about this solution went crazy because they spend their time putting a single breakpoint for all instances of a single function. > all the per-process data together, as opposed to grouping all the data for > each individual object across all processes together in an array, which might > be preferable. yes, it would be preferable but I don't see how to make it work (other than by running the same simulation twice: once to gather the memory requirements of the static area of each process and a second time to allocate the memory only once for each process). Mathieu
Re: a new pass, "globalization", for user-space virtualization
On Sat, 2006-09-09 at 17:34 +0200, mathieu lacage wrote:
> Another solution would be to do something like this:
>
> extern void *magic_function (void *variable_uid);
>
> static int a;
> void foo (void)
> {
> void *ptr = magic_function (&a);
> int *pa = (int *)ptr;
> *pa = 1;
> }
I think that the code above should be:
extern void *magic_function (void *variable_uid, int size);
static int a;
void foo (void)
{
void *ptr = magic_function (&a, sizeof (a));
int *pa = (int *)ptr;
*pa = 1;
}
Mathieu
gcc-4.2-20060909 is now available
Snapshot gcc-4.2-20060909 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060909/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 116799 You'll find: gcc-4.2-20060909.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060909.tar.bz2 C front end and core compiler gcc-ada-4.2-20060909.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060909.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060909.tar.bz2 C++ front end and runtime gcc-java-4.2-20060909.tar.bz2 Java front end and runtime gcc-objc-4.2-20060909.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060909.tar.bz2The GCC testsuite Diffs from 4.2-20060906 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Wcoercion Project (Google Summer of Code): Final Report
(Google does not requires me to write this report, yet I would like to bring some attention to the project, hoping that patches are reviewed and open issues are discussed.) The following is the final report on my Google's Summer of Code project. It summarises what we have achieved so far, which is pretty much all that was intended, and what remains to be done. A clear separation has been made between the original purpose of Wconversion, which has been encapsulated in a new option Wtraditional-conversion, and the purpose of the new Wcoercion option, which is to warn for implicit conversions that may alter a value. The names of these new options are provisional until an agreement on the final options names is reached. A more detailed explanation of each option and the motivation behind these changes can be found in the Wcoercion project wiki page. [1] Conversions examined are real from/to integer, signed from/to unsigned, and conversions to smaller width types. In this context, real includes both binary and decimal float. Binary float from/to decimal float conversions are also taken into account by Wcoercion. The code works for both C and C++ (and probably would work also for obj-c and obj-c++, although I don't know whether that is appropriate). Testcases can be found at the project's page [2]. Existing code has been reused as much as possible by assessing whether its intended behaviour falls into the description of Wtraditional-conversion or Wcoercion. For example, Wconversion warning messages in g++ are now triggered by Wcoercion instead. However, we have modified the old behaviour where it was appropriate. For instance, g++ no longer warns for int i = 1.0 as Wconversion did, since no value is changed in such conversion. A second example is that Wtraditional-conversion no longer warns for decimal float, since there are no default promotions for decimal float, so the default promotion could never make a difference whenever the value passed as argument or the expected type is a decimal float type. [3] Five patches are currently in the queue list pending review. An imminent additional patch will add support for decimal floats. Yet, an open and fundamental issue is the final name for each option. Once a decision is made, patches would need to be adjusted accordingly. Also, additional patches may rename all mentions of Wconversion in the GCC code to the final name. In the next days I will add the Wcoercion project to the GCC 4.3 Project's page.[4] Finally, I would like to acknowledge my mentor Ian Lance Taylor. His patience and helpful comments have been an important motivation to keep working in the project.[*] Also, thanks to Roger Sayle and Janis Johnson for their ideas, comments and help with some parts of the code. Manuel López-Ibáñez, [1] http://gcc.gnu.org/wiki/Wcoercion#Background [2] http://gcc.gnu.org/wiki/Wcoercion#Testcases [3] http://gcc.gnu.org/ml/gcc/2006-08/msg00230.html [4] http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning [*] For your information, the final evaluation has already finished.
Re: libgfortran build broken on Darwin ppc
Using the cctools from Xcode 2.4, the failure changes and moves to the linkage of libgfortran itself... ld: .libs/maxloc0_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxloc0_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxloc1_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxloc1_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxval_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc0_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc0_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc1_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc1_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minval_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/write.o unknown flags (type) of section 4 (__TEXT,__literal16) in load command 0 /usr/bin/libtool: internal link edit command failed So if there is a usable cctools, it doesn't exist outside of Apple. I wonder if the literal16 patch was meant for Darwin intel only as I understand they don't use stabs, etc at the moment. No, it was meant for everything, it might only work with the cctools that was handed out at WWDC though. I've been looking around and can't find them though. I'll keep you updated. -eric
Re: GCC testsuite timeout question (gcc.c-torture/compile/20001226-1.c)
On Tue, Sep 05, 2006 at 01:27:45PM -0700, Steve Ellcey wrote: > I am not sure what the 'right' way to do this is. I wound up editing > /usr/share/dejagnu/remote.exp to change 'set timeout 300' to 'set > timeout 2000' and I edited /usr/share/dejagnu/config/unix.exp to change > 'set status [remote_wait $dest 300]' to 'set status [remote_wait $dest > 2000]' It helps some. I tried this at the end of /usr/share/dejagnu/baseboards/unix.exp: set_board_info gcc,timeout 5400 set_board_info g++,timeout 5400 set_board_info gfortran,timeout 5400 [and so on for any x in "=== x tests ===" from the summary] Additionally, these changes as per your suggestion: --- /usr/share/dejagnu/config/unix.exp-orig 2005-03-05 21:06:49.0 +0100 +++ /usr/share/dejagnu/config/unix.exp 2006-09-06 19:27:27.0 +0200 @@ -81 +81 @@ - set status [remote_wait $dest 300] + set status [remote_wait $dest 5300] --- /usr/share/dejagnu/remote.exp-orig 2005-03-05 21:06:49.0 +0100 +++ /usr/share/dejagnu/remote.exp 2006-09-06 19:28:30.0 +0200 @@ -260 +260 @@ - set timeout 300 + set timeout 5500 With the above changes, the following timeouts are used according to the log files for the following tests: 5500 seconds: libffi, libgomp, libjava, g++, gfortran and objc libmudflap for anything not using a 10 or 20 second timeout libstdc++ when executing msgfmt, extract_symvers, compiling libstdc++-v3/testsuite/19_diagnostics/23591_thread-1.c, iconv7593.c, function7593.c and cxaatexit7593.cc gcc when compiling and executing gcc/testsuite/gcc/gcc.dg-struct-layout-1 compiling tls12629.c, tls_runtime12629.c running 'spawn --help' executing gcc/gcov running 'gcc/xgcc -v' 5400 seconds: gcc for anything not using the timeout of 5500 seconds 5300 seconds: (nothing) 600 seconds: libstdc++ for anything not using the timeout of 5500 seconds 20 seconds: libmudflap libmudflap.cth/pass40-frag.c execution and output pattern tests 10 seconds: libmudflap libmudflap.cth/pass37-frag.c and libmudflap.cth/pass39-frag.c execution and output pattern tests -- Rask Ingemann Lambertsen
Re: libgfortran build broken on Darwin ppc
Eric, One last question. Is it correct to assume that when the newer cctools with the literal16 support becomes available, things like 'integer(16)' will become available in gfortran for darwin? Jack
Re: libgfortran build broken on Darwin ppc
Jack Howarth wrote: Eric, One last question. Is it correct to assume that when the newer cctools with the literal16 support becomes available, things like 'integer(16)' will become available in gfortran for darwin? Seems reasonable to expect that it could be made to happen. -eric
long-long-cst1.c regression
Has anyone else noticed that the testcase long-long-cst1.c has started to fail on both powerpc-apple-darwin8.5.0 and on other ppc targets like powerpc64-unknown-linux-gnu? It appears to be still passing as of r116775 and to be failing as of r116778. Jack
Re: long-long-cst1.c regression
On Sat, 2006-09-09 at 22:16 -0400, Jack Howarth wrote: > It appears to be still passing as of r116775 and > to be failing as of r116778. The testcase was just added at r116777 so it cannot be a regression. -- Pinski
Re: long-long-cst1.c regression
Andrew, Odd. When I do 'svn log', the entry for r116777 doesn't show a testcase being added. Oh, well. Jack
Re: libgfortran build broken on Darwin ppc
That's not correct. The linker support only exists in ld64 for Xcode 2.4. It fails like this for ld(32). 32-bit Darwin targets shouldn't be using this assembly feature... Shantonu On Sep 9, 2006, at 12:16 PM, Eric Christopher wrote: Using the cctools from Xcode 2.4, the failure changes and moves to the linkage of libgfortran itself... ld: .libs/maxloc0_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxloc0_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxloc1_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxloc1_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/maxval_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc0_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc0_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc1_4_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minloc1_8_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/minval_r16.o unknown flags (type) of section 2 (__TEXT,__literal16) in load command 0 ld: .libs/write.o unknown flags (type) of section 4 (__TEXT,__literal16) in load command 0 /usr/bin/libtool: internal link edit command failed So if there is a usable cctools, it doesn't exist outside of Apple. I wonder if the literal16 patch was meant for Darwin intel only as I understand they don't use stabs, etc at the moment. No, it was meant for everything, it might only work with the cctools that was handed out at WWDC though. I've been looking around and can't find them though. I'll keep you updated. -eric
Re: libgfortran build broken on Darwin ppc
Shantonu Sen wrote: That's not correct. The linker support only exists in ld64 for Xcode 2.4. It fails like this for ld(32). 32-bit Darwin targets shouldn't be using this assembly feature... Right, I knew that. Looks like I have a typo though. Bah. I'll fix it shortly. Though nothing wrong with the autoconf check as well for now. -eric
