Re: Can't bootstrap gcc 4.2 RC1 on cygwin: gcc/boehm-gc/misc.c:680: undefined reference to `_GC_get_thread_stack_base'

Mohan, will you please copmment on this? Perhaps mingw is working properly, but Cygwin support has rotted. Thanks, Andrew. Brian Dessent writes: > Christian Joensson wrote: > > > /usr/local/src/branch/objdir/gcc/gcj > > -B/usr/local/src/branch/objdir/i686-pc-cygwin/libjava/ > > -B/usr/loc

Re: We're out of tree codes; now what?

Manuel López-Ibáñez writes: > On 23/03/07, Marc Espie <[EMAIL PROTECTED]> wrote: > > > > GCC being vastly a volunteer project, > > Actually, if you monitored gcc-patches and the subversion commits for > a while, you will realise that that statement is factually wrong. Most > of the code com

Re: How can I get VRP information for an RTX?

Andrew Pinski writes: > On 4/1/07, David Daney <[EMAIL PROTECTED]> wrote: > > The issue is that for some things (the java front-end) we need the > > trapping behavior. I just want to optimize it if the divisor is known > > to be non-zero. VRP knows, but by the time we generate the code it >

Re: Gcc and gfortran installation on MacBook Pro

Aurélien Benoit-Lévy writes: > I have no idea of what is a gcc-4.2 snapshot ? > > Could you explain a bit. Why, instead, do you not simply go to http://gcc.gnu.org/ and follow thw link marked snapshots? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire,

Re: Integer overflow in operator new

Andrew Pinski writes: > On 4/8/07, Bradley Lucier <[EMAIL PROTECTED]> wrote: > > Is this just a rumor, or are there data that backs this up. (That - > > fwrapv doesn't work, not that Dewar was always told that it doesn't > > work.) > > If you look into the bugzilla, you will see now two bug

Re: Problem with gcc 3.4.0 & 3.4.6 in ARM thumb mode regarding stack buffer allocation

Mick CORNUT writes: > > We've just pointed out a strange problem with gcc 3.4.0: we use it > for generating ARM 7 processor thumb code. This strange behavior > was pointed out with a function taking 5 parameters (the fifth one > is passed through stack according to the abi spec). Can y

Re: Re : Problem with gcc 3.4.0 & 3.4.6 in ARM thumb mode regarding stack buffer allocation

Please don't top-post. Mick CORNUT writes: > > > > - Message d'origine > > De : Andrew Haley <[EMAIL PROTECTED]> > > > > Mick CORNUT writes: > > > > > We've just pointed out a strange problem with gcc 3.4.0:

Re: [ARM optimization back-end] Strange bug in MySQL

Emmanuel Fleury writes: > Hi, > > I'm following a strange bug in MySQL Debian package for ARM plateforms: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411427 > > It seems that compiling the exact same code without optimization option > make it works. > > Could somebody take a quic

Re: [ARM optimization back-end] Strange bug in MySQL

Emmanuel Fleury writes: > Andrew Haley wrote: > > > > It seems that no-one has investigated what is really going on. All > > the gdb backtraces are without any debuginfo, and no-one has looked at > > where exactly the segfault happens. No-one has looked at the s

Re: Bootstrap comparison differnce(s) on cygwin with 4.2.0 RC3: ./ada/exp_aggr.o differs

Christian Joensson writes: > On cygwin, with D. Korn's proposed patch to cygwin's (i.e., newlib's) > stdio.h, I get a bootstrap failure do to comparison difference(s): Did you do a total rebuild of all gcc in a clean directory? You need to. Andrew.

Re: __builtin_cpow((0,0),(0,0))

Robert Dewar writes: > Paolo Carlini wrote: > > > Actually, sorry, __builtin_cpow returns (nan, nan) (got > > sidetracked by a strange issue I'm seeing in the C++ library), > > even "worse", so to speak... > > Well it certainly seems the right result in this case to me. Does > the standar

A plea for help

This is PR debug/19769. [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb Because of this regression it has been impossible to debug any gcj compiled program for several weeks now. gdb dies the instand libgcj is loaded. Can some C++ wizard please look at this and come up wit

Re: A question about java/lang.c:java_get_callee_fndecl.

Kazu Hirata writes: > Hi, > > I see that the implementation of LANG_HOOKS_GET_CALLEE_FNDECL in Java > always returns NULL (at least for the time being). > > static tree > java_get_callee_fndecl (tree call_expr) > { > tree method, table, element, atable_methods; > > HOST_WIDE_INT i

Re: A question about java/lang.c:java_get_callee_fndecl.

Steven Bosscher writes: > On Tuesday 22 March 2005 09:11, Andrew Haley wrote: > > Kazu Hirata writes: > > > Hi, > > > > > > I see that the implementation of LANG_HOOKS_GET_CALLEE_FNDECL in Java > > > always returns NULL (at least for

Re: Do we still need get_callee_fndecl?

Kazu Hirata writes: > > > I am wondering if we still need get_callee_fndecl in the presence of > > tree optimizers. I think this function performs a form of constant > > propagation at a rather strange place. > > Sorry for omitting you in the CC. > > Once you fix java_get_callee_fndecl,

Re: Name of files and functions etc.

Tom Tromey writes: > > "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes: > > >> I jumped on one of the newbe gcc hackers quests described at > >> http://gcc.gnu.org/projects/#beginner_gcc_hackers . > >> More precisely I started to clean up the long actions in > >> gcc/java/parse.y.

Re: Use Bohem's GC for compiler proper in 4.1?

Sam Lauber writes: > I know that Bohem's GC is used in the Java runtime for GCC. > However, the compiler proper itself can _really_ cramp people's > avalible RAM (for those who don't belive me and have Windows w/ > DJGPP, change all the memory controls from `auto' to the highest > value and ju

Re: Use Bohem's GC for compiler proper in 4.1?

Daniel Berlin writes: > On Fri, 2005-04-01 at 12:43 +0100, Andrew Haley wrote: > > Sam Lauber writes: > > > I know that Bohem's GC is used in the Java runtime for GCC. > > > However, the compiler proper itself can _really_ cramp people's > > &g

4.0 regression: g++ class layout on PPC32 has changed

I've had a gcj bug report saying that some CNI code has ceased to work on PPC 32, but I'm not sure that this is a gcj bug at all. The bug is that gcj and g++ no longer have comptabile class layout -- members are at different offsets. If you run the appended code with g++ version 3.4.1, you get

Re: 4.0 regression: g++ class layout on PPC32 has changed

Joe Buck writes: > On Mon, Apr 04, 2005 at 04:07:49PM +0100, Andrew Haley wrote: > > I've had a gcj bug report saying that some CNI code has ceased to work > > on PPC 32, but I'm not sure that this is a gcj bug at all. The bug is > > that gcj and g++ no long

Re: 4.0 regression: g++ class layout on PPC32 has changed

Giovanni Bajo writes: > Andrew Haley <[EMAIL PROTECTED]> wrote: > > > public: > > long long __attribute__((aligned(__alignof__( ::java::lang::Object > l; > > I don't recall the exact details, but I have fixed a couple of bugs about > the us

Re: 4.0 regression: g++ class layout on PPC32 has changed

Giovanni Bajo writes: > Andrew Haley <[EMAIL PROTECTED]> wrote: > > > > > public: > > > > long long __attribute__((aligned(__alignof__( ::java::lang::Object > > l; > > > > > > I don't recall the exact de

Re: [BUG mm] "fixed" i386 memcpy inlining buggy

I'm having a little difficulty understanding what this is for. Is it that gcc's builtin memcpy expander generates bad code, or that older versions of gcc generate bad code, or what? gcc generates too much code? Andrew.

HEAD regression: All java tests are failing with an ICE when optimized

HEAD, clean build this morning. i686-linux-gnu. With the libgcj "make check", there are many identical failures. These are of the form PR4766.java: In class 'PR4766': PR4766.java: In method 'PR4766.myfunction()': PR4766.java:0: internal compiler error: in hash_scan_set, at postreload-gcse.c:74

Re: HEAD regression: All java tests are failing with an ICE when optimized

Ranjit Mathew writes: > Andrew Haley wrote: > > HEAD, clean build this morning. i686-linux-gnu. > > > > With the libgcj "make check", there are many identical failures. > > > > These are of the form > > > > PR4766.java: In class &

Re: HEAD regression: All java tests are failing with an ICE when optimized

Andrew Pinski writes: > > On Apr 7, 2005, at 1:59 PM, Andrew Haley wrote: > > > So maybe it is a front end bug. I'm working on it now. > > Note I really doubt this is a front-end bug as exception handling > is lowered on the tree and then expanded from

Re: GCC 4.0 RC1 Available

Eric Botcazou writes: > > > We severely regressed for Java (22*2 new failures) 3 days ago. Please post the list of failures to [EMAIL PROTECTED] Andrew.

Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Mark Mitchell writes: > Your primary objective (get rid of -fno-unit-at-a-time) is one that I > strongly support. I have a problem with getting rid of -fno-unit-at-a-time. Sometimes we compile huge Java programs; however, keeping all the method bodies consumes vast amouts of memory. So, we so

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Steven Bosscher writes: > On Monday 11 April 2005 12:18, Andrew Haley wrote: > > Mark Mitchell writes: > > > Your primary objective (get rid of -fno-unit-at-a-time) is one that I > > > strongly support. > > > > I have a problem with getting rid of

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Nathan Sidwell writes: > Andrew Haley wrote: > > > Might it still be possible for a front end to force all pending code > > to be generated, even with -fno-unit-at-a-time gone? > > I think this is a bad idea. You're essentially asking for the backend > to

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Nathan Sidwell writes: > Andrew Haley wrote: > > Nathan Sidwell writes: > > > Andrew Haley wrote: > > > > > > > Might it still be possible for a front end to force all pending code > > > > to be generated, even with -fno-unit-at-a-tim

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Nathan Sidwell writes: > Andrew Haley wrote: > > Nathan Sidwell writes: > > > > 1) The C++ programs are smaller than the java programs > > > > That's my guess. Usually, C++ users compile one source file at a > > time, whereas Java users find i

Re: GCC 4.0 RC1 Available

Eric Botcazou writes: > > Tom, I presume there was a very good reason for installing such a > potentially > destabilizing patch a few days before the prerelease? In defence of my fellow maintainer: There was. We are now, for the first time ever, in a position where we can run a large nu

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Marcin Dalecki writes: > > On 2005-04-11, at 14:01, Andrew Haley wrote: > > > Nathan Sidwell writes: > >> Andrew Haley wrote: > >>> Nathan Sidwell writes: > >>>> Andrew Haley wrote: > >>>> > >>>>> Might

Re: GCC 4.0 RC1 Available

Eric Botcazou writes: > > which I see you've already committed a patch for, and a large number > > of Java failures. > > > > > > > > for 4.0.0-20050410. > > Same failure as on Solaris. > > Andrew, do you have a Darwin machine

Re: GCC 4.0 RC1 Available

Geoff Keating writes: > > On 12/04/2005, at 6:31 AM, Andrew Haley wrote: > > > Eric Botcazou writes: > >>> which I see you've already committed a patch for, and a large number > >>> of Java failures. > >>> > >&

Re: GCC 4.0 RC1 Available

Per Bothner writes: > Per Bothner wrote: > > However, the Kawa testsuite fails, raising a ClassNotFoundException. > > I'm looking into it. > > Hm. This fails, with or without the patch: >clas = Class.forName(cname); > This works: >clas = Class.forName(cname, true, getClass().getCl

Re: exceptions with longjmp (perhaps i am too stupid)

Georg Steffers writes: > Hi, > > i am working on a lib that should implement OO methods in C. I tried to > build up an exception system using longjmp and ran into a problem. I am > searching for an answer a month now and am actually not bit farther > than at the beginning. Actually i a

Re: GCC 4.0 RC1 Available

Andrew Haley writes: > Eric Botcazou writes: > > > which I see you've already committed a patch for, and a large number > > > of Java failures. > > > > > > <http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html> > > >

Re: GCC 4.0 RC1 Available

My Darwin build of 4.0 failed in libstdc++: ibsupc++convenience.a -lm -lm -lc -Wl,-single_module -Wl,-flat_namespace -install_name /Users/aph/gcc/install/lib/libstdc++.6.dylib -compatibility_version 7 -current_version 7.4 ld: .libs/mt_allocator.o malformed object, illegal reference for -dyna

Re: GCC 4.0 RC1 Available

Andrew Haley writes: > My Darwin build of 4.0 failed in libstdc++: > > ibsupc++convenience.a -lm -lm -lc -Wl,-single_module -Wl,-flat_namespace > -install_name /Users/aph/gcc/install/lib/libstdc++.6.dylib > -compatibility_version 7 -current_version 7.4 > ld: .l

Re: GCC 4.0 RC1 Available

Ranjit Mathew writes: > Geoffrey Keating wrote: > [...] > > which I see you've already committed a patch for, and a large number > > of Java failures. > > > > You can see full test results at > [...] > > > > > > > > for 4.0

Re: GCC 4.0 RC1 Available

Eric Botcazou writes: > > which I see you've already committed a patch for, and a large number > > of Java failures. > > > > > > > > for 4.0.0-20050410. > > Same failure as on Solaris. > > Andrew, do you have a Darwin machine

Re: struct __attribute((packed));

E. Weddington writes: > Paul Koning wrote: > > >>"E" == E Weddington <[EMAIL PROTECTED]> writes: > >> > >> > > > > > > E> typedef int packed_int __attribute__ ((aligned (1))); > > > >I'd rather the compiler got the work than the docs. > > > >Maybe it's better i

Re: GCC 4.0 RC1 Available

Geoffrey Keating writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > Ranjit Mathew writes: > > > Geoffrey Keating wrote: > > > [...] > > > > which I see you've already committed a patch for, and a large number > > >

Re: GCC 4.0 RC2 Available

ut. A field is marked as DECL_IGNORED_P, but dbxout_type_fields() still tries to access it. Andrew. 2005-04-19 Andrew Haley <[EMAIL PROTECTED]> * dbxout.c (dbxout_type_fields): Check DECL_IGNORED_P before looking at a field's bitpos. Index: dbxout.c =

Re: GCC 4.0 RC2 Available

Mark Mitchell writes: > Andrew Haley wrote: > > Geoffrey Keating writes: > > > Mark Mitchell <[EMAIL PROTECTED]> writes: > > > > > > > RC2 is available here: > > > > > > > > ftp://gcc.gnu.org/pub/gcc/pre

Re: GCC 4.0 RC2 Available

Andrew Haley writes: > Mark Mitchell writes: > > > > The C++ front-end (and probably the C front-end) strips > > zero-width (and possibly unnamed) bitfields after class layout. > > This can be justified in that those bitfields only affect > > layout; o

Re: GCC 4.0 RC2 Available

Tom Tromey writes: > >>>>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes: > > Andrew> At compile time we don't know the field offset of fields that we > Andrew> inherit, because it can change at runtime. So, we don't se

Java failures [Re: 75 GCC HEAD regressions, 0 new, with your patch on 2005-04-20T14:39:10Z.]

GCC regression checker writes: > With your recent patch, GCC HEAD has some regression test failures, > which used to pass. There are 0 new failures, and 75 > failures that existed before and after that patch; 0 failures > have been fixed. > > The old failures, which were not fixed or intro

Re: Java field offsets [was; GCC 4.0 RC2 Available]

Per Bothner writes: > Andrew Haley wrote: > > However, these fields are real, and they are used, but we shouldn't > > output any debug info for them. > > Does Dwarf support "computed field offsets"? (This might be needed > for Ada, to.) If so, the R

Re: Java failures [Re: 75 GCC HEAD regressions, 0 new, with your patch on 2005-04-20T14:39:10Z.]

James E Wilson writes: > Andrew Haley wrote: > >* postreload-gcse.c (hash_scan_set): Removve bogus assertion. > > I agree with Roger here, we need to add code to handle REG_EG_REGION > notes here instead of just dropping the gcc_assert call. See my 2 week > o

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre writes: > On 2005-04-26 13:15:43 -0700, Zack Weinberg wrote: > > The initializer thus tries to give a variable with type unsigned:8 > > a value that it cannot hold. The diagnostic is correct. > > However it is correct to store any integer to an unsigned variable, > even if th

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre writes: > On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote: > > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > > However it is correct to store any integer to an unsigned variable, > > > even if the original value cannot be represented. > > > > If that operation occurs at r

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre writes: > On 2005-04-27 11:37:51 +0100, Andrew Haley wrote: > > Warnings are to help the programmer see where there is some code that, > > although not necessarily an error, may require some attention. This > > is a classic case of such a warning. Thi

Re: GCC 4.1: Buildable on GHz machines only?

Paul Koning writes: > > "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes: > > >> However, I can always tell when a GCC build has hit the libjava > >> build -- that's when the *whole system* suddenly slows to a crawl. > >> Maybe it comes from doing some processing on 5000 foo.o file

Re: GCC 4.1: Buildable on GHz machines only?

Richard Earnshaw writes: > On Wed, 2005-04-27 at 21:55, Andrew Pinski wrote: > > > However, I can always tell when a GCC build has hit the libjava build > > > -- that's when the *whole system* suddenly slows to a crawl. Maybe > > > it comes from doing some processing on 5000 foo.o files all at

Re: GCC 4.1: Buildable on GHz machines only?

Andreas Schwab writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > If ld can't accept a list of files from a stream but is instead > > limited by command line length, then that *is* the fault of ld. > > You can always use a linker script. Yeah,

Re: GCC 4.1: Buildable on GHz machines only?

Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > If ld can't accept a list of files from a stream but is instead > > limited by command line length, then that *is* the fault of ld. > > GNU ld won't currently read a list of

Re: GCC 4.1: Buildable on GHz machines only?

Joe Buck writes: > On Wed, Apr 27, 2005 at 07:40:37PM -0600, Tom Tromey wrote: > > > "Paul" == Paul Koning <[EMAIL PROTECTED]> writes: > > > > Paul> Maybe. Then again, maybe there are real problems here. The ranlib > > Paul> one was already mentioned. And I wonder if libjava really nee

Re: 'make bootstrap' oprofile (13% on bash?)

Scott A Crosby writes: > On Thu, 28 Apr 2005 10:29:32 +0100, Andrew Haley <[EMAIL PROTECTED]> writes: > > > > -- and it wouldn't surprise me if the libjava build procedure were a > > > major contributor there. > > > > Yes. This is a profil

Re: GCC 4.1: Buildable on GHz machines only?

Ian Lance Taylor writes: > > And, yes, we clearly need to do something about the libjava build. OK, I know nothing about libtool so this might not be possible, but IMO the easiest way of making a dramatic difference is to cease to compile every file twice, once with PIC and once without. There

Re: 'make bootstrap' oprofile (13% on bash?)

Scott A Crosby writes: > On Fri, 29 Apr 2005 10:43:57 +0100, Andrew Haley <[EMAIL PROTECTED]> writes: > > > However, there is another major disparity here, in that on your box > > jc1 uses much more cpu than bash. I don't know why that might be. > > I

Re: GCC 4.1: Buildable on GHz machines only?

Andreas Schwab writes: > Ian Lance Taylor writes: > > > Andrew Haley <[EMAIL PROTECTED]> writes: > > > >> Ian Lance Taylor writes: > >> > > >> > And, yes, we clearly need to do something about the libjava build. > >

Re: GCC 4.1: Buildable on GHz machines only?

Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > >> OK, I know nothing about libtool so this might not be possible, but > > > >> IMO the easiest way of making a dramatic difference is to cease to > > > >>

Re: GCC 4.1: Buildable on GHz machines only?

Richard Henderson writes: > On Fri, Apr 29, 2005 at 01:30:13PM -0400, Ian Lance Taylor wrote: > > I don't know of a way to tell libtool to not do duplicate compiles. > > You can use -prefer-pic, but at least from looking at the script it > > will still compile twice, albeit with -fPIC both time

Re: GCC 4.1: Buildable on GHz machines only?

Matt Thomas writes: > Joe Buck wrote: > > I think you need to talk to the binutils people. It should be possible > > to make ar and ld more memory-efficient. > > Even though systems maybe demand paged, having super large > libraries that consume lots of address space can be a problem. >

Re: libjava build times

Richard Henderson writes: > > Now, unless I've done something drastically wrong, it appears as if we > are spending 2/3 of our time in the libtool script. Yes, that's right. That's similar to what my oprofile experiments suggest. Andrew.

Re: volatile semantics

Nathan Sidwell writes: > Dale Johannesen wrote: > > > And we don't have to document the behavior at all; it is not documented > > now. > I disagree. It's not documented explicitly in gcc now, because it is doing > what the std permits, and so documented there. We should document either >

Re: GCC 4.1: Buildable on GHz machines only?

Joe Buck writes: > On Tue, May 03, 2005 at 04:57:10PM -0300, Alexandre Oliva wrote: > > At this point, it doesn't feel like switching to 1.5.16 is worth the > > effort. 2.0 should be far more maintainable, and hopefully > > significantly more efficient on hosts where the use of shell functions

Re: gij problem (3.4.4)

Thorsten Glaser writes: > > > A quick look into CVSweb shows me _Jv_ClassReader::handleFieldsEnd () > is still the same as in 3.4.4. Does anyone have an idea where this > SIGSEGV could come from? No, but I do know that I would not even attempt to start looking at this with no debugging info

Re: GCC 4.1: Buildable on GHz machines only?

H. J. Lu writes: > On Wed, May 04, 2005 at 11:23:20AM +0100, Andrew Haley wrote: > > Joe Buck writes: > > > On Tue, May 03, 2005 at 04:57:10PM -0300, Alexandre Oliva wrote: > > > > At this point, it doesn't feel like switching to 1.5.16 is worth the >

Re: gij problem (3.4.4)

Thorsten Glaser writes: > Andrew Haley dixit: > > >No, but I do know that I would not even attempt to start looking at > >this with no debugging info in libgcj. libgcj builds by default with > >full debugging info, so something (someone) must have removed it. >

Re: gij problem (3.4.4)

Thorsten Glaser writes: > Andrew Haley dixit: > > >In which case it would be best to post a bug report at > >gcc.gnu.org/bugzilla and attach both source and class files. > > What for? I'm 99% sure nobody else has got the bug, since > most probably haven

Re: FORTH frontend?

Sam Lauber writes: > I am experimenting with the FORTH langauge, and I would like a > front-end to be added to GCC. I think I can get most of the parts > down, but how can I generate a tree that can be used in the > code-generator? There are a few diffciulties here, particularly with address

Re: GCC 4.1: Buildable on GHz machines only?

Per Bothner writes: > > We could also save time by making --disable-static the default. > Building static libraries is not very useful on other than > embedded-class systems. I strongly agree. Andrew.

Re: GCC 4.1: Buildable on GHz machines only?

Rutger Ovidius writes: > Thursday, May 5, 2005, 1:16:05 PM, you wrote: > > RH> On Thu, May 05, 2005 at 04:57:48PM -0300, Alexandre Oliva wrote: > >> The savings of creating static libraries would be small if we > >> refrained from building non-PIC object files. > > RH> But still largely us

Re: GCC 4.1: Buildable on GHz machines only?

Rutger Ovidius writes: > Friday, May 6, 2005, 1:33:32 AM, you wrote: > > AH> I don't think that anyone is proposing to drop static libraries on > AH> Win32. Win32 systems have their own requirements that make static > AH> libs preferable in some cases. On GNU systems, however, static libs

Re: GCC 4.1: Buildable on GHz machines only?

Rutger Ovidius writes: > Friday, May 6, 2005, 8:06:49 AM, you wrote: > > AH> But Java isn't compatible with static linking. Java is, by its very > AH> nature, a dynamic language, where classes invoke and even generate > AH> other classes on the fly. There is no way when linking to determine

Re: Auto-vectorization with gcj

Andrew Pinski writes: > > On May 15, 2005, at 10:33 AM, Andrew Pinski wrote: > > The multiple exit comes bounds checking (which VRP does not remove > > still > > because we don't pull out a load of the length). > > > > If we add -fno-bounds-checks, we get: > > Test.java:7: note: not vecto

Re: Sine and Cosine Accuracy

Scott Robert Ladd writes: > > The program used is below. I'm very open to suggestions about this > program, which is a subset of a larger accuracy benchmark I'm writing > (Subtilis). Try this: public class trial { static public void main (String[] argv) { System.out.println(Math.sin(

Re: Sine and Cosine Accuracy

Scott Robert Ladd writes: > Andrew Haley wrote: > > Try this: > > > > public class trial > > { > > static public void main (String[] argv) > > { > > System.out.println(Math.sin(Math.pow(2.0, 90.0))); > > } > > } > &

Re: Sine and Cosine Accuracy

Morten Welinder writes: > > But, you are using a number in the range of 2^90, only > > have 64 bits for storing the floating point representation, and > > some of that is needed for the exponent. > > 2^90 would require 91 bits for the base alone (as an integer > > value), plus a couple more fo

Re: Sine and Cosine Accuracy

chris jefferson writes: > Scott Robert Ladd wrote: > > >Marc Espie wrote: > > > > > >>Heck, I can plot trajectories on a sphere that do not follow great circles, > >>and that extend over 360 degrees in longitude. I don't see why I should be > >>restricted from doing that. > >> > >

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

Vincent Lefevre writes: > On 2005-05-30 16:12:07 -0400, Robert Dewar wrote: > > Haren Visavadia wrote: > > >--- Robert Dewar wrote: > > > > >I would expect the seem behaviour for both cases. > > > > why? You have some inaccurate model of computation, > > which in the absence of switches,

Re: Sine and Cosine Accuracy

Scott Robert Ladd writes: > chris jefferson wrote: > > I would like to say yes, I disagree that this should be true. By your > > argument, why isn't sin(pow(2.0,90.0)+1) == sin(6.153104..)? Also, how > > the heck do you intend to actually calculate that value? You can't just > > keep subtracti

Re: x86 Q: why aren't the SSE intrinsics always_inline?

Stuart Hastings writes: > Subject says it all. > > IIUC, the SSE intrinsics are made available as functions because > that's the least-broken way to support them in a target-agnostic > compiler. They're clearly intended to be fully inlined in normal > usage. And they're marked "inlin

Re: How to replace -O1 with corresponding -f's?

Sergei Organov writes: > Hi, > > Using gcc compiled from gcc-4_0-branch, in an attempt to see which > particular optimization option makes my test case to be mis-optimized, I > try to replace -O1 (which toggles on the problem) with corresponding set > of -fxxx optimization options. In gener

Re: signed is undefined and has been since 1992 (in GCC)

Olivier Galibert writes: > On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote: > > Original Message > > >From: Olivier Galibert > > >Sent: 28 June 2005 15:25 > > > > > In particular, a very large number of C and C++ programs are written > > > with the assumptions: > > > >

Re: sizeof() function parameter array: known problem?

Etienne Lorrain writes: > The result of this funtion is 1, is there a C lawyer around? > > $ cat tmp.c > unsigned fct (unsigned array[10]) > { > return sizeof(array) / sizeof(array[0]); > } This is 6.7.5.3, Para. 7. Andrew.

Re: Double checked locking and GCJ?

Hans Boehm writes: > > On Tue, 28 Jun 2005, Andrew Haley wrote: > > > Martin Egholm Nielsen writes: > > > Hi there, > > > > > > Sorry for bringing up what may be the most tedious thread ever. But does > > > "double checked locki

Re: matching '-Wl,' in a specs file

Gunther Nikl writes: > On Fri, Jul 01, 2005 at 03:19:28PM -0700, James E Wilson wrote: > > Gunther Nikl wrote: > > >A few LINK_SPEC definitions contain a "%{Wl,*:%*}" sequence. > > > > There is no need to match -Wl options in LINK_SPEC, as it is handled by > > the gcc.c driver. The driver

Re: Offset and Bit Mask for Bit Fields?

Dimitry Golubovsky writes: > > If one wants to automatically determine offset of a regular field in a > C structure, one uses `offsetof' > > According to the documentation, > > == > This macro (offsetof) won't work if member is a bit field; you get an > error from the C com

Re: Some notes on the Wiki

Steven Bosscher writes: > On Monday 11 July 2005 16:50, Bernd Schmidt wrote: > > Steven Bosscher wrote: > > > I guess that, apart from the legal discussion of whether this enough, > > > such a statement would not apply to existing content. It was certainly > > > not my intention to sign over

Re: volatile semantics

D. Hugh Redelmeier writes: > start of Henry Spencer's comment > > There is little room for compiler writers to maneuver here, unless they > have announced their intentions in advance in their documentation. > Reading C99 carefully: > > ... > > 6.3.2.1: when an object

Re: volatile semantics

Gabriel Dos Reis writes: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > | > | There is no point in type qualifiers if they can be simply changed at > | > | will. Do not lie about your objects, and you will not be screwed over. > | > > | > only if the language you're implementing the compi

Re: Large, modular C++ application performance ...

Giovanni Bajo writes: > michael meeks <[EMAIL PROTECTED]> wrote: > > > I've been doing a little thinking about how to improve OO.o startup > > performance recently; and - well, relocation processing happens to be > > the single, biggest thing that most tools flag. > > > > Anyhow - so I wrot

Re: Ada character types : tree code and DW_AT_encoding

Tom Tromey writes: > > "Jim" == James E Wilson <[EMAIL PROTECTED]> writes: > > Jim> Java uses CHAR_TYPE. So Ada would not be the only supported language > Jim> using it if you switched to it. > > I was under the impression that CHAR_TYPE was deprecated, so I > purposely avoided it in

Re: Question regarding compiling a toolchain for a Broadcom SB1

Ian Lance Taylor writes: > Jonathan Day <[EMAIL PROTECTED]> writes: > > > My question is simple enough - has anyone built a > > toolchain for a MIPS64-Linux-GNU target? > > Yes, I did, last year. > > But I did it through a tedious iterative process--build the binutils, > build the compi

uncaught exception in g++ 3.4 and 4.0

There's a thread at http://groups.google.co.uk/group/gnu.gcc.help/tree/browse_frm/thread/e85dce7d69fb7dc1 which looks odd. It seems that the exception filter is not being correctly processed. I can't find a Bugzilla entry for this. Is it really a bug? Andrew. quoted message ---

<    1   2   3   4   5   6   7   8   9   10   >