Re: [cygwin] libjava/java/lang/natClass.cc:904: error: thread-local storage not supported for this target
Christian Joensson writes: > Currently, and it's been there for a while, I get the following error > on gcc trunk: > > ../../../gcc/libjava/java/lang/natClass.cc:904: error: thread-local > storage not supported for this target > make[3]: *** [java/lang/natClass.lo] Error 1 > make[3]: Leaving directory > `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava' > make[1]: *** [all-target-libjava] Error 2 > make[1]: Leaving directory `/usr/local/src/trunk/objdir' > make: *** [all] Error 2 > > My system is this: > > Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with packages: > > binutils 20060817-1 2.17.50 20060817 > bison2.3-1 2.3 > cygwin 1.5.21-2 > dejagnu 20021217-2 1.4.2.x > expect 20030128-1 5.26 > gcc 3.4.4-1 > gcc-ada 3.4.4-1 > gcc-g++ 3.4.4-1 > gmp 4.1.4-2 > make 3.81-1 > tcltk20060202-1 8.4 > w32api 3.7-1 > > > and the configure was done like this: > > ../gcc/configure --enable-nls --without-included-gettext > --enable-version-specific-runtime-libs --without-x --enable-libgcj > --with-system-zlib --enable-threads=posix > --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang > > Now, am I doing something terribly wrong here or is this a well know "bug"? That __thread variable is surrounded by HAVE_TLS. There is a configure test which simply compiles this line: __thread int foo; and that configure test must succeed for HAVE_TLS to be set. So, to fix this we need to find out if that program did compile, and if so, how. --disable-tls in the configure line might solve your problem. Andrew.
Re: Fwd: Migration of Cross Compiler from gcc 3.4.6 to gcc 4.1.1
Rohit Arul Raj writes:
> Hi all,
> I am upgrading my cross-compiler from 3.4.6 to 4.1.1. It has built
> successfully. But while running the test suites, one of the errors
> that i was getting was due to the below mentioned file
> 20020611-1.c that too while optimizing for size Os.
On what arch?
>
> /* PR target/6997. Missing (set_attr "cc" "none") in sleu pattern in
> cris.md. Testcase from hp (at) axis.com. */
> int p;
> int k;
> unsigned int n;
>
> void x ()
> {
>unsigned int h;
>h = n <= 30;
>if (h)
> p = 1;
>else
> p = 0;
>
> if (h)
> k = 1;
> else
> k = 0;
>}
>
>unsigned int n = 30;
>
> main ()
> {
> x ();
> if (p != 1 || k != 1)
> abort ();
> exit (0);
> }
>
> This bug was fixed previously.
> 1. Can i get more information on how the bug was fixed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6997
> 2. what does sleu pattern mean?
Set if Lessthan or Equal Unsigned.
Andrew.
Re: Why does GCC allow '$' character in variable and function names?
Ian Lance Taylor writes: > gcc permits '$' as an implementation defined character. It does this > mainly for historical reasons. We also need it to link C++ programs with programs written in the Java language. That's because in Java, classes have synthetic fields whose names contain '$' chracaters. Andrew.
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
Roger Sayle writes: > > Hi David, > > On Sun, 22 Oct 2006, David Daney wrote: > > 2006-10-22 Richard Sandiford <[EMAIL PROTECTED]> > > David Daney <[EMAIL PROTECTED]> > > > > PR middle-end/29519 > > * rtlanal.c (nonzero_address_p): Remove check for values wrapping. > > :REVIEWMAIL: > > This is ugly. I agree with you and Richard that this optimization > isn't safe unless we can somehow prevent the RTL optimizers from > creating the problematic RTL that they currently do. But I also > worry how much benefit some platforms get from the current unsafe > transformation, and whether there'd be an observable performance > degradation with this fix. > > I think its best to apply this patch to mainline to allow the > benchmarking folks test whether there's any change. Likewise if > someone could check whether there are any/many code generation > differences in cc1 files (or similar), that'd go some way to > silencing my potential concerns. > > Only after this has been on mainline for a while without problems > or performance issues, should we consider backporting it to the 4.2 > branch. > > Does this sound reasonable? I must admit to being a little perplexed by this. We have an unsafe optimization that causes bad code to be generated on at least one platform. However, we want to continue to perform this unsafe optimization on our release branch until we are sure that removing it doesn't cause performance regressions. And, perhaps, if removing the optimization does cause performance regressions we won't remove it, preferring bad code to reduced performance. Is that a fair summary? Perhaps I'm misunderstanding what you wrote. Andrew.
Re: compiling very large functions.
Kenneth Zadeck writes: > Paolo Bonzini wrote: > > > >> While I agree with you, I think that there are so many things we > >> are already trying to address, that this one can wait. I think > >> we've been doing a very good job on large functions too, and I > >> believe that authors of very large functions are just getting > >> not only what they deserve, but actually what the expect: large > >> compile times (superlinear). > > > > Not too mention, that these huge functions are usually central to > > the program. If GCC decided that it is not worth optimizing the > > machine-generated bytecode interpreter of GNU Smalltalk, for > > example, I might as well rewrite it in assembly (or as a JIT > > compiler). Same for interpret.cc in libjava, though it is a tad > > smaller than GNU Smalltalk's interpreter. > > > > Unlike the authors of other VM's, I have no problem writing code > > so that the *latest* version of GCC will do its best, instead of > > complaining that GCC compiles my code worse on every release. > > So, I am ok with GCC doing stupid things because of bugs that > > I/we can fix, but not with GCC just giving up optimization on > > code that has always been compiled perfectly (in one/two minutes > > for about 30,000 lines of machine-generated code, despite being > > chock-full of computed gotos), that *can* be optimized very well, > > and that is central to the performance of a program. > I actually think that you small talk example is the exception and > not the rule. Mmm, probably. But these interpreters, while uncommon, are important in the sense that they are executed a great deal. Paolo is surely right: we don't want to cease to optimize those important programs on which we've done a good job in the past. > The thing is that even as memories get larger, something has to > give. There are and will always be programs that are too large for > the most aggressive techniques and my proposal is simply a way to > gracefully shed the most expensive techniques as the programs get > very large. Indeed, yes. > The alternative is to just to just shelve these bugs and tell the > submitter not to use optimization on them. It's hard to argue with your reasoning. Andrew.
Re: Volatile operations and PRE
Ricardo FERNANDEZ PASCUAL writes: > > Notice that the arg 1 of the MODIFY_EXPR is a COMPONENT_REF which > is marked as volatile. Notice also that the arg 1 of the > COMPONENT_REF is not marked as such, because that field is not > volatile itself and there are other accesses to it which are not > volatile. This is because in my source language individual load or > stores can be marked as volatile, not the variables. > So, I think the real question is: are COMPONENT_REF nodes allowed > to be marked as volatile by themselves? I think they should, and > actually it seems to work (the generated code looks correct). volatile is a type qualifier. The type of a COMPONENT_REF is the type of the operand to which it refers. If you want to change the effective type of a reference, you should generate a suitable CONVERT_EXPR. Like this: tree exp_type = TREE_TYPE (exp); tree v_type = build_qualified_type (exp_type, TYPE_QUALS (exp_type) | TYPE_QUAL_VOLATILE); tree addr = build_fold_addr_expr (exp); v_type = build_pointer_type (v_type); addr = fold_convert (v_type, addr); exp = build_fold_indirect_ref (addr); Andrew.
Re: Volatile operations and PRE
Ricardo FERNANDEZ PASCUAL writes:
> Andrew Haley wrote:
>
> >Ricardo FERNANDEZ PASCUAL writes:
> > > So, I think the real question is: are COMPONENT_REF nodes allowed
> > > to be marked as volatile by themselves? I think they should, and
> > > actually it seems to work (the generated code looks correct).
> >
> >volatile is a type qualifier. The type of a COMPONENT_REF is the type
> >of the operand to which it refers. If you want to change the
> >effective type of a reference, you should generate a suitable
> >CONVERT_EXPR. Like this:
> >
> > tree exp_type = TREE_TYPE (exp);
> > tree v_type
> >= build_qualified_type (exp_type,
> >TYPE_QUALS (exp_type) | TYPE_QUAL_VOLATILE);
> > tree addr = build_fold_addr_expr (exp);
> > v_type = build_pointer_type (v_type);
> > addr = fold_convert (v_type, addr);
> > exp = build_fold_indirect_ref (addr);
> >
> >
> Thank you. I have tried this and it works for stores, but not for loads
> (for loads it behaves as a non volatile load).
>
> I have done some experiments to try to understand what is happening, and
> I am a bit confused by the bahavior of GCC. Consider the following C
> function:
>
> static struct { int w; } s;
>
> void wait (void) {
> int t;
> loop:
> t = *((volatile int *) &s.w);
> if (t > 0) goto loop;
> }
>
>
> The code generated by "cc1 -O3" on x86 is:
>
> wait:
> movls, %eax
> pushl %ebp
> movl%esp, %ebp
> testl %eax, %eax
> jg .L6
> popl%ebp
> ret
> .L3:
> .L6:
> jmp .L6
>
>
> Which does not seem to respect the semantics of volatile. Is this the
> expected behavior or is this a bug?
I think it's a bug. The gimple is:
wait ()
{
int t;
void loop = <<< error >>>;
loop:;
t = s.w;
if (t > 0)
{
goto loop;
}
else
{
}
}
Whereas for this:
> FWIW, the folowing function:
>
> void wait2 (void) {
> int t;
> volatile int *p = &s.w;
> loop:
> t = *p;
> if (t > 0) goto loop;
> }
the gimple is:
wait2 ()
{
int t;
volatile int * p;
void loop = <<< error >>>;
p = (volatile int *) &s.w;
loop:;
t = *p;
if (t > 0)
{
goto loop;
}
else
{
}
}
which looks right. A temporary shouldn't make any difference here.
At a wild guess, maybe strip_useless_type_conversions() is doing
something Bad.
Andrew.
RE: Volatile operations and PRE
Dave Korn writes:
> On 07 November 2006 16:33, Andrew Haley wrote:
>
> > Ricardo FERNANDEZ PASCUAL writes:
>
> > > I have done some experiments to try to understand what is happening, and
> > > I am a bit confused by the bahavior of GCC. Consider the following C
> > > function:
> > >
> > > static struct { int w; } s;
> > >
> > > void wait (void) {
> > > int t;
> > > loop:
> > > t = *((volatile int *) &s.w);
> > > if (t > 0) goto loop;
> > > }
> > >
> > >
> > > The code generated by "cc1 -O3" on x86 is:
> > >
> > > wait:
> > > movls, %eax
> > > pushl %ebp
> > > movl%esp, %ebp
> > > testl %eax, %eax
> > > jg .L6
> > > popl%ebp
> > > ret
> > > .L3:
> > > .L6:
> > > jmp .L6
> > >
> > >
> > > Which does not seem to respect the semantics of volatile. Is this the
> > > expected behavior or is this a bug?
> >
> > I think it's a bug.
>
> > > FWIW, the folowing function:
>
> > which looks right. A temporary shouldn't make any difference here.
>
> Can I just remind everyone we had a huge long thread with this discussion
> last year and it might be worth reviewing. Look for the thread titled
> "volatile semantics" running from Tue 03/05/2005 09:42 to Tue 26/07/2005
> 00:09. (We should try not to repeat too much of a three-month long debate!)
Yeah it was, and there was a decision:
http://gcc.gnu.org/ml/gcc/2005-07/msg00731.html
So no, we don't have to revisit it.
Paolo Bonzini has come up with a simple fix.
Andrew.
Re: Volatile operations and PRE
Paolo Bonzini writes:
>
> > At a wild guess, maybe strip_useless_type_conversions() is doing
> > something Bad.
>
> Almost there. It looks like strip_useless_type_conversions is not used,
> and then something Bad happens.
>
> The following patch fixes it, but it's completely untested.
>
> 2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]>
>
> * gimplify.c (fold_indirect_ref_rhs): Use
> STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS.
>
> Index: ../../gcc/gimplify.c
> ===
> --- ../../gcc/gimplify.c(revision 118481)
> +++ ../../gcc/gimplify.c(working copy)
> @@ -3207,7 +3207,7 @@ fold_indirect_ref_rhs (tree t)
> tree sub = t;
> tree subtype;
>
> - STRIP_NOPS (sub);
> + STRIP_USELESS_TYPE_CONVERSION (sub);
> subtype = TREE_TYPE (sub);
> if (!POINTER_TYPE_P (subtype))
> return NULL_TREE;
>
> If anybody could regtest it, this is a regression from 3.3, likely to be
> present in all 4.x branches.
Regtested x86-64-gnu-linux. The only interesting failure was
mayalias-2.c, but that also fails before the patch.
Andrew.
$ /home/aph/gcc/gcc-4_2-branch/x86_64-unknown-linux-gnu/gcc/xgcc
-B/home/aph/gcc/gcc-4_2-branch/x86_64-unknown-linux-gnu/gcc/
/home/aph/gcc/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c
-w -O3 -g -fno-show-column -lm -o
/home/aph/gcc/gcc-4_2-branch/x86_64-unknown-linux-gnu/gcc/testsuite/gcc/mayalias-2.x4
/home/aph/gcc/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c:2:
internal compiler error: in splice_child_die, at dwarf2out.c:5565
Please submit a full bug report,
with preprocessed source if appropriate.
struct S { short x; };
typedef struct S __attribute__((__may_alias__)) test;
int f() {
int a=10;
test *p=(test *)&a;
p->x = 1;
return a;
}
int main() {
if (f() == 10)
__builtin_abort();
return 0;
}
Re: libgcj-2.95.1
[EMAIL PROTECTED] writes:
> hello,
> I'm trying to compile libgcj, but there are some errors. Can somebody help
> me?
> Thanks!
>
>
> checking whether build environment is sane... yes
> checking whether make sets ${MAKE}... yes
> checking for Cygwin environment... no
> checking for mingw32 environment... no
> checking host system type... i686-pc-linux-gnu
> checking for working aclocal... missing
> checking for working autoconf... missing
> checking for working automake... missing
> checking for working autoheader... missing
> checking for working makeinfo... missing
> checking for gcc... gcc -m64
> checking whether we are using GNU C... yes
> checking whether gcc -m64 accepts -g... yes
> checking for c++... c++
> checking whether we are using GNU C++... yes
> checking whether c++ accepts -g... yes
> checking build system type... i686-pc-linux-gnu
> checking for as... as
> checking for ar... ar
> checking for ranlib... ranlib
> checking for a BSD compatible install... /usr/bin/install -c
> checking whether to enable maintainer-specific portions of Makefiles... no
> i686-pc-linux-gnu
> checking for ranlib... (cached) ranlib
> checking for gcc... (cached) gcc -m64
> checking whether the C compiler (gcc -m64 -g -O2 ) works... no
> configure: error: installation or configuration problem: C compiler
> cannot create executables.
There's your clue. You're trying to build with "gcc -m64", which 2.95
doesn't do.
How about you tell us what you are really tring to do?
Andrew.
Re: Zdenek Dvorak and Daniel Berlin appointed loop optimizer maintainers
Zdenek Dvorak writes: > Hello, > > >I am pleased to announce that the GCC Steering Committee has > > appointed Zdenek Dvorak and Daniel Berlin as non-algorithmic maintainers > > of the RTL and Tree loop optimizer infrastructure in GCC. > > > >Please join me in congratulating Zdenek and Daniel on their new > > role. Zdenek and Daniel, please update your listings in the MAINTAINERS > > file. > > done. I am not sure whether it would be useful to indicate > non-algorithmicness somehow in the MAINTAINERS file? "non-algorithmicity", I suspect. :-) Andrew.
Re: build gcc with distcc
David Fang writes: > > *sigh* Bootstrapping on me 5+ yr. old dual-G4 takes quite a while, even > with make -j2 (which helps a lot). Wish-list: gcj-ccache for classpath > rebuild acceleration. What would it do? Andrew.
Re: Help for warning: type attributes are honored only at type definition
Francesco Montorsi writes: > > Looking around for a solution (e.g. suppress that specific warning) I've > found: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20345 > > and I wonder if the patch referenced there > (http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01511.html) does fix my > problem, too. Does anyone know that? > > In that case, which is the first GCC version which will include that patch? 4.2. I think you should try a snapshot. Snapshot gcc-4.3-20061118 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20061118/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. Andrew.
Re: strict aliasing warning
Joel Sherrill writes: > Silvius Rus wrote: > > > > I wrote some code (not released yet) that improves the accuracy of > > -Wstrict-aliasing using tree-ssa-alias information. The primary idea > > was to tell the programmer "go fix the types of variables x and y at > > lines ..." when -fstrict-aliasing breaks their code. > > > > It occurred to me that part of this code could be used as a > > preconditioner to aggressive optimization that would normally require > > -fstrict-aliasing, so this more aggressive optimization can then be > > performed selectively on individual functions even with > > -fno-strict-aliasing on the command line. I fear a little though that > > the functions which are provably free of cross-type aliasing might > > also not benefit much from -fstrict-aliasing, but I have very little > > experience with C compilers and GCC. Is this something worth pursuing? > > > How reliable is this detection and warning? Is it ready for testers yet? > > I ask because we have found a case where code in RTEMS breaks when > strict-aliasing is enabled. We are having discussions on how to > effectively perform an audit on RTEMS for other breakages. Right > now, the best idea is Ralf's to diff the assembly generated for > each file compiled with and without strict-aliasing. If there is a > difference, we will have to review it. This eliminates a lot of > the code base but it is still generating a lot of cases to examine > by hand. Ewww, that's scary. All it tells you is which code breaks today; even a minor bug fix in gcc might make a difference. Nonetheless, this is a really interesting idea, and I'm sure we'd all be very interested to see the results. Andrew.
Re: Interface for manipulating the abstract syntax tree
Ferad Zyulkyarov writes: > > Also, having the opportunity, I would like to ask you if there is any > function to use for deleting a tree (most particularly a statement or > variable declaration tree) or it would be enough to assign it as NULL > (which does not seems to be a gentle solution). Just assign it NULL. The garbage collector does the rest. Andrew.
Re: How to save a va_list object into a buffer and restore it from there?
Hoehenleitner, Thomas writes: > ps: Please ignore the following attachment. I am writing from my company > account and can not avoid it. Please do not send e-mail with this sort of disclaimer to the gcc mailing lists. They are against list policy, as described here: http://gcc.gnu.org/lists.html If you can not prevent your e-mail server from adding these disclaimers, then we suggest using a free web based e-mail account. Thanks. Andrew. > > This message (including any attachments) contains confidential > and/or proprietary information intended only for the addressee. > Any unauthorized disclosure, copying, distribution or reliance on > the contents of this information is strictly prohibited and may > constitute a violation of law. If you are not the intended > recipient, please notify the sender immediately by responding to > this e-mail, and delete the message from your system. If you > have any questions about this e-mail please notify the sender > immediately.
Re: Version of gcc , for which patch submitted?
[EMAIL PROTECTED] writes: > Hi, > I want to know that the patch at > "http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00211.html"; submitted for > which version of gcc? > How can we know that any of patch submitted , that for which version? > Kindly help me to figure it out soon. I'm guessing tree-ssa branch. svn://gcc.gnu.org/svn/gcc/branches/tree-ssa-20020619-branch Andrew.
Re: Unwinding CFI gcc practice of assumed `same value' regs
Jan Kratochvil writes: > currently (on x86_64) the gdb backtrace does not properly stop at > the outermost frame: > > #3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0 > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6 > #5 0x in ?? () > > Currently it relies only on clearing %rbp (0x above is > unrelated to it, it got read from uninitialized memory). That's how it's defined to work: %rbp is zero. > http://sourceware.org/ml/gdb/2004-08/msg00060.html suggests frame > pointer 0x0 should be enough for a debugger not finding CFI to stop > unwinding, still it is a heuristic. Not by my understanding it isn't. It's set up by the runtime system, and 0 (i.e. NULL on x86-64) marks the end of the stack. Officially. See page 28, AMD64 ABI Draft 0.98 \u2013 September 27, 2006 -- 9:24. Andrew.
Re: Unwinding CFI gcc practice of assumed `same value' regs
Mark Kettenis writes: > > Jan Kratochvil writes: > > > > > currently (on x86_64) the gdb backtrace does not properly stop at > > > the outermost frame: > > > > > > #3 0x0036ddb0610a in start_thread () from > > /lib64/tls/libpthread.so.0 > > > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6 > > > #5 0x in ?? () > > > > > > Currently it relies only on clearing %rbp (0x above is > > > unrelated to it, it got read from uninitialized memory). > > > > That's how it's defined to work: %rbp is zero. > > > > > http://sourceware.org/ml/gdb/2004-08/msg00060.html suggests frame > > > pointer 0x0 should be enough for a debugger not finding CFI to stop > > > unwinding, still it is a heuristic. > > > > Not by my understanding it isn't. It's set up by the runtime system, > > and 0 (i.e. NULL on x86-64) marks the end of the stack. Officially. > > > > See page 28, AMD64 ABI Draft 0.98 \u2013 September 27, 2006 -- 9:24. > > Unfortunately whoever wrote that down didn't think it through. In > Figure 3.4 on page 20, %rbp is listed as "callee-saved register; > optionally used as frame pointer". So %rbp can be used for anything, as > long as you save its contents and restore it before you return. Null-terminating the call stack is too well-established practice to be changed now. In practice, %ebp either points to a call frame -- not necessarily the most recent one -- or is null. I don't think that having an optional frame pointer mees you can use %ebp for anything random at all, but we need to make a clarification request of the ABI. > Since it may be used for anything, it may contain 0 at any point in > the middle of the call stack. > So it is unusable as a stack trace termination condition. The only > viable option is explicitly marking it as such in the CFI. > > Initializing %rbp to 0 in the outermost frame is sort of pointless > on amd64. The right way to fix the ABI is to specify that %ebp mustn't be [mis]used in this way, not to add a bunch more unwinder data. Andrew.
Re: Unwinding CFI gcc practice of assumed `same value' regs
Ulrich Drepper writes: > Andrew Haley wrote: > > Null-terminating the call stack is too well-established practice to be > > changed now. > > Which does not mean that the mistake should hold people back. Sure it does. Not breaking things is an excellent reason, probably one of the the best reasons you can have. > This is just one of the mistakes in the x86-64 ABI. It was copied > from x86 and it was wrong there already. > > > In practice, %ebp either points to a call frame -- not necessarily the > > most recent one -- or is null. I don't think that having an optional > > frame pointer mees you can use %ebp for anything random at all, > > Of course it means that. Really? Well, that's one interpretation. I don't believe that, though. It's certainly an inconsistency in the specification, which says that null-termination is supported, and this implies that you can't put a zero in there. > > The right way to fix the ABI is to specify that %ebp mustn't be > > [mis]used in this way, not to add a bunch more unwinder data. > > Nope. The right way is to specify things like backtraces with the > adequate mechanism. I fully support adding the Dwarf3 unwinder > requirements. "All of these" might be the right way to go. That is, keep null-terminating the stack, strengthen the rules about what you might do with %ebp, and extend debuginfo. Andrew.
Re: Unwinding CFI gcc practice of assumed `same value' regs
Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > In practice, %ebp either points to a call frame -- not necessarily the > > most recent one -- or is null. I don't think that having an optional > > frame pointer mees you can use %ebp for anything random at all, but we > > need to make a clarification request of the ABI. > > I don't see that as feasible. If %ebp/%rbp may be used as a general > callee-saved register, then it can hold any value. Sure, we already know that, as has been clear. The question is *if* %rbp may be used as a general callee-saved register that can hold any value. > And permitting %ebp/%rbp to hold any value is a very useful > optimization in a function which does not require a frame pointer, > since it gives the compiler an extra register to use. > > If you want to require %ebp/%rbp to hold a non-zero value, then you > are effectively saying that this optimization is forbidden. There is > no meaningful way to tell gcc "this is a general register, but you may > not store zero in it." It would be a poor tradeoff to forbid that > optimization in order to provide better support for exception > handling: exception handling is supposed to be unusual. Sure, that's reasonable: it's a good reason to suggest that the ABI spec (still in DRAFT state, I note!) might be changed. Andrew.
Re: GCC optimizes integer overflow: bug or feature?
Robert Dewar writes: > Brooks Moses wrote: > > > Now, if your argument is that following the LIA-1 standard will > > prevent optimizations that could otherwise be made if one > > followed only the C standard, that's a reasonable argument, but > > it should not be couched as if it implies that preventing the > > optimizations would not be following the C standard. > > I continue to suspect that the gains from this optimization are minimal > to non-existent in practice. Given the requirements in LIA-1, I would > think that taking advantage of overflow being undefined is only > acceptable That's an interesting use of the passive voice. Acceptable to whom? > if there is very clear quantitative data showing that this indeed > is a significant optimization. We've already defined `-fwrapv' for people who need nonstandard arithmetic. I don't see that this is any different from the interminable strict-aliasing discussion. Andrew.
Re: GCC optimizes integer overflow: bug or feature?
Robert Dewar writes: > Andrew Haley wrote: > > > We've already defined `-fwrapv' for people who need nonstandard > > arithmetic. > > Nonstandard implies that the result does not conform with the standard, I don't think it does; it merely implies that any program which requires "-fwrapv" for correct execution is not a strictly conforming program. Andrew.
Re: GCC optimizes integer overflow: bug or feature?
Gabriel Dos Reis writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > | Robert Dewar writes: > | > Andrew Haley wrote: > | > > | > > We've already defined `-fwrapv' for people who need nonstandard > | > > arithmetic. > | > > | > Nonstandard implies that the result does not conform with the standard, > | > | I don't think it does; it merely implies that any program which > | requires "-fwrapv" for correct execution is not a strictly conforming > | program. > > How many useful C programs do you know that are strictly conforming? > Certainly, GCC isn't stritcly conforming. > > I suspect the actual argument must be somewhere else. I'm sure it is. The only purpose of my mail was to clarify what I meant by "nonstandard", which in this case was "not strictly conforming". I didn't intend to imply anything else. In this case, there are two ways to view the program: either it has a bug, or it has an environmental depencency on wrapping integer arithmetic. Andrew.
[ecj] Bump ABI version
Java 5 has an extended class file format for annotations. We have to
support that in gcj-compiled code too, and it requires an ABI change.
Tom Tromey, I'd appreciate it if you'd have a quick check of this one.
We should probably port the code that throws a ClassFormatError if
we're not ABI-compatible to the active branches.
Andrew.
2006-12-19 Andrew Haley <[EMAIL PROTECTED]>
* java/lang/natClassLoader.cc (_Jv_CheckABIVersion): Move here
from include/jvm.h.
Add BC ABI Version 1.
Throw a ClassFormatError if we're not ABI-compatible.
(_Jv_RegisterClasses): Throw a ClassFormatError if we're not
ABI-compatible.
(_Jv_RegisterClasses_Counted): Likewise.
(_Jv_NewClassFromInitializer): Likewise.
Call Class::initializerSize to get size of initializer struct.
* include/jvm.h (_Jv_CheckABIVersion): Move to natClassLoader.cc.
* java/lang/Class.h (Class::initializerSize): New function.
gIndex: gcc/java/decl.c
===
--- gcc/java/decl.c (revision 120004)
+++ gcc/java/decl.c (working copy)
@@ -75,9 +75,9 @@
loader. */
/* If an ABI change is made within a GCC release series, rendering current
- binaries incompatible with the old runtimes, this number can be set to
+ binaries incompatible with the old runtimes, this number must be set to
enforce the compatibility rules. */
-#define MINOR_BINARYCOMPAT_ABI_VERSION 0
+#define MINOR_BINARYCOMPAT_ABI_VERSION 1
/* The runtime may recognize a variety of BC ABIs (objects generated by
different version of gcj), but will probably always require strict
Index: libjava/include/jvm.h
===
--- libjava/include/jvm.h (revision 120004)
+++ libjava/include/jvm.h (working copy)
@@ -658,30 +658,8 @@
// New style version IDs used by GCJ 4.0.1 and later.
#define GCJ_40_BC_ABI_VERSION (4 * 10 + 0 * 1000)
-inline bool
-_Jv_CheckABIVersion (unsigned long value)
-{
- // We are compatible with GCJ 4.0.0 BC-ABI classes. This release used a
- // different format for the version ID string.
- if (value == OLD_GCJ_40_BC_ABI_VERSION)
- return true;
-
- // The 20 low-end bits are used for the version number.
- unsigned long version = value & 0xf;
-
- if (value & FLAG_BINARYCOMPAT_ABI)
-{
- int abi_rev = version % 100;
- int abi_ver = version - abi_rev;
- if (abi_ver == GCJ_40_BC_ABI_VERSION && abi_rev <= 0)
-return true;
-}
- else
-// C++ ABI
-return version == GCJ_CXX_ABI_VERSION;
-
- return false;
-}
+void _Jv_CheckABIVersion (unsigned long value);
+
inline bool
_Jv_ClassForBootstrapLoader (unsigned long value)
Index: libjava/java/lang/natClassLoader.cc
===
--- libjava/java/lang/natClassLoader.cc (revision 120004)
+++ libjava/java/lang/natClassLoader.cc (working copy)
@@ -180,6 +180,41 @@
// _Jv_RegisterNewClasses() are of Type 2.
+// Check that the file we're trying to load has been compiled with a
+// compatible version of gcj. In previous versions of libgcj we
+// silently failed to register classes of an incompatible ABI version,
+// but this was totally bogus.
+void
+_Jv_CheckABIVersion (unsigned long value)
+{
+ // We are compatible with GCJ 4.0.0 BC-ABI classes. This release used a
+ // different format for the version ID string.
+ if (value == OLD_GCJ_40_BC_ABI_VERSION)
+ return;
+
+ // The 20 low-end bits are used for the version number.
+ unsigned long version = value & 0xf;
+
+ if (value & FLAG_BINARYCOMPAT_ABI)
+{
+ int abi_rev = version % 100;
+ int abi_ver = version - abi_rev;
+ // We are compatible with abi_rev 0 and 1.
+ if (abi_ver == GCJ_40_BC_ABI_VERSION && abi_rev <= 1)
+return;
+}
+ else
+{
+ // C++ ABI
+ if (version == GCJ_CXX_ABI_VERSION)
+ return;
+}
+
+ throw new ::java::lang::ClassFormatError
+(JvNewStringLatin1 ("Library compiled with later ABI version than"
+ " this version of libgcj supports"));
+}
+
// This function is called many times during startup, before main() is
// run. At that point in time we know for certain we are running
// single-threaded, so we don't need to lock when adding classes to the
@@ -194,14 +229,8 @@
{
jclass klass = *classes;
- if (_Jv_CheckABIVersion ((unsigned long) klass->next_or_version))
- (*_Jv_RegisterClassHook) (klass);
- else
- {
- fprintf (stderr, "ABI mismatch: library is compiled with "
- "the wrong version of gcj\n");
- abort ();
- }
+ _Jv_CheckABIVersion ((unsigned long) klass->next
Re: GCC optimizes integer overflow: bug or feature?
Denis Vlasenko writes:
>
> I wrote this just a few days ago:
>
> do {
> int32_t v1 = v << 1;
> if (v < 0) v1 ^= mask;
> v = v1;
> printf("%10u: %08x\n", c++, v);
> } while (v != 1);
>
> I would become rather sad if this will stop compiling correctly.
I can understand the objections to do with "dusty deck" code that
hasn't been looked at for aeons, but in the case of code that you
wrote so recently, given that you understand the issue, why not simply
use the standard idiom?
Andrew.
Re: GCC optimizes integer overflow: bug or feature?
Robert Dewar writes: > Paul Brook wrote: > > > As opposed to a buggy program with wilful disregard for signed overflow > > semantics? ;-) > > I know there is a smiley there, but in fact I think it is useful to > distinguish these two cases. This is, I think, a very interesting comment. I've thought about it for a little while, and I don't understand why you think it is useful to distinguish these two cases. Is it simply that one error is likely to be more common than another? Or is there some more fundamental reason? Andrew.
Re: GCC optimizes integer overflow: bug or feature?
Denis Vlasenko writes:
> On Tuesday 19 December 2006 20:05, Andrew Haley wrote:
> > Denis Vlasenko writes:
> > >
> > > I wrote this just a few days ago:
> > >
> > > do {
> > > int32_t v1 = v << 1;
> > > if (v < 0) v1 ^= mask;
> > > v = v1;
> > > printf("%10u: %08x\n", c++, v);
> > > } while (v != 1);
> > >
> > > I would become rather sad if this will stop compiling correctly.
> >
> > I can understand the objections to do with "dusty deck" code that
> > hasn't been looked at for aeons, but in the case of code that you
> > wrote so recently, given that you understand the issue, why not simply
> > use the standard idiom?
>
> I want sane compiler.
> One in which N-bit integer variables stay exactly N-bit.
> Without "magic" N+1 bit which is there "somethimes". a*2/2:
> If I say "multiply by 2 and _after that_ divide by 2,
> I meant that. Compiler can optimize it any way it wants,
> as long as result is the same as unoptimized one.
This kind of thinking was appropriate before standardization.
But C changed. C is no longer a kind of high-level assembly laguage:
it's defined by a standard, in terms of an abstract machine, and some
operations are not well-defined. If you want your programs to do what
you expect, you'd better find out what that abstract machine does.
> Above: v is a signed entity. I expect (v < 0) to be equal to
> "most significant bit is set". It's not about standards.
> It's about sanity.
You'd better find some other programming langauge that is defined the
way you want.
Andrew.
Re: Link tests not allowed
Douglas B Rupp writes: > DJ Delorie wrote: > > Is your target a newlib target? If so, are you including --with-newlib? > > > > Thanks, that was the problem. > Why isn't --with-newlib the default for newlib targets? AIX is a newlib target? Really? Andrew.
Re: Link tests not allowed
Douglas B Rupp writes: > Andrew Haley wrote: > > Douglas B Rupp writes: > > > DJ Delorie wrote: > > > > Is your target a newlib target? If so, are you including > > --with-newlib? > > > > > > > > > > Thanks, that was the problem. > > > Why isn't --with-newlib the default for newlib targets? > > > > AIX is a newlib target? Really? > > Don't really know one way or the other but it fixed the configure > problem. How does one tell a newlib target other than by looking at > configure.in and noconfigdirs? Newlib targets are targets without their own native libc. I find it exceedingly hard to believe that AIX falls into this category. Andrew.
[ecj] Fix ArrayStore testsuite failure
Fixes almost the last gcj test failure on the branch.
Andrew.
2007-01-02 Andrew Haley <[EMAIL PROTECTED]>
* expr.c (expand_java_arraystore): Make sure we perform a bounds
check at runtime before we perform a type check.
Index: expr.c
===
--- expr.c (revision 120344)
+++ expr.c (working copy)
@@ -1127,7 +1127,7 @@
&& TYPE_PRECISION (rhs_type_node) <= 32) ?
int_type_node : rhs_type_node);
tree index = pop_value (int_type_node);
- tree array_type, array;
+ tree array_type, array, temp, access;
/* If we're processing an `aaload' we might as well just pick
`Object'. */
@@ -1149,14 +1149,31 @@
index = save_expr (index);
array = save_expr (array);
+ /* We want to perform the bounds check (done by
+ build_java_arrayaccess) before the type check (done by
+ build_java_arraystore_check). So, we call build_java_arrayaccess
+ -- which returns an ARRAY_REF lvalue -- and we then generate code
+ to stash the address of that lvalue in a temp. Then we call
+ build_java_arraystore_check, and finally we generate a
+ MODIFY_EXPR to set the array element. */
+
+ access = build_java_arrayaccess (array, rhs_type_node, index);
+ temp = build_decl (VAR_DECL, NULL_TREE,
+build_pointer_type (TREE_TYPE (access)));
+ java_add_local_var (temp);
+ java_add_stmt (build2 (MODIFY_EXPR, TREE_TYPE (temp),
+temp,
+build_address_of (access)));
+
if (TREE_CODE (rhs_type_node) == POINTER_TYPE)
{
tree check = build_java_arraystore_check (array, rhs_node);
java_add_stmt (check);
}
- array = build_java_arrayaccess (array, rhs_type_node, index);
- java_add_stmt (build2 (MODIFY_EXPR, TREE_TYPE (array), array, rhs_node));
+ java_add_stmt (build2 (MODIFY_EXPR, TREE_TYPE (access),
+build1 (INDIRECT_REF, TREE_TYPE (access), temp),
+rhs_node));
}
/* Expand the evaluation of ARRAY[INDEX]. build_java_check_indexed_type makes
Re: Autoconf manual's coverage of signed integer overflow & portability
Andrew Pinski writes: > > This will always cause a trap on x86, even with -fwrapv so really > -fwrapv has a bug on x86. I will file this bug sometime later > tomorrow. Oh and fixing this bug will actually slow down users > of -fwrapv even more than what it is currently does because > you can no longer use the div instruction. Actually, you can still use div, but it's rather tricky. There's some code in libgcj to handle this very situation. Andrew.
Re: gcc, mplayer and profile (mcount)
H. J. Lu writes:
> On Wed, Jan 03, 2007 at 10:18:36AM -0800, Seongbae Park wrote:
> > >In fact, by default, gcc for the i386 targets will call _mcount. gcc
> > >for i386 GNU/Linux targets was changed to call mcount instead of
> > >_mcount with this patch:
> > >
> > >Thu Mar 30 06:20:36 1995 H.J. Lu ([EMAIL PROTECTED])
> > >
> > >* configure (i[345]86-*-linux*): Set xmake_file=x-linux,
> > >tm_file=i386/linux.h, and don't set extra_parts.
> > >(i[345]86-*-linux*aout*): New configuration.
> > >(i[345]86-*-linuxelf): Deleted.
> > >* config/linux{,-aout}.h, config/x-linux, config/xm-linux.h: New
> > >files.
> > >* config/i386/linux-aout.h: New file.
> > >* config/i386/linux.h: Extensive modifications to use ELF format
> > >as default.
> > >(LIB_SPEC): Don't use libc_p.a for -p. don't use libg.a
> > >unless for -ggdb.
> > >(LINUX_DEFAULT_ELF): Defined.
> > >* config/i386/linuxelf.h,config/i386/x-linux: Files deleted.
> > >* config/i386/xm-linux.h: Just include xm-i386.h and xm-linux.h.
> > >
> > >I believe that was during the time H.J. was maintaining a separate
> > >branch of glibc for GNU/Linux systems. Presumably his version
> > >provided mcount but not _mcount. I haven't tried to investigate
> > >further.
> > >
> > >In any case clearly gcc for i386 GNU/Linux systems today should call
> > >_mcount rather than mcount. I will make that change.
> >
> > I remember someone wanting to provide his own mcount().
> > Presumably, mcount() is weak in libc to cover such a use case ?
>
> It was a mistake. I don't remember why I did that way when I switched
> Linux from a.out to ELF. It should be fixed.
Trivia time: what is the longest delay between a bug being committed
to gcc before someone notices and a fix being committed? This one is
eleven years and eight months. I wonder if we have a record.
Andrew.
gcc 3.4 > mainline performance regression
This is from the gcc-help mailing list. It's mentioned there for ARM,
but it's just as bad for x86-64.
It appears that memory references to arrays aren't being hoisted out
of loops: in this test case, gcc 3.4 doesn't touch memory at all in
the loop, but 4.3pre (and 4.2, etc) does.
Here's the test case:
void foo(int *a)
{ int i;
for (i = 0; i < 100; i++)
a[0] += a[1];
}
gcc 3.4.5 -O2:
.L5:
leal(%rcx,%rsi), %edx
decl%eax
movl%edx, %ecx
jns .L5
gcc 4.3pre -O2:
.L2:
addl4(%rdi), %eax
addl$1, %edx
cmpl$100, %edx
movl%eax, (%rdi)
jne .L2
Thoughts?
Andrew.
--- Begin Message ---
Hi David,
I've noticed the same problem with the GCC 4.1.3 (in thumb mode for ARM).
When a simple test file is compiled with -s to only get the "pseudo" assembly
form, quality of the generated code is quite poor. I've seen an equivalent
inquiry to codesourcery mailing list, quoting that even if gcc 4.x series
perform good optimization, simple cases of loop are sadly compiled. But I'm
quite surprised by the miss of comments to this quote...
Ps: Happy new year everybody!
__
Hi,
We were using GCC 3.4.0 to generate Thumb code for ARM processor,
switching to GCC 4.1.1 has improved our code size (we always use -Os switch),
but has severely altered the execution speed.
After further investigation, we isolate one the problem in the
following example:
Source code:
void foo(int *a)
{ int i;
for (i = 0; i < 100; i++)
a[0] += a[1];
}
The result with GCC 3.4.0 with -mthumb -Os was:
:
0:b500push{lr}
2:6803ldr r3, [r0, #0]
4:4a03ldr r2, [pc, #12] (14 <.text+0x14>)
6:6841ldr r1, [r0, #4]
8:3a01sub r2, #1
a:185badd r3, r3, r1
c:2a00cmp r2, #0
e:d1fbbne 8
10:6003str r3, [r0, #0]
12:bd00pop {pc}
14:4240neg r0, r0
16:000flsl r7, r1, #0
when compiled for ARM with GCC 4.1.1 (and mainline too) with -mthumb
-O1, we get:
:
0:b510push{r4, lr}
2:1c04addsr4, r0, #0
4:2200movsr2, #0
6:6841ldr r1, [r0, #4]
8:4803ldr r0, [pc, #12] (18 <.text+0x18>)
a:6823ldr r3, [r4, #0]
c:185baddsr3, r3, r1
e:3201addsr2, #1
10:4282cmp r2, r0
12:d1fbbne.n c
14:6023str r3, [r4, #0]
16:bd10pop {r4, pc}
18:4240negsr0, r0
1a:000flslsr7, r1, #0
-> No so bad but slower than 3.4.0
when compiled with -mthumb -Os, we get:
:
0:b510push{r4, lr}
2:6802ldr r2, [r0, #0]
4:6844ldr r4, [r0, #4]
6:2100movsr1, #0
8:4b03ldr r3, [pc, #12] (18 <.text+0x18>)
a:3101addsr1, #1
c:1912addsr2, r2, r4
e:4299cmp r1, r3
10:d1fabne.n 8
12:6002str r2, [r0, #0]
14:bd10pop {r4, pc}
16:lslsr0, r0, #0
18:4240negsr0, r0
1a:000flslsr7, r1, #0
-> The Load of the loop end value is performed within the loop !
when compiled with -mthumb -O3, we get:
:
0:b530push{r4, r5, lr}
2:6802ldr r2, [r0, #0]
4:4d05ldr r5, [pc, #20] (1c <.text+0x1c>)
6:1d04addsr4, r0, #4
8:2100movsr1, #0
a:6823ldr r3, [r4, #0]
c:3101addsr1, #1
e:18d3addsr3, r2, r3
10:1c1aaddsr2, r3, #0
12:6003str r3, [r0, #0]
14:42a9cmp r1, r5
16:d1f8bne.n a
18:bd30pop {r4, r5, pc}
1a:lslsr0, r0, #0
1c:4240negsr0, r0
1e:000flslsr7, r1, #0
-> Amazingly slow !
Does anybody has a magic set of options to generate an efficient and
small code as 3.4.0 did.
Thanks in advance for any hints on this problem.
David
__
Do You Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible
contre les messages non sollicités
http://mail.yahoo.fr Yahoo! Mail
--- End Message ---
Re: gcc 3.4 > mainline performance regression
Steven Bosscher writes:
> On 1/5/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> > This is from the gcc-help mailing list. It's mentioned there for ARM,
> > but it's just as bad for x86-64.
> >
> > It appears that memory references to arrays aren't being hoisted out
> > of loops: in this test case, gcc 3.4 doesn't touch memory at all in
> > the loop, but 4.3pre (and 4.2, etc) does.
> >
> > Here's the test case:
> >
> > void foo(int *a)
> > { int i;
> > for (i = 0; i < 100; i++)
> >a[0] += a[1];
> > }
> >
> > gcc 3.4.5 -O2:
> >
> > .L5:
> > leal(%rcx,%rsi), %edx
> > decl%eax
> > movl%edx, %ecx
> > jns .L5
> >
> > gcc 4.3pre -O2:
> >
> > .L2:
> > addl4(%rdi), %eax
> > addl$1, %edx
> > cmpl$100, %edx
> > movl%eax, (%rdi)
> > jne .L2
> >
> > Thoughts?
>
> What does the code look like if you compile with -O2 -fgcse-sm?
A bit better, altho' there's still one memory ref:
.L2:
addl$1, %eax
addl4(%rdi), %edx
cmpl$100, %eax
jne .L2
Andrew.
Re: __sync_bool_compare_and_swap
Magnus Fromreide writes:
> I got so happy when __sync_bool_compare_and_swap showed up in 4.1 but
> now HEAD have changed the behaviour for me.
>
> Earlier I got (gcc version 4.1.2 20061028 (prerelease) (Debian
> 4.1.1-19)) (Yes, vendor version, but gcc.gnu.org versions did the same)
>
> lock
> cmpxchgl%edx, (%ecx)
>
> but now I get (gcc version 4.3.0 20070105 (experimental)) (rev 120486
> (this would be interesting in the output of gcc -v, is there a way to
> put the revision there?))
>
> call__sync_bool_compare_and_swap_4
>
> Now, reading the manual suggests that if I use the wrong architecture I
> should get a call of this form but since the code I used was
>
> int main()
> {
> int a;
> return __sync_bool_compare_and_swap(&a, 0, 1);
> }
>
> I think it should generate the cmpxchgl.
But it can't unless you use an architecture that has cmpxchgl.
cmpxchgl is a 486 instruction; if you compile for 386, we have to
generate the call because there is no such instruction.
Andrew.
Re: Re : gcc 3.4 > mainline performance regression
Please don't top-post. It's very confusing. Mick CORNUT writes: > I don't know exactly if I've understood all your previous > explanation (excepted the load & store motion part), but we pointed > out 2 different problems: > > Pb n°1: depending on the optimization level -03, a[0] and a[1] are > being loaded and stored on each loop iteration > Pb n°2: depending on the optimization level -0s, the max range > limit value (1.000.000) is loaded on each loop iteration > (previously in gcc 3.4.2, it was loaded once, then the register > holding it was decremented by one until null flag detected) > > It seems to me that your current remaks only apply to Pb n°1, am I wrong? That's right. Andrew.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
H. J. Lu writes: > I am enclosing a patch to implement a new linker swicth, > --dynamic-list-data. It is -Bsymbolic for function symbols only. > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > and Linux/ia64. There are only a few regressions. The function calls > within the new resulting DSOs will bind locally. It speeds up > the enclosed C++ testcase by > > 1. 23% on ia64. > 2. 6% on ia32. > 3. 3% on x86-64. > > Should we consider such optimization? That's a terrible name for the option. What does it mean? Andrew.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
H. J. Lu writes: > On Tue, Jan 09, 2007 at 01:38:00PM +0000, Andrew Haley wrote: > > H. J. Lu writes: > > > I am enclosing a patch to implement a new linker swicth, > > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > > > and Linux/ia64. There are only a few regressions. The function calls > > > within the new resulting DSOs will bind locally. It speeds up > > > the enclosed C++ testcase by > > > > > > 1. 23% on ia64. > > > 2. 6% on ia32. > > > 3. 3% on x86-64. > > > > > > Should we consider such optimization? > > > > That's a terrible name for the option. What does it mean? > > It is an extension of the current command line options: > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > --dynamic-list FILE Read dynamic list But you said it was like -Bsymbolic for function symbols only. What is the connection between C++ typeinfo and that? (Hint: Java doesn't use C++ typeinfo, but -Bsymbolic for function symbols only would be very useful.) Andrew.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
H. J. Lu writes: > On Tue, Jan 09, 2007 at 01:51:00PM +0000, Andrew Haley wrote: > > H. J. Lu writes: > > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > > > > H. J. Lu writes: > > > > > I am enclosing a patch to implement a new linker swicth, > > > > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > > > > I tried it with C, C++, Java and Fortran on Linux/ia32, > > Linux/x86-64 > > > > > and Linux/ia64. There are only a few regressions. The function > > calls > > > > > within the new resulting DSOs will bind locally. It speeds up > > > > > the enclosed C++ testcase by > > > > > > > > > > 1. 23% on ia64. > > > > > 2. 6% on ia32. > > > > > 3. 3% on x86-64. > > > > > > > > > > Should we consider such optimization? > > > > > > > > That's a terrible name for the option. What does it mean? > > > > > > It is an extension of the current command line options: > > > > > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > > > --dynamic-list FILE Read dynamic list > > > > But you said it was like -Bsymbolic for function symbols only. What > > is the connection between C++ typeinfo and that? (Hint: Java doesn't > > use C++ typeinfo, but -Bsymbolic for function symbols only would be > > very useful.) > > --dynamic-list is a generic linker feature. Users have to provide a > list of symbols, which will be bound dynamically and everything else > is bound locally. --dynamic-list-cpp-typeinfo includes a prefined > list for C++ typeinfo. --dynamic-list-data puts data symbols on > the dynamic list. OK, so in the case of --dynamic-list-data, there is no user-supplied list. Instead, there's (conceptually) an automatically-generated list, which contains every symbol that doesn't point to a function. Can't you just call the new option -Bsymbolic-functions? At least then people like me might have an outside chance of remembering it. Andrew.
Re: Enforcing order of execution for function arguments
Chris Jefferson writes: > One thing which comes up regularly in various C and C++ > messageboards is that statements like "f() + g()" and "a(f(), g())" > do not declare which order f() and g() will be executed in. > > How hard would it be to fix the order of execution in gcc/g++? > Could someone point me to the piece of code which must change, or > if it is only a very small change, the actual change required? I > would very much like to be able to benchmark this, as I can find no > previous case where someone has tried fixing the order of execution > to see if it actually makes any measureable difference. The easiest way is during gimplification: you'd walk over the arglist from left to right, calling gimplify_expr (&arg, pre_p, post_p, is_gimple_formal_tmp_var, fb_rvalue); on each arg. > Would anyone be interested in this being added as a command line argument? That would be a Bad Thing. Andrew.
Aliasing error in man page?
This is "man dlopen" ;
#include
#include
int main(int argc, char **argv) {
void *handle;
double (*cosine)(double);
char *error;
handle = dlopen ("libm.so", RTLD_LAZY);
if (!handle) {
fprintf (stderr, "%s\n", dlerror());
exit(1);
}
dlerror();/* Clear any existing error */
---
*(void **) (&cosine) = dlsym(handle, "cos");
---
if ((error = dlerror()) != NULL) {
fprintf (stderr, "%s\n", error);
exit(1);
}
printf ("%f\n", (*cosine)(2.0));
dlclose(handle);
return 0;
}
That is a strict-aliasing error, is it?
Andrew.
Re: Enforcing order of execution for function arguments
Roberto COSTA writes: > Andrew Haley wrote: > > Chris Jefferson writes: > > > > > One thing which comes up regularly in various C and C++ > > > messageboards is that statements like "f() + g()" and "a(f(), g())" > > > do not declare which order f() and g() will be executed in. > > > > > > How hard would it be to fix the order of execution in gcc/g++? > > > Could someone point me to the piece of code which must change, or > > > if it is only a very small change, the actual change required? I > > > would very much like to be able to benchmark this, as I can find no > > > previous case where someone has tried fixing the order of execution > > > to see if it actually makes any measureable difference. > > > > The easiest way is during gimplification: you'd walk over the arglist > > from left to right, calling > > > > gimplify_expr (&arg, pre_p, post_p, > > is_gimple_formal_tmp_var, fb_rvalue); > > > > on each arg. > > But would it be sufficient? I think so. > I guess you would also have to make sure that further passes (i.e. > out-of-ssa) do not revert what you have just done. If any arg had side-effects that would be a bug. Andrew.
Re: Mis-handled ColdFire submission?
Mike Stump writes: > On Jan 10, 2007, at 1:13 PM, Richard Sandiford wrote: > > I just wanted to guage the general feeling as to whether I'd > > screwed up, and whether I should have submitted the patches in a > > different way. > > I don't see a trivial way that is strictly better. The problem is > that some folks don't want the huge patch and some folks don't like > the spray of 60. Hard to please both at once. One strategy that > might be better would be to do them up on a development branch and > submit one patch at a time as you develop them and then when all is > said and done and all reviewed and approved, just merge it in. That's what I had in mind, yes. Develop a patch, test it, post it to list, commit to branch. Write the next patch, etc. Work in public, not in private. Unless there's some reason to hold a patch back, I can't see any reason not to post and commit a patch as soon as it's written and tested. > I'm used to this style from the Ada folks That style from the Ada folks tends to exclude other developers. Andrew.
Re: Tricky(?) aliasing question.
Sergei Organov writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > Sergei Organov <[EMAIL PROTECTED]> writes:
> >
>
> >> $ cat alias.c
> >> typedef struct { int i; } S;
> >>
> >> int i;
> >> int foo()
> >> {
> >> S const sc = { 10 };
> >> i = 20;
> >> // Accessing object 'i' of type 'int' through 'S' containing 'int'
> >> // field. Should be OK from C99 standard POV?
> >> *(S*)&i = sc;
> >
> > C99 says that you can access an object via "an aggregate or union type
> > that includes one of the aforementioned [basically, compatible] types
> > among its members (including, recursively, a member of a subaggregate
> > or contained union)" (section 6.5, paragraph 7). So on that basis
> > this looks OK to me.
>
> Yes, it looked OK due to that rule to me too, until I just came up with
> the following example in which either I've finally violated some rule,
> or GCC miscompiles the code:
>
> $cat alias3.c
> typedef struct {
> int i;
> float f;
> } H0;
>
> typedef struct {
> float f;
> int i;
> } H1;
>
> H1 h1 = { 0, 10 };
>
> int float_as_int() __attribute__((noinline));
> int float_as_int()
> {
> h1.f = 1;
> H0 h0 = *(H0*)&h1.f; // Should be OK? No, it is not?!
I don't think this is OK. Per C99, you can cast to the element type
from the struct or vice versa, but you can't cast from one struct type
to another via the first element. If this were possible, every struct
type that started with an int would be in a single alias set.
Andrew.
Re: Tricky(?) aliasing question.
Sergei Organov writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Sergei Organov writes:
> > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > Sergei Organov <[EMAIL PROTECTED]> writes:
> > > >
> > > int float_as_int()
> > > {
> > > h1.f = 1;
> > > H0 h0 = *(H0*)&h1.f; // Should be OK? No, it is not?!
> >
> > I don't think this is OK. Per C99, you can cast to the element type
> > from the struct or vice versa, but you can't cast from one struct type
> > to another via the first element.
>
> There is no word "casting" in the definition of the aliasing rules in
> C99. It talks about accessing of object through an lvalue of compatible
> type. In this example I access stored value of object "h1.f"
No, that's not what the code above does. You're accessing an object
of type h1 through an lvalue of type h0. Accessing h1.f would have
been perfectly OK, but that's not what the code above does.
Look at it again:
H0 h0 = *(H0*)&h1.f;
The LHS of this assignment is of type h0. The RHS is an object of
effective type h1. The fact that you're going via a pointer cast to
its first member is neither here nor there.
> of type "float" through an lvalue of type "H0" that is an aggregate
> type that includes "float" (a type compatible with the effective
> type of the object) among its members. That IMHO should be OK from
> C99 aliasing rules POV.
No. You can only access an object through an lvalue of compatible
type. In this case you're accessing an object of type h1 through an
lvalue of type h0.
> > If this were possible, every struct type that started with an int
> > would be in a single alias set.
>
> How else should I interpret these C99 wordings (re-citing again):
>
> An object shall have its stored value accessed only by an lvalue
> expression that has one of the following types: {footnote 73}
>
> - a type compatible with the effective type of the object,
> [...]
> - an aggregate or union type that includes one of the aforementioned
>types among its members (including, recursively, a member of a
>subaggregate or contained union)
And this is neither.
Andrew.
Re: Tricky(?) aliasing question.
Sergei Organov writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Sergei Organov writes:
> > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > >
> > > > Sergei Organov writes:
> > > > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > > > Sergei Organov <[EMAIL PROTECTED]> writes:
> > > > > >
> >> > > int float_as_int()
> > > > > {
> > > > > h1.f = 1;
> > > > > H0 h0 = *(H0*)&h1.f; // Should be OK? No, it is not?!
> > > >
> > > > I don't think this is OK. Per C99, you can cast to the element type
> > > > from the struct or vice versa, but you can't cast from one struct type
> > > > to another via the first element.
> > >
> > > There is no word "casting" in the definition of the aliasing rules in
> > > C99. It talks about accessing of object through an lvalue of compatible
> > > type. In this example I access stored value of object "h1.f"
> >
> > No, that's not what the code above does. You're accessing an object
> > of type h1 through an lvalue of type h0. Accessing h1.f would have
> > been perfectly OK, but that's not what the code above does.
> >
> > Look at it again:
> >
> >H0 h0 = *(H0*)&h1.f;
> >
> > The LHS of this assignment is of type h0.
>
> Yes.
>
> > The RHS is an object of effective type h1. The fact that you're going
> > via a pointer cast to its first member is neither here nor there.
>
> So "h1.f" is not an object?
This is too silly for words.
> If it is not, it brings us back to the validity of my boo()
> function from the initial post, for which 2 persons (3 including
> me) thought it's OK:
>
> S s;
> int boo()
> {
> s.i = 20;
> // Accessing 's' of type 'S' through 'int'. Is it aliasing rules
> // violation? Maybe yes, but on the other hand this could be
> // considered as accessing 's.i' of type 'int' through 'int' that
> // should be OK from C99 standard POV?
> *(int*)&s = 10;
> return s.i;
> }
>
> Do you think this one is OK then?
Yes. The standard says it's OK.
You can convert a pointer to a struct to the type of its first member,
and back to a pointer to the original struct and the pointer will
still be valid. What you can't do is use that converted pointer to
access an object of incompatible type.
> Anyway, I can rewrite the float_as_int() so that it will access plain
> float f:
>
> float f;
> int float_as_int()
> {
> h1.f = 1;
> H0 h0 = *(H0*)&f; // Should be OK? No, it is not?!
No. The types have to be compatible. If f were of type h0, this
would be OK. But f is of type float, so it isn't.
> return h0.i;
> }
>
> Does it change anything in your reasoning?
No.
Andrew.
Re: Tricky(?) aliasing question.
Sergei Organov writes: > If we come back to strict aliasing rules, then I will have to refer once > again to already cited place in the standard that says that I'm > permitted to access an object not only through a compatible type, but > also through a structure containing a field of compatible type (and > there is no indication that those field should be the first one in the > structure): > >An object shall have its stored value accessed only by an lvalue >expression that has one of the following types: > > - a type compatible with the effective type of the object, > [...] > - an aggregate or union type that includes one of the aforementioned > types among its members (including, recursively, a member of a > subaggregate or contained union) > > Or are you saying that I don't violate strict aliasing rules, but > instead some other rule from the standard? If so, then how to explain > that GCC stops to "miscompile" the code when I add -fno-strict-aliasing > option? That's what it's for. -fno-strict-aliasing exists to support such broken code. > Not that I insist on sane results of compilation of broken code, > but it seems that GCC thinks it's violation of strict aliasing > rules. 6.3.2.3 makes it quite clear that this: H0 h0 = *(H0*)&f; produces undefined behaviour. Andrew.
Re: Tricky(?) aliasing question.
Sergei Organov writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > Sergei Organov writes: > > > > > If we come back to strict aliasing rules, then I will have to refer once > > > again to already cited place in the standard that says that I'm > > > permitted to access an object not only through a compatible type, but > > > also through a structure containing a field of compatible type (and > > > there is no indication that those field should be the first one in the > > > structure): > > > > > >An object shall have its stored value accessed only by an lvalue > > >expression that has one of the following types: > > > > > > - a type compatible with the effective type of the object, > > > [...] > > > - an aggregate or union type that includes one of the > > aforementioned > > > types among its members (including, recursively, a member of a > > > subaggregate or contained union) > > > > > > Or are you saying that I don't violate strict aliasing rules, but > > > instead some other rule from the standard? If so, then how to explain > > > that GCC stops to "miscompile" the code when I add -fno-strict-aliasing > > > option? > > > > That's what it's for. -fno-strict-aliasing exists to support such > > broken code. > > Could you please give direct answer to the following question: > > Does the code in question violate strict aliasing rules? Yes. > > > Not that I insist on sane results of compilation of broken code, > > > but it seems that GCC thinks it's violation of strict aliasing > > > rules. > > > > 6.3.2.3 makes it quite clear that this: > > > >H0 h0 = *(H0*)&f; > > > > produces undefined behaviour. > > What it has to do with strict aliasing rules? The strict aliasing rues, are, in part, defined by Section 6.3.2.3. > Anyway, the only undefined behavior in this section I've found is: > > "7. A pointer to an object or incomplete type may be converted to a > pointer to a different object or incomplete type. If the resulting > pointer is not correctly aligned(57) for the pointed-to type, the > behavior is undefined." > > Let's suppose that in my example the alignment requirements for 'float' > and 'H0' types are the same. Then the cited item (7) allows me to > convert float* to/from H0* without invoking of undefined behavior. This is the relevant language, in whole: "A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned 57) for the pointed-to type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer." Note that you do not have permission to do anything with the converted pointer _except_ convert it back to the original pointer; everything else is undefined. You certainly may not use the converted pointer to create an lvalue. Andrew.
Re: Tricky(?) aliasing question.
Sergei Organov writes: > > BTW, I've tried once to raise similar aliasing question in > comp.std.c++. The result was that somebody started to talk about > validity of pointers conversions that IMHO has nothing to do with > strict aliasing, It's the same issue. > and the discussion died. It is relevant to comp.std.c++. It is not relevant to this list. We're now way off-topic, so I'm leaving this discussion. Andrew.
Re: PATCH: Build shared libraries with -Bsymbolic-functions
H. J. Lu writes: > On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote: > > > > >config/ > > > > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]> > > > > > > * ld-symbolic.m4: New. > > > > Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or > > ACX_PROG_LD_GNU_SYMBOLIC. > > > > >libgfortran/ > > > > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]> > > > > > > * aclocal.m4: Include ../config/lib-ld.m4 and > > > ../config/ld-symbolic.m4. > > > > Also, aclocal.m4 is automatically generated with "aclocal -I ../config" > > except in libjava. > > > > > * configure.ac: Use PROG_LD_GNU_SYMBOLIC. Set > > > libgcj_ld_symbolic to $SYMBOLIC_LDFLAGS if it isn't set. > > > > Please check if libgcj_ld_symbolic is now obsolete in > > libjava/configure.host. > > libjava will use -Bsymbolic on Linux, which is more aggresive than > -Bsymbol-functions. libjava doesn't use -Bsymbolic for all of its libraries, just for libgij, libjvm, and libawt. I'd use -Bsymbolic for libgcj as well, but (because of copy relocs) we'd have to compile all gcj executables -fpic. I presume your patch doesn't change this behaviour. Andrew.
Re: Mis-handled ColdFire submission?
Nathan Sidwell writes: > The major chunk of this reworking has been blocked from going into > mainline because GCC was in stages 2 & 3 for much of this year. > When it was in stage 1, we weren't in a position to add things > coherently. We've not deliberately been holding back on patches > that could have gone in earlier. Ah, that explains it all. Thank you. Andrew.
Re: Miscompilation of remainder expressions
Roberto Bagnara writes: > > Reading the thread "Autoconf manual's coverage of signed integer > overflow & portability" I was horrified to discover about GCC's > miscompilation of the remainder expression that causes INT_MIN % -1 > to cause a SIGFPE on CPUs of the i386 family. Are there plans to > fix this bug (which, to me, looks quite serious)? No, there aren't. It would make more sense for you to wrap % in some code that checks for this, rather than for us to slow down every division for this one special case. Andrew.
Re: Miscompilation of remainder expressions
Paolo Carlini writes: > > I would like to understand the issue better, however... What more is there to understand? It's an integer overflow. The processor generates a trap on integer overflows during division operations. Andrew.
Re: Miscompilation of remainder expressions
Paolo Carlini writes: > Roberto Bagnara wrote: > > > No, Paolo: the result of INT_MIN % -1 is zero, according to the standard. > > There is no overflow whatsoever involved. The overflow that you > > see is simply an artifact of GCC that produces assembly code that > > does not implement remainder expressions correctly. > > Ok, I believe you. However, isn't true that, in general, because the > sign of the result is implementation defined, The sign of the result of % is no longer (since C99) implementation- defined. Andrew.
Re: Miscompilation of remainder expressions
Paolo Carlini writes: > Andrew Haley wrote: > > > > Ok, I believe you. However, isn't true that, in general, because the > > > sign of the result is implementation defined, > > > >The sign of the result of % is no longer (since C99) implementation- > >defined. > > > > > I see. However, by default, I'm always talking about C++03... I just had a look at that, and it seems that they haven't yet adopted the tightening-up of the langauge used by C. However, the footnote says: "74) According to work underway toward the revision of ISO C, the preferred algorithm for integer division follows the rules defined in the ISO Fortran standard, ISO/IEC 1539:1991, in which the quotient is always rounded toward zero." It would be a very brave developer who chose to do anything different. Andrew.
Re: Miscompilation of remainder expressions
Michael Veksler writes: > Roberto Bagnara wrote: > > > > Reading the thread "Autoconf manual's coverage of signed integer > > overflow & portability" I was horrified to discover about GCC's > > miscompilation of the remainder expression that causes INT_MIN % -1 > > to cause a SIGFPE on CPUs of the i386 family. Are there plans to > > fix this bug (which, to me, looks quite serious)? > > All the best, > > > This problem is quite rare in practice (otherwise there would be > much more complaining). As such it may be too expensive, > performance-wise, to fix in GCC. It seems as one of those > classical things that can be worked-around in the kernel. I guess, or it can be fixed-up in user space. We already do this for the Java language. Andrew.
Re: Miscompilation of remainder expressions
Gabriel Dos Reis writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > | Michael Veksler writes: > | > Roberto Bagnara wrote: > | > > > | > > Reading the thread "Autoconf manual's coverage of signed integer > | > > overflow & portability" I was horrified to discover about GCC's > | > > miscompilation of the remainder expression that causes INT_MIN % -1 > | > > to cause a SIGFPE on CPUs of the i386 family. Are there plans to > | > > fix this bug (which, to me, looks quite serious)? > | > > All the best, > | > > > | > This problem is quite rare in practice (otherwise there would be > | > much more complaining). As such it may be too expensive, > | > performance-wise, to fix in GCC. It seems as one of those > | > classical things that can be worked-around in the kernel. > | > | I guess, or it can be fixed-up in user space. We already do this for > | the Java language. > > Andrew pointed me to his implementation. > I, however, have a question: why do we need to mess with signals at all? > I mean, could not we generate the following for "%": > > rem a b := > if abs(b) == 1 > return 0 > return a b > > is there any other corner case that will trigger the trap? I have tried it, and it is pretty expensive. It messes up the pipelines and it hides the % from the optimizer. IMO we should not do this by default, since it's such a nitpicky corner case. Andrew.
Re: Miscompilation of remainder expressions
Roberto Bagnara writes: > Andrew Haley wrote: > > Roberto Bagnara writes: > > > > > > Reading the thread "Autoconf manual's coverage of signed integer > > > overflow & portability" I was horrified to discover about GCC's > > > miscompilation of the remainder expression that causes INT_MIN % -1 > > > to cause a SIGFPE on CPUs of the i386 family. Are there plans to > > > fix this bug (which, to me, looks quite serious)? > > > > No, there aren't. It would make more sense for you to wrap % in some > > code that checks for this, rather than for us to slow down every division > > for this one special case. > > With all due respect, I must say I am shocked. I always thought > (and taught) that we, Free Software people, value standard conformance > and getting things right. This is a disgreement about interpretation of the langauge in the standard, which is: "The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behavior is undefined. When integers are divided, the result of the / operator is the algebraic quotient with any fractional part discarded.87) If the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a." If the quotient a/b is *not* representable, is the behaviour of % well-defined or not? It doesn't say. Andrew.
Re: Miscompilation of remainder expressions
Roberto Bagnara writes: > Andrew Haley wrote: > > > > If the quotient a/b is *not* representable, is the behaviour of % > > well-defined or not? It doesn't say. > > To the point that, when a/b is not representable, raising SIGFPE > for a%b is standard conformant behavior? > Note however that I am not saying that the standard is not defective. > Who knows how to write and submit C/C++ standard defect reports? > Let us do that, assuming that such a report has not been submitted > already. It's already been done. Andrew.
Reduce size of indirect-dispatch executables
I noticed that we were repeatedly reloading from memory this.class and
this.class.constants. It makes far more sense to read these values at
the start of a method, and that is what this patch does. It reduces
the text size of 32-bit indirect-dispatch executables by 1.4% and
64-bit by 1.3%.
We need a more general patch to hoist invariants in gcj -- there are a
lot of these -- but this is a good start.
Andrew.
2007-01-16 Andrew Haley <[EMAIL PROTECTED]>
* expr.c (expand_byte_code): Call cache_this_class_ref() and
cache_cpool_data_ref().
Set TYPE_CPOOL_DATA_REF.
(cache_cpool_data_ref): New function.
* constants.c (build_ref_from_constant_pool): Remove special-case
code for flag_indirect_classes.
* decl.c (finish_method): Move class initialization from here to
cache_this_class_ref.
* class.c (cache_this_class_ref): New function.
(build_class_ref): Use this_classdollar to get the
current class$.
Index: class.c
===
--- class.c (revision 120621)
+++ class.c (working copy)
@@ -110,6 +110,10 @@
static GTY(()) VEC(tree,gc) *registered_class;
+/* A tree that returns the address of the class$ of the class
+ currently being compiled. */
+static GTY(()) tree this_classdollar;
+
/* Return the node that most closely represents the class whose name
is IDENT. Start the search from NODE (followed by its siblings).
Return NULL if an appropriate node does not exist. */
@@ -1031,6 +1035,35 @@
return decl;
}
+/* Create a local variable that holds the the current class$. */
+
+void
+cache_this_class_ref (tree fndecl)
+{
+ tree classdollar_field = build_classdollar_field (output_class);
+ this_classdollar = build_decl (VAR_DECL, NULL_TREE,
+TREE_TYPE (classdollar_field));
+
+ java_add_local_var (this_classdollar);
+ java_add_stmt (build2 (MODIFY_EXPR, TREE_TYPE (this_classdollar),
+this_classdollar, classdollar_field));
+
+ /* Prepend class initialization for static methods reachable from
+ other classes. */
+ if (METHOD_STATIC (fndecl)
+ && (! METHOD_PRIVATE (fndecl)
+ || INNER_CLASS_P (DECL_CONTEXT (fndecl)))
+ && ! DECL_CLINIT_P (fndecl)
+ && ! CLASS_INTERFACE (TYPE_NAME (DECL_CONTEXT (fndecl
+{
+ tree init = build3 (CALL_EXPR, void_type_node,
+ build_address_of (soft_initclass_node),
+ build_tree_list (NULL_TREE, this_classdollar),
+ NULL_TREE);
+ java_add_stmt (init);
+}
+}
+
/* Build a reference to the class TYPE.
Also handles primitive types and array types. */
@@ -1050,7 +1083,7 @@
return build_indirect_class_ref (type);
if (type == output_class && flag_indirect_classes)
- return build_classdollar_field (type);
+ return this_classdollar;
if (TREE_CODE (type) == RECORD_TYPE)
return build_static_class_ref (type);
@@ -2537,7 +2570,7 @@
if (TYPE_NVIRTUALS (this_class))
return;
-
+
super_class = CLASSTYPE_SUPER (this_class);
if (super_class)
Index: decl.c
===
--- decl.c (revision 120621)
+++ decl.c (working copy)
@@ -2001,22 +2001,6 @@
build2 (TRY_FINALLY_EXPR, void_type_node, *tp, exit));
}
- /* Prepend class initialization for static methods reachable from
- other classes. */
- if (METHOD_STATIC (fndecl)
- && (! METHOD_PRIVATE (fndecl)
- || INNER_CLASS_P (DECL_CONTEXT (fndecl)))
- && ! DECL_CLINIT_P (fndecl)
- && ! CLASS_INTERFACE (TYPE_NAME (DECL_CONTEXT (fndecl
-{
- tree clas = DECL_CONTEXT (fndecl);
- tree init = build3 (CALL_EXPR, void_type_node,
- build_address_of (soft_initclass_node),
- build_tree_list (NULL_TREE, build_class_ref (clas)),
- NULL_TREE);
- *tp = build2 (COMPOUND_EXPR, TREE_TYPE (*tp), init, *tp);
-}
-
/* Convert function tree to GENERIC prior to inlining. */
java_genericize (fndecl);
Index: constants.c
===
--- constants.c (revision 120621)
+++ constants.c (working copy)
@@ -448,7 +448,7 @@
TREE_STATIC (decl) = 1;
TYPE_CPOOL_DATA_REF (output_class) = decl;
}
-
+
return decl;
}
@@ -459,25 +459,6 @@
{
tree d = build_constant_data_ref ();
tree i = build_int_cst (NULL_TREE, index);
- if (flag_indirect_classes)
-{
- tree decl = build_class_ref (output_class);
- tree klass = build1 (INDIRECT_REF, TREE_TYPE (TREE_TYPE (decl)),
- decl);
- tree constants = build3 (COMPONENT_REF,
-
Re: Miscompilation of remainder expressions
Roberto Bagnara writes: > Robert Dewar wrote: > > > Yes, it's a bug, is it a serious bug, no? Will real software > > be affected? no. Indeed I find any program that actually > > does this remainder operation in practice to be highly > > suspect. > > But I am not wrong if I say that a bug is a bug and must be fixed. > I was answering to a message saying (basically) "we won't fix > it since there is a performance penalty to be paid." It wasn't saying that. My opinion at the time was (and still is) that it probably isn't a bug, and there is a performance penalty to be paid for changing the behaviour, so we shouldn't fix it. If I had believed that it surely was a bug, then I wouldn't have made the performance argument: correctness first, then performance. Andrew.
Re: Miscompilation of remainder expressions
Ian Lance Taylor writes: > Joe Buck <[EMAIL PROTECTED]> writes: > > > I suggest that those who think this is a severe problem are the > > ones who are highly motivated to work on a solution. An > > efficient solution could be tricky: you don't want to disrupt > > pipelines, or interfere with optimizations that rely on > > recognizing that there is a modulo. > > I suspect that the best fix, in the sense of generating the best > code, would be to do this at the tree level. That will give loop > and VRP optimizations the best chance to eliminate the test for -1. > Doing it during gimplification would be easy, if perhaps rather > ugly. If there are indeed several processors with this oddity, > then it would even make a certain degree of sense as a > target-independent option. x86, x86-64, S/390, as far as I'm aware. Andrew.
Re: Miscompilation of remainder expressions
Ian Lance Taylor writes: > Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > > > Ian, do you believe something along the line of > > > > # > I mean, could not we generate the following for "%": > > # > > > # > rem a b := > > # > if abs(b) == 1 > > # > return 0 > > # > return a b > > # > > # On x86 processors that have conditional moves, why not do the equivalent > > # of > > # > > # neg_b = -b; > > # cmov(last result is negative,neg_b,b) > > # __machine_rem(a,b) > > # > > # Then there's no disruption of the pipeline. > > > > is workable for the affected targets? > > Sure, I think the only real issue is where the code should be > inserted. >From a performance/convenience angle, the best place to handle this is either libc or the kernel. Either of these can quite easily fix up the operands when a trap happens, with zero performance degradation of existing code. I don't think there's any need for gcc to be altered to handle this. Andrew.
Re: Miscompilation of remainder expressions
Gabriel Dos Reis writes: > On Wed, 17 Jan 2007, Andrew Haley wrote: > > | > | From a performance/convenience angle, the best place to handle this is > | either libc or the kernel. > > Hmm, that is predicated on assumptions not convenient to users > on targets that are not glibc-based or GNU/Linux-based. Well, if GNU libc/Linux/whatever can fix this bug in libc or the kernel, so can anyone else. "To a man with a hammer, all things look like a nail." It's very tempting for us in gcc-land always to fix things in gcc, not because it's technically the right place but because it's what we control ourselves. Andrew.
Re: Miscompilation of remainder expressions
David Daney writes: > > That only works if the operation causes a trap. Which it does in almost all cases. Let PPC do something different, if that's what really PPC needs. Andrew.
Re: Miscompilation of remainder expressions
Gabriel Dos Reis writes: > On Wed, 17 Jan 2007, Andrew Haley wrote: > > | Gabriel Dos Reis writes: > | > On Wed, 17 Jan 2007, Andrew Haley wrote: > | > > | > | > | > | From a performance/convenience angle, the best place to handle this is > | > | either libc or the kernel. > | > > | > Hmm, that is predicated on assumptions not convenient to users > | > on targets that are not glibc-based or GNU/Linux-based. > | > | Well, if GNU libc/Linux/whatever can fix this bug in libc or the > | kernel, so can anyone else. > > (1) people upgrde OS less frequently than compilers. > (2) it is not at all obvious that the problem is in the libc or in the kernel > > | "To a man with a hammer, all things look like a nail." It's very > | tempting for us in gcc-land always to fix things in gcc, not because > | it's technically the right place but because it's what we control > | ourselves. > > well, I'm unclear what your point is here, but certainly GCC is > at fault for generating trapping instructions. > So, we fix the problem in GCC, not because that is what we control > ourselves, but we we failed to generate proper code. It's not a matter of whose fault it is; trying to apportion blame makes no sense. You could blame the library for passing on the signal, or the kernel for passing the signal to the library, or the compiler for generating the instruction in the first place. If we decide that the current behaviour is wrong, then we want to change the behaviour. If we want to do that, then we want do to so in the way that has the least cost for most programs and most users. Andrew.
Re: Miscompilation of remainder expressions
Gabriel Dos Reis writes: > On Wed, 17 Jan 2007, Andrew Haley wrote: > > [...] > > | > | "To a man with a hammer, all things look like a nail." It's very > | > | tempting for us in gcc-land always to fix things in gcc, not because > | > | it's technically the right place but because it's what we control > | > | ourselves. > | > > | > well, I'm unclear what your point is here, but certainly GCC is > | > at fault for generating trapping instructions. > | > So, we fix the problem in GCC, not because that is what we control > | > ourselves, but we we failed to generate proper code. > | > | It's not a matter of whose fault it is; trying to apportion blame > | makes no sense. > > we have a communication problem here. Nobody is trying to apportion > blame. However, gcc is the tool that generates trapping instruction. > It is unclear why it would be the responsability of the OS or libc > to fix what GCC has generated in the first place. That makes no sense either. It's an engineering problem. We have a widget that does the wrong thing*. We have several ways to make it do the right thing, only one of which has no adverse impact on the existing users of the widget. Andrew. * (in some people's opinion)
Re: Miscompilation of remainder expressions
Gabriel Dos Reis writes: > On Wed, 17 Jan 2007, Andrew Haley wrote: > > | Gabriel Dos Reis writes: > | > On Wed, 17 Jan 2007, Andrew Haley wrote: > | > > | > [...] > | > > | > | > | "To a man with a hammer, all things look like a nail." It's very > | > | > | tempting for us in gcc-land always to fix things in gcc, not > because > | > | > | it's technically the right place but because it's what we control > | > | > | ourselves. > | > | > > | > | > well, I'm unclear what your point is here, but certainly GCC is > | > | > at fault for generating trapping instructions. > | > | > So, we fix the problem in GCC, not because that is what we control > | > | > ourselves, but we we failed to generate proper code. > | > | > | > | It's not a matter of whose fault it is; trying to apportion blame > | > | makes no sense. > | > > | > we have a communication problem here. Nobody is trying to apportion > | > blame. However, gcc is the tool that generates trapping instruction. > | > It is unclear why it would be the responsability of the OS or libc > | > to fix what GCC has generated in the first place. > | > | That makes no sense either. > | > | It's an engineering problem. We have a widget that does the wrong > | thing*. We have several ways to make it do the right thing, only one > | of which has no adverse impact on the existing users of the widget. > > You believe there is one solution, except that it does not work for > the supported target. Sorry, I don't understand what you mean by that. I've been thinking about why we see this so very differently, and it's dawned on me why that is. I first came across this "architectural feature" of the 8086 in the mid-1980s. To begin with, there was no divide overflow handler at all: the machine would simply crash. It took me a little while to figure out what was happening, but once I'd done so it was a simple matter to write a few lines of assembly language that fix up the operands and carry on. Fast-forward ten years or so and for the first time I come across unices running on an x86. And I was surprised to see that rather than fixing up the operands and continuing, the kernel punted the problem to the user's program, which usually responded by core dumping. "OK," I thought, "that must be what UNIX programmers want. This trap must be desired, because it is trivially easy to fixup and continue. Perhaps it's because programmers want to be alerted that there is a bug in their program." And that's what I thought until last week. :-) Andrew.
Re: Miscompilation of remainder expressions
Robert Dewar writes: > Joe Buck wrote: > > (off topic!) > > > On Wed, Jan 17, 2007 at 06:40:21PM -0500, Robert Dewar wrote: > >> H .. I wish some of the more important bugs in gcc received > >> the attention that this very unimportant issue is receiving :-) > >> > >> I guess the difference is that lots of people can understand > >> this issue. > > > > Yes, this phenomenon has been given a name, by Parkinson of Parkinson's > > law fame: "bike shed". > > Actually I don't think Parkinson uses this term. He states a similar > principle as: > > * THE LAW OF TRIVIALITY: The time spent on any item of a committee's > agenda will be in inverse proportion to the sum of money involved. Mm, but although the problem being dicussed here is trivial, some of the proposed solutions aren't. As the saying goes, "the cure is worse than the disease." Andrew.
Re: Miscompilation of remainder expressions
Ian Lance Taylor writes: > Robert Dewar <[EMAIL PROTECTED]> writes: > > > Ian Lance Taylor wrote: > > > > > We do want to generate a trap for x / 0, of course. > > > > Really? Is this really defined to generate a trap in C? > > I would be surprised if so ... > > As far as I know, but I think it would be a surprising change for x / > 0 to silently continue executing. > > But perhaps not a very important one. Java depends for correct execution on some divisions by zero (in libgcc) generating traps. For example, here's one in __udivmoddi4: if (d0 == 0) d0 = 1 / d0;/* Divide intentionally by zero. */ Andrew.
Re: gcc compile time support for assumptions
Ian Lance Taylor writes: > Abramo Bagnara <[EMAIL PROTECTED]> writes: > > > I'd like to know if gcc has implemented some generic way to help > > optimizer job by allowing programmers to specify assumptions (or > > constraints). > > The answer is no, there is nothing quite like you describe. > > But I think it would be a good idea. Something like this would greatly improve the code generation quality of gcj. There are a great many assertions that I could pass to VRP and the optimizers: this is invariant, this is less than that, and so on. Andrew.
Fix libgcj build failure on Alpha
write_barrier() is missing in the libgcj build. Fixed thusly.
Andrew.
2007-01-22 Andrew Haley <[EMAIL PROTECTED]>
* sysdep/alpha/locks.h (write_barrier): New.
Index: locks.h
===
--- locks.h (revision 120859)
+++ locks.h (working copy)
@@ -50,4 +50,12 @@
return compare_and_swap(addr, old, new_val);
}
+// Ensure that prior stores to memory are completed with respect to other
+// processors.
+inline static void
+write_barrier()
+{
+ __asm__ __volatile__("wmb" : : : "memory");
+}
+
#endif
Re: order of local variables in stack frame
Robert Dewar writes: > Markus Franke wrote: > > > Please let me know whether I missunderstood something completely. If > > this behaviour is correct what can I do to change it to the other way > > around. Which macro variable do I have to change? > > There is no legitimate reason to care about the order of variables > in the local stack frame! Or at least I don't see one, why do *you* > care? Generally one may want to reorder the variables for alignment > purposes anyway. And also, the optimizers rewrite your code to usch an extent that there isn't any simple correspondence between the stack slots used and any variables declared by the programmer. Andrew.
Re: Possible build problems with the "current" gcc
George R Goffe writes: > > --- David Daney <[EMAIL PROTECTED]> wrote: > > > This really looks like a java problem, CCing java@ > > I agree with this assessment. I'd like to get the person responsible for > this code > to take a look at my build logs. This is a FC6 x86_64 system by the way. Log > attached. > > > It looks like you are missing jack/jack.h > > > > On my FC6/x86_64 system these files are not even built, so I don't get > > the missing jack/jack.h error. Instead it builds the midi-alsa files. > > Why would this happen? > > > That is the only insight I can provide. > > > > David Daney > > Thanks for your response and your time on this issue. We don't have enough information. What was your configure line, for example? Andrew.
java: mark calls to external fndecls DECL_EXTERNAL
We weren't marking calls to external fndecls DECL_EXTERNAL, and this was causing build failures on PPC64. Andrew. 2007-01-29 Andrew Haley <[EMAIL PROTECTED]> * class.c (add_method_1): Mark fndecl as external unless we are compiling it into this object file. Index: class.c === --- class.c (revision 121108) +++ class.c (working copy) @@ -733,6 +733,10 @@ METHOD_NATIVE (fndecl) = 1; DECL_EXTERNAL (fndecl) = 1; } + else +/* FNDECL is external unless we are compiling it into this object + file. */ +DECL_EXTERNAL (fndecl) = CLASS_FROM_CURRENTLY_COMPILED_P (this_class) == 0; if (access_flags & ACC_STATIC) METHOD_STATIC (fndecl) = DECL_INLINE (fndecl) = 1; if (access_flags & ACC_FINAL)
Re: Failure to build libjava on 512MB machine
Gerald Pfeifer writes: > I can no longer build libjava on a machine with "just" 512MB of main > memory (FreeBSD/i386 5.4 in this case). > > Three weeks ago the build worked on that very machine; did we raise > our minimum requirements We just imported a whole new release of the Classpath library, and it's big. But that doesn't explain this bug. > or is this simply a bug? I think so. javax/swing/text/html/parser is quite small: $ /usr/bin/time make javax/swing/text/html/parser.lo 0.53user 0.16system 0:00.74elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+26369minor)pagefaults 0swaps $ ls -lh javax/swing/text/html/.libs/parser.o -rw-r--r-- 1 aph aph 260K Jan 30 11:44 javax/swing/text/html/.libs/parser.o I don't know why it is using so much memory in your case. > Gerald > > echo > /sw/test/GCC/trunk/libjava/classpath/lib/gnu/javax/swing/text/html/parser/*.class > > gnu/javax/swing/text/html/parser.list > /bin/sh ./libtool --mode=compile /files/pfeifer/OBJ-0129-2308/gcc/gcj > -B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ > -B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer > -fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib > --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o > gnu/javax/swing/text/html/parser.lo > -fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes > -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF > gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list > /files/pfeifer/OBJ-0129-2308/gcc/gcj > -B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ > -B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer > -fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib > --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c > -fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes > -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF > gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list > -fPIC -o gnu/javax/swing/text/html/.libs/parser.o > jc1: out of memory allocating 4072 bytes after a total of 536273352 bytes > gmake[3]: *** [gnu/javax/swing/text/html/parser.lo] Error 1 > gmake[3]: Leaving directory > `/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory > `/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava' > gmake[1]: *** [all-target-libjava] Error 2 > gmake[1]: Leaving directory `/files/pfeifer/OBJ-0129-2308' > gmake: *** [bootstrap-lean] Error 2
Re: Failure to build libjava on 512MB machine
Marco Trudel writes: > Andrew Haley wrote: > > Gerald Pfeifer writes: > > > I can no longer build libjava on a machine with "just" 512MB of main > > > memory (FreeBSD/i386 5.4 in this case). > > > > > > Three weeks ago the build worked on that very machine; did we raise > > > our minimum requirements > > > > We just imported a whole new release of the Classpath library, and > > it's big. But that doesn't explain this bug. > > You mean 0.93, right? Strictly speaking it's the (former) generics branch from Classpath, but yes. > > > or is this simply a bug? > > > > I think so. javax/swing/text/html/parser is quite small: > > > > $ /usr/bin/time make javax/swing/text/html/parser.lo > > What? No way! I always thought this must be something about 7gb or so. > Compiling my canadian cross mingw takes 2h. 40min to 50min is spend for > compiling html/parser... > I think a linux normal build (static, 32bit) also needs about 2h. A > cross host=mingw target=linux took only 50min to my surprise. > > 0.53user 0.16system 0:00.74elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k > > 0inputs+0outputs (0major+26369minor)pagefaults 0swaps > > > > $ ls -lh javax/swing/text/html/.libs/parser.o > > -rw-r--r-- 1 aph aph 260K Jan 30 11:44 javax/swing/text/html/.libs/parser.o > > > > I don't know why it is using so much memory in your case. > > I assume is has something to do with optimization. I think I was compiling the wrong file. There's gnu/javax/swing/text/html/parser.lo and javax/swing/text/html/partser.lo, which is much larger. Sorry. Anyway, I tried again, this time with the right file, and it took 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k and indeed, it does want a lot of memory - at peak some 550m. It'll be smaller on a 32-bit box, but not much smaller. Andrew.
Re: MIPS Wrong-code regression.
David Daney writes: > Richard, > > Sometime between 1/7 and 1/16 on the trunk I started getting wrong code > on a bunch of java testcases under mipsel-linux. > > It looks related to (but not necessarily caused by) this patch: > > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01346.html > > For example if we examine the assembler output of the PR9577.java > testcase, we see: > > . > . > . > $LBB2: > lw $2,40($fp) > sw $2,24($fp) > lw $2,24($fp) > move$4,$2 > .option pic0 > jal _ZN4java4lang6ObjectC1Ev > nop > > .option pic2 > lw $28,16($fp) > $LBE2: > move$sp,$fp > lw $31,36($sp) > lw $fp,32($sp) > addiu $sp,$sp,40 > j $31 > nop > > The call to _ZN4java4lang6ObjectC1Ev is being generated as non-pic, even > though that symbol is defined in libgcj.so. The assembler and linker > conspire to jump to address 0x for this call. > > It looks like the logic that decides if a symbol is external to the > compilation unit is faulty. > > Any ideas about where it might have gone wrong? Does http://gcc.gnu.org/ml/gcc/2007-01/msg01184.html fix this? Andrew.
Re: Failure to build libjava on 512MB machine
Tom Tromey writes: > >>>>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes: > > Andrew> Anyway, I tried again, this time with the right file, and it took > Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > Andrew> and indeed, it does want a lot of memory - at peak some 550m. It'll > Andrew> be smaller on a 32-bit box, but not much smaller. > > I suppose with some awful build hacking we could split this .o into > multiple parts. I'm fine with the situation as it is, myself, but I > will do this if the consensus is that we should. I'd want a bit more information. There's no reason that a 512M box couldn't cope with a 550M process. Sure, it'll be slow, but it should still work, and this is an extreme case. If there is to be a maximum process size during building, we need to make a sane decision about what that size should be. Andrew.
Re: Failure to build libjava on 512MB machine
Gerald Pfeifer writes: > On Tue, 30 Jan 2007, Andrew Haley wrote: > > 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata > > 0maxresident)k > > > > and indeed, it does want a lot of memory - at peak some 550m. It'll > > be smaller on a 32-bit box, but not much smaller. > > Ouch. I can confirm that on a 32-bit box of mine it fails with about > 500MB of main memory. Can you tell us a bit more about the config? It really shouldn't be failing to compile this program. Andrew.
Re: Failure to build libjava on 512MB machine
Mark Wielaard writes: > On Tue, 2007-01-30 at 12:55 -0700, Tom Tromey wrote: > > >>>>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes: > > > > Andrew> Anyway, I tried again, this time with the right file, and it took > > Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata > > 0maxresident)k > > Andrew> and indeed, it does want a lot of memory - at peak some 550m. > > It'll > > Andrew> be smaller on a 32-bit box, but not much smaller. > > > > I suppose with some awful build hacking we could split this .o into > > multiple parts. I'm fine with the situation as it is, myself, but I > > will do this if the consensus is that we should. > > It does look like we are scaring away some people with the long > build times and memory hungry build of libjava. I only started > building libgcj again recently when I got a > 3Ghz/64-bit/dual-core/2GB machine. And even on that box an > compile/install/test cycle is not something I want to do more than > once or twice a day. I'm surprised: the libgcj build takes about 15mis on my box, which is similar to yours. > Having a 'light' build would be really good. Even if it is just a > configure option that creates an unoptimized build. > > Has someone looked into why gcj takes so much memory/time to compile? Yes. Lots of times. It's not entirely to do with gcj: it's mostly time spent in the emiddle-end. gcc, g++, etc do the same. The main difference with gcj is that we're compiling bigger files. One thing that could be improved is the quality of trees geneerated by the gcj front-end, which are unnecessaily verbose, but that would shave a few percentage points of the total time/space. > And might recent changes in tree-ssa have increased memory and compile > time? Yes, I think so. Recent changes to the optimizers do cost compile time and space. I think the authors are aware of that. Andrew.
Re: Failure to build libjava on 512MB machine
Andrew Haley writes: > > > > It does look like we are scaring away some people with the long > > build times and memory hungry build of libjava. I only started > > building libgcj again recently when I got a > > 3Ghz/64-bit/dual-core/2GB machine. And even on that box an > > compile/install/test cycle is not something I want to do more than > > once or twice a day. > > I'm surprised: the libgcj build takes about 15mis on my box, which is > similar to yours. Actually, it used to take that long, but libgcj is a lot bigger these days. I will re-measure. Andrew.
Re: Failure to build libjava on 512MB machine
Benjamin Kosnik writes: > > I am somewhat concerned with the response of the java maintainers > (and others) that it's OK to require >512MB to bootstrap gcc with > java, or that make times "WORKSFORME." Well, I didn't say that, so I hope you aren't referring to me. But before we do anything we need to know more about the machine on which it failed. Ultimately, it's a question of what we consider to be a reasonable machine on which to build libgcj. I don't know the answer to that. Andrew.
Re: MIPS Wrong-code regression.
David Daney writes: > Tom Tromey wrote: > >> "David" == David Daney <[EMAIL PROTECTED]> writes: > > > > David> The call to _ZN4java4lang6ObjectC1Ev is being generated as non-pic, > > David> even though that symbol is defined in libgcj.so. The assembler and > > David> linker conspire to jump to address 0x for this call. > > > > Could also be the problem reported at the end of: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606 > > > > Tom > > I suspect it is the same problem. APH's patch would not have fixed it > if it were. OK. Does your patch work? If it does, I'm going to trace through jc1 to see if I can find the real origin of this regression. TVM, Andrew.
Re: Any hints on this problem? Thanks!
Re: US Daylight Savings Time Changes
Joe Buck writes: > On Sat, Feb 10, 2007 at 12:49:56AM -0500, David Edelsohn wrote: > > > Tom Tromey writes: > > > > Tom> David probably knows this, but for others, Jakub and Andrew put in a > > Tom> patch for this today. I think it is only on trunk, not any other > > Tom> branches. > > > >Should this be included in GCC 4.1.2? > > I think so. I'm glad someone raised the issue. > > For GNU/Linux and BSD-based systems, languages other than Java use > data files for time zone changes, so you'd need to check if your > tzdata package is new enough (use Google to find out how). I'm > surprised to learn that Java does it a different way. Are we > really shipping time zone information in gcc? Doesn't it change > every month or so (when considering the 180 or so countries in the > world)? We are looking carefully at the best way to solve this for Java, but it's hard. Andrew.
Re: GCC 4.1.2 RC2
Mark Mitchell writes: > Kaveh R. GHAZI wrote: > > [Java folks: see below for check-in window for daylight savings time > patches.] > > Therefore, if the Java folks have daylight savings time patches that > they would like to check in, please do so before Monday evening, > California time. Done. Andrew.
Re: Question about register allocation (GCC 4.1)
Thomas Bernard writes: > I have a question about retargeting the back-end of GCC 4.1. > Our targeted architecture uses four classes of registers: global ($RG), > locals ($RL), dependents ($RD), shareds ($RS). In total 31 hard > registers available for the all previous classes. > The amount of each register is only known at compile-time depending on > the needs of the program. > > Normally I would have to specify the number of registers for each class > in the .md and .h files which describe the targeted architecture. > But is it possible to have an arbitrary number of register in each class > and the number would be given by the compiler depending on the needs of > registers at compile-time (when the compiler discovers how many > registers of each class are needed) ??? > > Let's take an example... > A source file A needs 10 registers for the globals, 11 for the locals, 5 > for dependents and 5 for shareds (10RG+11RL+5RD+5RS<=31). And for a > program B needs 11 globals, 13 for the locals, 3 for dependents and 4 > for shareds (11RG+13RL+3RD+4RS<=31). Finally the program C needs 3 > globals and 10 locals (3RG+10RL<<31). > > So basically this is known at compile-time. Such as "dynamic" register > allocator. > Is it that possible and what are the implications on the register > allocator ??? That's more or less what the IA-64 does. You could look at how that port works. Andrew.
Re: What does coding-style tells about integer types for pointers ?
Please stop top-posting.
Kai Tietz writes:
>
> Richard Henderson <[EMAIL PROTECTED]>
> 08.03.2007 19:08
>
> > On Thu, Mar 08, 2007 at 06:06:57PM +0100, Kai Tietz wrote:
> > > > In gcc the file emutls.c assumes that a long has sizeof void * in
> > function
> > > > emutls_destroy.
> >
> > Not really. It assumes you can store the size of the array
> > in min(sizeof(long), sizeof(void*)) bytes.
> Just really ! The array arr has the type void ***, the cast happens on the
> first derefencing of arr. So the result remains a void **, which is for
> sure a pointer. This leads to a pointer truncation,
RTH is right. It isn't a pointer, it's an integer that has been
stored in a pointer. The pointer is not truncated, since it was never
a pointer in the first place. There is certainly no assumption that
long has sizeof void*, just that void* is large enough to hold the
length.
> therefore to a warning and a build failure. It is clear, that the first
> element of the array arr is in fact the integer value of a type with
> sizeof(void *).
> Wouldn't is better to have for this cast monster a structure. Something
> like
> struct sFieldArray {
> size_t count;
> void *arr[1];
> }
> ?
Andrew.
Re: Question for removing trailing whitespaces (not vertical tab) from source
Kai Tietz writes: > I want to remove some trailing whitespaces from gcc source as coding style > demands. Also I wrote, while doing a small tool for that, a feature to > replace horiz. tabs by spaces. But the question is by which width should > be used ? 8. Andrew.
For those using emacs ...
... a little tip. Add this to your c-mode-hook: (set-variable 'show-trailing-whitespace t) And you'll see all the trailing whitespace. On my system it appears bright red. Andrew.
Re: Question for removing trailing whitespaces (not vertical tab) from source
Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > Kai Tietz writes: > > > > > I want to remove some trailing whitespaces from gcc source as coding > > style > > > demands. Also I wrote, while doing a small tool for that, a feature to > > > replace horiz. tabs by spaces. But the question is by which width > > should > > > be used ? > > > > 8. > > But please do not turn tabs into spaces in the gcc source code. > > I think removing trailing whitespace would be OK, Please don't check it in, though! That would be really bad. It would do horrible things to diffs, particularly between branches. Andrew.
RE: Question for removing trailing whitespaces (not vertical tab) from source
Dave Korn writes: > On 13 March 2007 14:02, Andrew Haley wrote: > > > Kai Tietz writes: > > > > > I want to remove some trailing whitespaces from gcc source as coding > > style > demands. Also I wrote, while doing a small tool for that, a > > feature to > replace horiz. tabs by spaces. But the question is by which > > width should > be used ? > > > > 8. > > > Can you explain that value? It's just that 1) I see vast acres and acres > of > code where the tabstop size is two spaces 2) the coding standard doesn't seem > to /demand/ a specific tab size and 3) if we use 8-space TABs with the kind > of > depths of nesting the gcc code often contains we're going to exceed the > 80-column line length limit just on the leading indentation alone pretty > often That's not the question I answered, which was "when I come across a leading tab character in GNU souce code, how many spaces does that tab represent?" It says nothing about correct GNU indentation, which is two spaces. Andrew.
Re: Question for removing trailing whitespaces (not vertical tab) from source
Kai Tietz writes: > Andrew Haley <[EMAIL PROTECTED]> wrote on 13.03.2007 16:03:57: > > > Ian Lance Taylor writes: > > > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > > > > Kai Tietz writes: > > > > > > > > > I want to remove some trailing whitespaces from gcc > > > > > source as coding style demands. Also I wrote, while doing > > > > > a small tool for that, a feature to replace horiz. tabs > > > > > by spaces. But the question is by which width should be > > > > > used ? > > > > > > > > 8. > > > > > > But please do not turn tabs into spaces in the gcc source code. > > > > > > I think removing trailing whitespace would be OK, > > > > Please don't check it in, though! That would be really bad. It would > > do horrible things to diffs, particularly between branches. > > But I was questioned to do this stuff, for those files changed by a patch > of mine. So I tought, if I should do, than do it for the complete gcc (not > root) folder. How to process ? Feel free to do it to your local copy. Don't do it to the gcc source code repository. Andrew.
Re: Question for removing trailing whitespaces (not vertical tab) from source
Ian Lance Taylor writes: > I wonder if we could have some sort of svn trigger to check for > trailing whitespace as a pre-commit check on .c and .h files? It would be tricky, as we don't want it to barf on spaces that already were there. The emacs magic works very well for me: I'm sure that I have checked in no trailing spaces since enabling it. Andrew.
Re: RFC: obsolete __builtin_apply?
Steven Bosscher writes: > On 3/16/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > On 3/16/07, Steve Ellcey <[EMAIL PROTECTED]> wrote: > > > My thinking is that if libobjc was changed then we could put in a > > > depreciated message on these builtins for 4.3 and maybe remove them for > > > 4.4. > > > > libobjc has not changed yet. There was a patch a while back to change > > libobjc to use libffi but I need to go back to it and review it (as it > > was before I became a libobjc maintainer). > > Do you mean this patch: > http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00841.html Are there any performance issues to consider? Is using libffi slower/faster than the builtins? Andrew.
Tree VRP bug: internal compiler error: in build_int_cst_wide, at tree.c:886
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
This happens because we have a VIEW_CONVERT EXPR(double->long) that is
used in a conditional. VRP tries to register an edge assertion for
this expression:
unit size
align 64 symtab 0 alias set -1 canonical type 0x2dfee3c0 precision
64 min max
pointer_to_this chain >
arg 0 unit size
align 64 symtab 0 alias set -1 canonical type 0x2dffa6c0
precision 64
chain >
visited var def_stmt
Which eventually works its way down to:
if (!has_single_use (op))
{
val = build_int_cst (TREE_TYPE (op), 0);
register_new_assert_for (op, code, val, NULL, e, bsi);
retval = true;
}
and this fails with an ICE because TREE_TYPE (op) is real_type, and
you can't build_int_cst with a real_type.
The simplest way of fixing this is simply to disallow
VIEW_CONVERT_EXPR in this context. Comments?
Index: tree-vrp.c
===
--- tree-vrp.c (revision 122839)
+++ tree-vrp.c (working copy)
@@ -3485,7 +3485,6 @@
}
else if (TREE_CODE (rhs) == NOP_EXPR
|| TREE_CODE (rhs) == CONVERT_EXPR
- || TREE_CODE (rhs) == VIEW_CONVERT_EXPR
|| TREE_CODE (rhs) == NON_LVALUE_EXPR)
{
/* Recurse through the type conversion. */
Andrew.
Re: Tree VRP bug: internal compiler error: in build_int_cst_wide, at tree.c:886
Richard Guenther writes: > > It's indeed broken to look through VIEW_CONVERT_EXPRs here. The patch looks > obviously correct. OK, thanks. Forwarding to gcc-patches. Andrew.
Re: Building mainline and 4.2 on Debian/amd64
Joe Buck writes: > On Mon, Mar 19, 2007 at 10:35:15AM -0700, Andrew Pinski wrote: > > On 3/19/07, Joe Buck <[EMAIL PROTECTED]> wrote: > > >This brings up a point: the build procedure doesn't work by default on > > >Debian-like amd64 distros, because they lack 32-bit support (which is > > >present on Red Hat/Fedora/SuSE/etc distros). Ideally this would be > > >detected when configuring. > > > > Actually it brings up an even more important thing, distros that don't > > include a 32bit user land is really just broken. Why do these distros > > even try to get away with this, they are useless to 99.9% of the > > people and for the 0.1% of the people who find them interesting, they > > can just compile with --disable-multilib. > > Unfortunately, such distros are in common use, and the GCC project jumps > through hoops to support many things that get far less use. > > A platform that contains only 64-bit libraries is fundamentally a > different platform than one that has both 32- and 64-. Ideally there > would be a different target triplet for such platforms. Maybe > x86_64only? But that would have to be handled upstream. > > In the meantime, the installation instructions should tell people to > use --disable-multilib. Will that work? Unless there's some more configury I don't understand, they'll still end up with libraries in /lib64 rather than /lib. Andrew.
