Re: [lto] function to DECL associations for WPA repackaging
On Fri, Jun 13, 2008 at 12:49 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 4:39 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>>
>>> I have no idea how to make sure, in whopr, that function x sees foobar if
>>> you are going to cherry pick the globals also.
>>
>> I'm not sure I see the problem that you are pointing to. In this program:
>>
>> int N;
>> int foobar;
>> int *bar = &foobar;
>> int **foo = &bar;
>> x ()
>> {
>> int **x = foo;
>> return **x;
>> }
>>
>> All of 'foobar', 'bar' and 'foo' will be in the list of symbols
>> referenced by x().
>
> Why do you think foobar will be in the list?
>
> (I'm just curious, i'm not saying you are wrong).
Citing the code (add_referenced_var):
/* Scan DECL_INITIAL for pointer variables as they may contain
address arithmetic referencing the address of other
variables.
Even non-constant initializers need to be walked, because
IPA passes might prove that their are invariant later on. */
if (DECL_INITIAL (var)
/* Initializers of external variables are not useful to the
optimizers. */
&& !DECL_EXTERNAL (var))
walk_tree (&DECL_INITIAL (var), find_vars_r, NULL, 0);
It is because foo might turn out to be const (ipa-reference), ccp would
then pull in bar from its DECL_INITIAL and subsequently foobar
is referenced from its DECL_INITIAL (which you then can pull in as well).
We add all these reachable through DECL_INITIAL vars to avoid needing
to add them to referenced vars later on demand (I have a patch for that)
and to avoid aliasing issues (I don't have a patch for this part -- basically
we'd need to re-compute alias information if a pass added globals or
addressable variables to referenced vars. We can do this via a global
flag and a TODO).
In the end we need to fix this anyway, as you can for example see in
PR36291 where we basically end up with every global in every
functions referenced vars and
tree find ref. vars : 15.36 ( 5%) usr 0.80 ( 8%) sys 15.90 ( 5%) wall
817801 kB (35%) ggc
referenced vars computation is really inefficient here - quadratic in
the number of functions and globals. We could fix that particular
part by keeping a bitmap of referenced vars per global variable and
just merging that in. But probably pulling them in on-demand is
a more practical approach (after all this huge number of vars is
also the cause of the slowness of alias computation and partitioning
in this testcase).
Richard.
Question about how to implement abi specific va_list (and builtins)
Hi,
The issue is, that for x86_64 the call for a w64 abi function should be
supported. The problem is, that va_list has always the type of the target
and there is no abi specific switching supported. My first idea was to
make the define for va_list_type_node in tree.h overridable for targets,
or replace the use of this type in code by an new target specific macro
(e.g. TARGET_VA_LIST).
Additionally of course new builtin types have to be added for such
targets, as for x86_64<->w64 like __builtin_ms_va_list and
__builting_sysv_va_list.
I am not sure if this approach would be ok. May somebody could give me a
hint about how to implement it?
Thanks in advance,
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: [lto] function to DECL associations for WPA repackaging
On 6/12/08 6:49 PM, Daniel Berlin wrote:
On Thu, Jun 12, 2008 at 4:39 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
int N;
int foobar;
int *bar = &foobar;
int **foo = &bar;
x ()
{
int **x = foo;
return **x;
}
All of 'foobar', 'bar' and 'foo' will be in the list of symbols
referenced by x().
Why do you think foobar will be in the list?
It's reachable from DECL_INITIAL of another referenced variable which we
go through in find_referenced_vars.
Diego.
Re: [lto] function to DECL associations for WPA repackaging
On 6/13/08 3:27 AM, Richard Guenther wrote: But probably pulling them in on-demand is a more practical approach (after all this huge number of vars is also the cause of the slowness of alias computation and partitioning in this testcase). I agree, and the end result would be the same. By the time we're ready to stream out gimple_referenced_vars(), all the symbols we need should be in that vector. Diego.
Re: [lto] function to DECL associations for WPA repackaging
On Fri, Jun 13, 2008 at 12:29 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > On 6/13/08 3:27 AM, Richard Guenther wrote: > >> But probably pulling them in on-demand is >> a more practical approach (after all this huge number of vars is >> also the cause of the slowness of alias computation and partitioning >> in this testcase). > > I agree, and the end result would be the same. By the time we're ready to > stream out gimple_referenced_vars(), all the symbols we need should be in > that vector. I don't know about the serialization issues - if you load all global decls all the time we should be fine, but otherwise you would need to be able to re-cherry-pick more globals during local optimizations (or de-serialize all reachable globals like we have now in referenced_vars, but do not put the into the referenced_vars immediately). Richard.
Update on CIL branch
Hi, I wanted to give a small update on what has been done on the CLI branch (gcc svn repository branches/st) before the summit. I will not be able to be there, have fun :) What we have done lately - added binutils for cil as simple wrappers on DotGnu binutils simplifies build of a toolchain instructions on how to build the toolchain (binutils +gcc), link at the end of the mail - libc/libm we developed an implementation of libc/libm on top of mscorlib that allows most of c applications to be compiled and run on any CIL Virtual Machine A lot of users asked for it since previously the lack of an implementation of the standard library prevented the use of the code generated in a lot of real world applications, all C applications depends in a way or another from libc we called it libstd and now it is built just after the compiler - install in the bin directory also 2 wrappers on top on mono and ilrun to execute the generated applications (they just set correctly the libraries search PATH) What are we doing now: - we are defining an internal IR of the CLI Backend that is close to the CLI IR, on wich we can do some final optimizations mostly optimizations on how the evaluation stack is handled, taking advantage of its semantic (implicit conversions, keep values on the stack instead of using local variables) - we are developing a new set of binutils to handle CLI object files Now we are using binutils from DotGNU project. For the use in our context they had few drawbacks: - a special assembler must be used, the objects files (.o) are not standard CIL assemblies and need special tools to be manipulated - they used CIL reflection to do the initialization of global variables, - it did not support a static library format and - there where some errors linking varargs functions We are developing a new set of binutils that resolve all this issues. - update/merge with trunk I added a small README file that explains how to build and install gcc with the CLI Backend and CLI binutils. You can find it in the ST branch (http://gcc.gnu.org/viewcvs/branches/st/README?view=markup) Andrea C. Ornstein
Re: Resend: [PATCH] [MIPS] Fix asm constraints for 'ins' instructions.
On Thu, Jun 12, 2008 at 01:10:10PM -0700, David Daney wrote:
>>> Among the versions of GCC that can build the current kernel, will any
>>> fail on this code because the "i" constraint cannot be matched when
>>> expanded to RTL?
>>
>> Someone will point this out if I don't, so for avoidance of doubt:
>> this needs to be always_inline. It also isn't guaranteed to work
>> with "bit" being a separate statement. I'm not truly sure it's
>> guaranteed to work even with:
>>
>> __asm__ __volatile__ (" foo %0, %1" : "=m" (*p) : "i" (nr & 5));
>>
>> but I think we'd try hard to make sure it does.
>>
>> I think Maciej said that 3.2 was the minimum current version.
>> Even with those two issues sorted out, I don't think you can
>> rely on this sort of thing with compilers that used RTL inlining.
>> (always_inline does go back to 3.2, in case you're wondering.)
>>
>
> Well I withdraw the patch. With the current kernel code we seem to always
> get good code generation. In the event that the compiler tries to put the
> shift amount (nr) in a register, the assembler will complain. I don't think
> it is possible to generate bad object code, so best to leave it alone.
>
> FYI, the reason that I stumbled on this several weeks ago is that
> if(__builtin_constant_p(nr)) in the trunk compiler was generating code for
> the asm even though nr was not constant.
How about I simply put your patch into the -queue tree, everybody gives it
a nice beating and then we'll how well it'll hold up in the real world?
Ralf
[EMAIL PROTECTED]: Results for 4.4.0 20080613 (experimental) [trunk revision 136737] (GCC) testsuite on iq2000-unknown-elf]
Showed up for v850, iq2000, and m32c... Manual compilation results in zero warnings. --- Start of forwarded message --- Date: Fri, 13 Jun 2008 11:21:27 -0400 From: DJ Delorie <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Results for 4.4.0 20080613 (experimental) [trunk revision 136737] (GCC) testsuite on iq2000-unknown-elf gcc result changes... Multilib: iq2000-sim PASS-FAIL: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c (test for warnings, line 14) PASS-FAIL: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c (test for warnings, line 16) g++ result changes... LAST_UPDATED: Fri Jun 13 06:02:21 UTC 2008 (revision 136737) Target is iq2000-unknown-elf Host is i686-pc-linux-gnu Compiler version: 4.4.0 20080613 (experimental) [trunk revision 136737] (GCC) Platform: iq2000-unknown-elf configure flags: --prefix=/sata/dj/gnu/install --target=iq2000-elf --enable-languages=c,c++ --with-newlib --with-headers --with-mpfr=/usr/local --- End of forwarded message ---
Re: [tuples] API documentation
Ian Lance Taylor wrote: I think that when it is reasonably stable it should move into a .texi file in the source code. That is there the gcc internals manual lives. I would not be averse to moving the entire internals manual to the web in some form. But having it in two places does not seem like a good idea to me. I agree. And, I think in the source code is the right answer, even over the long term. For one thing, one often needs to know what the API *was* for some old version of GCC. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: C++ warnings vs. errors
Jonathan Wakely wrote: Hi Volker, thanks for picking these issues up. I told Manuel I'd review the rest of the remaining pedwarns, but haven't had time to do it either. Just to chime in here: Volker, I agree with your comments. Jonathan, Manuel, if you would please make the time to finish this project, that would be very much appreciated. We don't want this to be a case where we improved the infrastructure of the compiler -- but made the user experience worse. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: C++ warnings vs. errors
2008/6/13 Mark Mitchell <[EMAIL PROTECTED]>: > Jonathan Wakely wrote: >> >> Hi Volker, thanks for picking these issues up. I told Manuel I'd >> review the rest of the remaining pedwarns, but haven't had time to do >> it either. > > Just to chime in here: Volker, I agree with your comments. > > Jonathan, Manuel, if you would please make the time to finish this project, > that would be very much appreciated. We don't want this to be a case where > we improved the infrastructure of the compiler -- but made the user > experience worse. Mark, I also agree with Volker comments. But I am respectfully not going to tackle this. First, because I have very little free time and I have many other things half-backed that I would like to finish. And second and more importantly, to "finish the project" as you say, just involves to "grep -n -e "pedwarn" cp/*.c and s/pedwarn/permerror/ whatever you think must be an error by default. The only "difficulty" of this process is to know whether something must be a warning or an error by default and I don't have the knowledge to decide this. And, honestly, the idea of discovering it by trial and error is not very exciting. That may take a long time and a lot of iterations. This job would be done better and faster by someone knowledgeable in the C++ standard, who could also add a comment in each warning/error stating why it is given. (In fact, you don't even need to bootstrap and run the regression testsuite: I bet there won't be any testsuite errors since the C++ testsuite can't distinguish between warnings and errors unless you included "warning: " or "error: " in the dg-* statement. And those we fixed already when we submitted the patch. Of course, bonus points would be to add those tests for each permerror so we don't regress in the future.) I am deeply sorry if I dissapoint you. But I think it is better to be honest than to silently ignore this issue. Manuel.
GCC 4.3.2 Status Report (2008-06-13)
Status == Congratulations and Kudos to Jakub for the GCC 4.3.1 release! The GCC 4.3 open for commits under normal release branch rules. Unfortunately, after getting to zero P1s, some more wrong-code and ice-on-valid errors have reappeared. So, the bug counts are up a bit. Quality Data Priority # Change from Last Report --- --- P18 + 8 P2 114 + 13 P32 - 13 --- --- Total 124 + 8 Previous Report === http://gcc.gnu.org/ml/gcc/2008-06/msg00155.html The next report for the 4.3 branch will be sent by Joseph. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
gcc-4.4-20080613 is now available
Snapshot gcc-4.4-20080613 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080613/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 136768 You'll find: gcc-4.4-20080613.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080613.tar.bz2 C front end and core compiler gcc-ada-4.4-20080613.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080613.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080613.tar.bz2 C++ front end and runtime gcc-java-4.4-20080613.tar.bz2 Java front end and runtime gcc-objc-4.4-20080613.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080613.tar.bz2The GCC testsuite Diffs from 4.4-20080606 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: [EMAIL PROTECTED]: Results for 4.4.0 20080612 (experimental) [trunk revision 136692] (GCC) testsuite on m32c-unknown-elf]
> I should start posting these to the testing list. Lots of m16c > improvements, but some m32c regressions. I haven't tried to diagnose > these yet, but if nobody claims it's their fault I will ;-) > > Anyone know why the regressions happened? > > PASS-FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O3 > -fomit-frame-pointer > PASS-FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O3 > -fomit-frame-pointer -funroll-loops > PASS-FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O3 > -fomit-frame-pointer -funroll-all-loops -finline-functions > PASS-FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O3 -g FYI I tracked this down to this patch (r136679): 2008-06-11 Richard Guenther <[EMAIL PROTECTED]> * alias.c (get_alias_set): Use the element alias-set for arrays. (record_component_aliases): For arrays and vectors do nothing. * c-common.c (strict_aliasing_warning): Handle the cases of alias set zero explicitly. * Makefile.in (dfp.o-warn): Add -Wno-error. Before the patch, -mcpu=m16c had execute failures for this test. After, -mcpu=m32c had execute failures. The problem is in the way newlib is compiled, not the test case itself. Richard, do you want me to try to track this down further, or is this enough for you to figure out what's happening?
