On 05/17/2010 09:15 PM, Sandeep Soni wrote:
> Hi,
>
> As part of GSoC 2010, I am developing a front end for GIMPLE.
> You can find the basic theme of the project at:
> http://gcc.gnu.org/wiki/GimpleFrontEnd
>
> One of the most important components in this GIMPLE Front End is to
> convert the GIMP
On 05/18/2010 04:24 AM, Sandeep Soni wrote:
> On Tue, May 18, 2010 at 2:34 AM, Andrew Haley wrote:
>
>>>For example:
>>>A textual GIMPLE tuple for the statement a=b+c can be like
>>>> (As demonstrated by the internal
>>> manual also).
On 05/18/2010 04:05 PM, Dave Korn wrote:
> On 18/05/2010 15:17, Steven Bosscher wrote:
>
>> IMHO, ideally we would have a syntax that is human readable and human
>> writable. S-expressions are not as easy to read for me as something
>> that resembles C.
>
> I'd like it that way too, but I ackno
On 06/02/2010 09:19 PM, DJ Delorie wrote:
>
> Robert Dewar writes:
>> I would create a specific committee to reccommend a C++ coding
>> standard (preferably based on one of the standard ones available, such
>> as Google).
>
> Doing things in secret like that is not the Open Source Way.
No, havi
On 06/03/2010 12:09 PM, Richard Guenther wrote:
> On Thu, Jun 3, 2010 at 12:51 PM, Robert Dewar wrote:
>> Steven Bosscher wrote:
>>
>>> Indeed. It is, well, perhaps not surprising, but quite annoying (to me
>>> at least) that a possible move to C++ as implementation language of
>>> GCC is so much
On 06/03/2010 09:47 PM, Robert Dewar wrote:
> Andrew Haley wrote:
>
>> Right, but I didn't think there was any plan to convert en masse to
>> C++ -- just to allow people to use it where appropriate. Apart from
>> anything else, there's always a nonzero pro
On 06/29/2010 06:53 AM, Kevin Bowling wrote:
> In the GCC 4.5 announcement:
>
> "Support for the classic POWER architecture implemented in the
> original RIOS and RIOS2 processors of the old IBM RS/6000 product line
> has been obsoleted in the rs6000 port. This does not affect the new
> generation
On 08/21/2010 10:43 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>> Sometime I have to do
>>
>> int x = 0;
>>
>> to silence gcc from uninitialized warnings when I know it is
>> unnecessary.
>
> I guess the official idiom is
>
> int x = x;
>
> and it is somewhat used in the GNU project although i
[ Redirect to gcc. This is a dev issue. ]
On 08/27/2010 10:39 PM, Tom Browder wrote:
>> On Fri, Aug 27, 2010 at 09:17, Andrew Haley wrote:
>>> However, just running download_prerequisites is, IMVHO, the only sane way
>>> to do it.
>
> That's the solution I u
On 08/30/2010 03:50 PM, Vincent Lefevre wrote:
> On 2010-08-30 14:46:57 +0200, Michael Matz wrote:
>> int x = x;
>>
>> is the way GCC offers this idiom since about forever, no need for an
>> attribute. Downthread I see that people worry about this generating an
>> actual (uninitialized) access t
On 09/06/2010 06:18 PM, NightStrike wrote:
> On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
> wrote:
>> On Mon, Sep 6, 2010 at 6:19 PM, NightStrike wrote:
>>> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther wrote:
On Mon, 6 Sep 2010, Tobias Burnus wrote:
> Gerald Pfeifer wrote:
On 09/07/2010 02:12 PM, Joel wrote:
> Hello,
> Apparently, at least for MIPS target, GCC generates labels starting
> from 2: $L2, $L3, etc.
> Do you know why the numbering begins at 2?
When I saw this question before, I thought that it'd be easy to find
out by debugging gcc. However, I also thoug
On 09/10/2010 11:50 PM, Steven Bosscher wrote:
> There is just one front-end file left that still has to #undef
> IN_GCC_FRONTEND, allowing the front end to include RTL headers. The
> one remaining file is java/builtins.c.
>
> In java/builtins.c there are (what appear to be) functions that
> gene
On 11/09/10 20:28, Steven Bosscher wrote:
> On Sat, Sep 11, 2010 at 8:48 PM, Andrew Haley wrote:
>> On 09/10/2010 11:50 PM, Steven Bosscher wrote:
>>
>>> There is just one front-end file left that still has to #undef
>>> IN_GCC_FRONTEND, allowing the front end to
On 11/09/10 21:21, Joseph S. Myers wrote:
> On Sat, 11 Sep 2010, Andrew Haley wrote:
>
>> The test tells us whether the back-end has atomic builtins. If it doesn't
>> then we generate calls to the libgcj back end. I really don't want gcj
>> to generate calls t
On 09/27/2010 01:23 AM, Jay K wrote:
>
> Hi. You know, gmp/mpfr/mpc are a significant
> portion of building any frontend/backend.
I disagree. Most of the time I don't notice them.
> The result is a lot faster to build, if you are just doing a just
> a single stage build of a compiler.
Sure, bu
On 09/27/2010 10:36 AM, Luke A. Guest wrote:
> On Mon, 2010-09-27 at 11:12 +0200, Olivier Hainque wrote:
>> Hello Luke,
>>
>> Luke A. Guest wrote:
>>> I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM.
>>
>> Thanks :-)
>
> Well, I'm reading as much as I can regarding this, but
On 09/28/2010 11:09 AM, Kai Tietz wrote:
> ChangeLog
>
> 2010-09-28 Kai Tietz
>
> * config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output
> addition zero for padding of secrel32 requested for 8 bytes.
>
> I will apply this today, if there aren't any objections.
Please do
On 09/28/2010 01:51 AM, Dave Korn wrote:
>
> Huh, am I doing something seriously wrong? It takes me four hours to
> boostrap GCC at with all languages enabled at -j8 on an AMD2x64
You must be. I just bootstrapped with c, c++, and java, and it was
real40m36.704s
user164m5.664s
sys
On 09/28/2010 12:35 PM, Dave Korn wrote:
> On 28/09/2010 11:44, Andrew Haley wrote:
>> On 09/28/2010 01:51 AM, Dave Korn wrote:
>>
>>> Huh, am I doing something seriously wrong? It takes me four hours to
>>> boostrap GCC at with all languages enabled at -j8 on
On 09/29/2010 08:07 AM, #SINHA SHARAD# wrote:
> Hi,
>
> I had a big piece of code that ran smoothly on gcc 3.2.2. For
> some reason, I had to start using that code on a machine with GCC
> 4.2.1. Now, it would throw segmentation faults (invalid free pointer
> etc) and abort the program. I pres
On 10/31/2010 07:09 PM, Ian Lance Taylor wrote:
> This patch should not of course change whether or not distros choose to
> package the Java compiler; undoubtedly they would continue to do so,
> just as they package the Ada compiler today.
>
> Comments? Approvals?
I see your point, but this wil
On 11/01/2010 04:06 AM, Geert Bosch wrote:
>
> On Oct 31, 2010, at 15:33, Steven Bosscher wrote:
>> The argument against disabling java as a default language always was
>> that there should be at least one default language that requires
>> non-call exceptions. I recall testing many patches without
On 11/01/2010 05:50 PM, Tom Tromey wrote:
>> "Steven" == Steven Bosscher writes:
>
> Steven> The argument against disabling java as a default language always was
> Steven> that there should be at least one default language that requires
> Steven> non-call exceptions. I recall testing many pat
On 11/01/2010 06:16 PM, Diego Novillo wrote:
> On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor wrote:
>
>> Comments? Approvals?
>
> FWIW, I agree with this patch for the same reasons stated by Ian.
> Other than massively increasing build times, I have not seen
> substantial benefits for having
On 11/02/2010 10:48 AM, Paolo Bonzini wrote:
> On 11/01/2010 11:47 AM, Joern Rennecke wrote:
>> Quoting Geert Bosch :
>>
>>> On Nov 1, 2010, at 00:30, Joern Rennecke wrote:
But to get that coverage, testers will need to have gnat installed.
Will that become a requirement for middle-end pa
On 11/03/2010 04:49 PM, Bingfeng Mei wrote:
> Hello,
> I came across an issue with function "optimize" attribute. The code is like:
> __attribute__((optimize("-fno-strict-aliasing")))
> void foo()
> {
>...
> }
>
> When compiling with -O2, we expect this function is compiled without following
>
On 11/03/2010 08:44 PM, Richard Guenther wrote:
> On Wed, Nov 3, 2010 at 6:12 PM, Andrew Haley wrote:
>> On 11/03/2010 04:49 PM, Bingfeng Mei wrote:
>>> Hello,
>>> I came across an issue with function "optimize" attribute. The code is like:
>>>
On 11/08/2010 11:13 PM, Walter Bright wrote:
>
>
> Joseph S. Myers wrote:
>> On Mon, 8 Nov 2010, Walter Bright wrote:
>>
>>
>>> Who do I need to talk to in order to resolve the various licensing
>>> issues so
>>> this becomes possible?
>>>
>>
>> The FSF, via the Steering Committee, via thi
On 11/18/2010 09:23 AM, Mark Mitchell wrote:
> On 11/11/2010 3:20 PM, Ian Lance Taylor wrote:
>> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor wrote:
>>> Currently we build the Java frontend and libjava by default. At the GCC
>>> Summit we raised the question of whether should turn this off,
On 11/25/2010 11:25 PM, Uros Bizjak wrote:
> /home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:
> In class 'gnu.java.awt.peer.gtk.GtkComponentPeer':
> /home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:
> In method
> 'gnu.ja
On 11/26/2010 11:12 PM, Uros Bizjak wrote:
> Hello!
>
>>> /home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:
>>> In class 'gnu.java.awt.peer.gtk.GtkComponentPeer':
>>> /home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:
>>> I
On 01/04/2011 12:49 PM, Klaus Rudolph wrote:
Is my code wrong
Yes. You need to define A::x.
Add this line:
const int A::x;
If the code is wrong, I expect a compiler error not a linker message!
No, because A::x might be defined in another translation unit.
Andrew.
On 01/06/2011 07:07 PM, Gerald Pfeifer wrote:
I am trying to debug this, alas not very successfully so far and am
looking for a pointer or two.
This happens with head as well; binutils (/usr/local/bin/ld) is 2.20.1.
Note 1: This can be avoid configuring with --disable-rpath. GCC
understands -
On 01/06/2011 09:28 PM, Gerald Pfeifer wrote:
On Thu, 6 Jan 2011, Ralf Wildenhues wrote:
Could be libtool issue or lib-link.m4 one (or gcj one). Can you send
./libtool --tag=GCJ --config
output?
I assume you mean from libjava in the build tree? Attached.
(Note this is now x86_64-portbld-
On 01/10/2011 06:40 PM, Ralf Wildenhues wrote:
* Andrew Haley wrote on Fri, Jan 07, 2011 at 10:24:53AM CET:
On 01/06/2011 09:28 PM, Gerald Pfeifer wrote:
On Thu, 6 Jan 2011, Ralf Wildenhues wrote:
Does passing '-Wl,-rpath -Wl,/foo' to gcj work for a small example
program for you?
Ranjit Mathew writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Bryce McKinlay wrote:
> > This patch merges the GC 6.6 sources into the libgcj trunk. Two patches
> [...]
>
> This little bit in "boehm-gc/include/private/gcconfig.h" (line 306):
> - - 8<
Tom Tromey writes:
> Historically we've wanted to have a 'native' java-source-code-reading
> compiler, that is, one which parses java sources and converts them
> directly to trees. From what I can remember this was based on 3
> things:
>
> * In the past the compiler handled loops built wit
Tom Tromey writes:
> >>>>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Andrew> In particular, the type system and the rules for exception
> Andrew> regions are different. Also, a "slot" in the .class format
> Andr
Tom Tromey writes:
> > "Thorsten" == Thorsten Glaser <[EMAIL PROTECTED]> writes:
>
> >> ecj is written in java. This will complicate the bootstrap process.
>
> Thorsten> Why not keep enough support in jc1 to bootstrap ecj?
>
> We don't know how much of the language that would be.
An
Andreas Krebbel writes:
>
> > struct foo { int n; };
> > extern unsigned long c = 0;
> >
> > {
> > int b;
> >
> > b = 2;
> > ((struct foo*)(&b + c))->n = 3;
> > }
>
> For having a true dependency the example should look like this:
>
> struct foo { int n; };
> extern unsign
Rui Wang writes:
> >> --enable-java-awt=gtk,xlib --without-x
> >
> >You said without X but included the gtk and the xlib peers.
> >What do you think that should mean?
> >
> Thank you for the quick reply, would you mind to explain a bit more
> on how these two related with each other?
>
Nicolas DICHTEL writes:
> Hi all,
>
> here is the result on ARM of my little program:
>
> [EMAIL PROTECTED]:/usr/admin# ./test2
> 4 5 6 8
> 2 3 4 6
>
>
> Is it normal to add an attribute __packed__ on each union{}
> contained in a structure, or is it a bug of my compiler ?
> On X86,
When building a-textio in libada, today's gcc build fails when memory
is exhausted.
Seems like VRP is looping, consuming more and more memory.
Andrew.
make[7]: `a-teioed.o' is up to date.
/home/aph/gcc/build-x86_64-unknown-linux-gnu/./gcc/xgcc
-B/home/aph/gcc/build-x86_64-unknown-linux-gnu/./
Andrew Pinski writes:
>
> On Feb 19, 2006, at 12:09 PM, Andrew Haley wrote:
>
> > When building a-textio in libada, today's gcc build fails when memory
> > is exhausted.
>
> This has already been reported as PR 26348 and it looks like a bug
> in t
Laurent GUERBY writes:
> On Fri, 2006-02-17 at 22:43 +, Joern RENNECKE wrote:
> > Has anybody done timings for gcc bootstrap / cross builds and regtests
> > with modern multi-core processors? I wonder what a sensible modern
> > configuration would be for gcc development, but the the mult
Joern RENNECKE writes:
> Andrew Haley wrote:
>
> >
> >As a comparison point, I get
> >
> >real73m39.275s
> >user113m19.549s
> >sys 15m26.010s
> >
> >for the bootstrap: that's 1h14 elapsed time. That's on a &qu
Joern RENNECKE writes:
> Andrew Haley wrote:
>
> > > Is that using the i686 or amd64 instruction set? If the latter, does it
> > > use 32 or 64 bit pointers?
> >
> >The latter. Yes.
> >
> >
> So which pointer size does the host
Andrew Pinski writes:
> >
> > In libjava/classpath there are two .cvsignore files which haven't been
> > deleted yet:
> >
> > native/jni/midi-alsa/.cvsignore
> > native/jni/midi-dssi/.cvsignore
> >
> > Should they go, too?
> > They are also in GCC 4.1.0 RC1.
>
> They are imported
Inder writes:
> Hi All
>
> I am trying to compile 'test.cc' (code attached) with the gcc 4.0.1
> it gives me the following error:
>
> test.cc:19: error: array bound is not an integer constant
>
> so it is not able to evaluate the conditional expression in gcc 4.0.1,
> while this is bein
Jerome Robert writes:
> Is this program wrong
Yes.
See ISO C9899:199 Section 6.3.2.3.
These lines are particularly bogus:
void ** aa=(void **)(void *)&a;
void ** ab=(void **)(void *)&b;
All the cast to (void *) does is suppress a useful warning.
-fno-strict-aliasing may help.
And
Digvijoy Chatterjee writes:
>
> On Thu, 2006-02-23 at 13:54 +0100, Richard Guenther wrote:
> > > This runs successfully with:
> > > g++ without any optimization ,
> > > but with -O or -02 or -03 the executable just hangs forever
> >
> > See PR323 - this is expected behavior.
> >
> > R
Andrew Pinski writes:
> With clean sources on x86_64-linux-gnu, I am getting almost all tests
> for running gij to fail. Does anyone know what is going on here?
I'll have a try now.
Andrew.
Andrew Haley writes:
> Andrew Pinski writes:
> > With clean sources on x86_64-linux-gnu, I am getting almost all tests
> > for running gij to fail. Does anyone know what is going on here?
>
> I'll have a try now.
You are right. The error is
lt-gij: reloca
H. J. Lu writes:
> On Wed, Mar 01, 2006 at 11:48:39AM +0000, Andrew Haley wrote:
> > Andrew Haley writes:
> > > Andrew Pinski writes:
> > > > With clean sources on x86_64-linux-gnu, I am getting almost all
> > tests
> > > > for running
H. J. Lu writes:
> On Wed, Mar 01, 2006 at 02:11:21PM +0000, Andrew Haley wrote:
> > H. J. Lu writes:
> > >
> > > The fix was posted at
> > >
> > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html
> >
> > If it still w
H. J. Lu writes:
> On Wed, Mar 01, 2006 at 03:19:18PM +0000, Andrew Haley wrote:
> > H. J. Lu writes:
> > > On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> > > > H. J. Lu writes:
> > > > >
> > > > > The fix wa
Our config tools return "x86_64" as an arch. Like this:
[EMAIL PROTECTED] ~]$ gcc/trunk/config.guess
x86_64-unknown-linux-gnu
But try it with gcc, and
[EMAIL PROTECTED] ~]$ gcc -S add-entropy.c -march=x86_64
add-entropy.c:1: error: bad value (x86_64) for -march= switch
add-entropy.c:1: error:
Andrew Haley writes:
>
> So, which is it supposed to be? In general we use "x86_64"
> everywhere, but gcc seems to have decided to use "x86-64". Perhaps we
> should accept "x86_64" as well?
Another example:
[EMAIL PROTECTED] ~]$ arch
x86_64
Confused.
Joe Buck writes:
> On Tue, Mar 07, 2006 at 10:26:24AM +0000, Andrew Haley wrote:
> > Our config tools return "x86_64" as an arch. Like this:
>
> They cannot return "x86-64", because that would break target triplets
> (which use "-" as a
Paolo Bonzini writes:
>
> > target-zlib: should be sufficient to add i386-darwin to the supported
> > platforms
>
> zlib is being skipped only because libjava is.
>
> > target-boehm-gc: a patch exists for porting to the new platform, so it
> > should be a matter of applying it
>
> W
Sandro Tolaini writes:
>
> On 10/mar/2006, at 20:42, Tom Tromey wrote:
>
> > libffi and mudflap were covered by Paolo and Andrew.
>
> I have done some work on sysv.S and now libffi compiles fine on OSX/
> Intel. Unfortunately, I had to put some #ifdef __APPLE__ this file
> because App
This is all binutils specific, nothing to do with gcc as such. Please
re-post your queries to the binutils list.
Andrew.
Torsten Rohlfing writes:
> Greetings.
>
> I am experiencing a major performance problem with the log() function on
> the x86_64 platform. It can be illustrated with the following little
> test program:
>
> testlog.cxx===
> #include
>
> main()
> {
> float f = 0;
>
Torsten Rohlfing writes:
> Andrew Haley wrote:
>
> > > When I run the two binaries on the exact same box and time them, I get
> > > the following outputs:
> > >
> > > time ./testlog64
> > > 13.264u 0.000s 0:13.26 100.0% 0+0k 0+0io 0
Richard Guenther writes:
> On 3/21/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > Take the following C code:
> > typedef long atype[];
> > typedef long atype1[];
> >
> > int NumSift (atype *a, atype1 *a1)
> > {
> >(*a)[0] = 0;
> >(*a1)[0] = 1;
> >return (*a)[0];
> > }
> >
Camm Maguire writes:
> Greetings! GCL is a lisp compiler system which outputs C code normally
> compiled by gcc into an object, which is then loaded and relocated
> into the running GCL image. In lisp, compiling is a very incremental
> process, with many, often thousands of small functions com
Sandro Tolaini writes:
> Finally, I managed to fix up libffi and run testing on libjava under
> Darwin/i386.
>
> The failures are due to the missing signal unwinding code (something
> that is out of my reach at the moment, so we must live with it at the
> moment unless someone is willi
Adriaan van Os writes:
> Steven Bosscher wrote:
>
> > Adriaan van Os <[EMAIL PROTECTED]> wrote:
> >> The
> >> answer is that simply the resources fail to maintain gpc on a daily
> >> basis on gcc mainline.
> >
> > It seems to me that integrating gpc would _reduce_ the burden on the
> > gp
Jeffrey A Law writes:
> On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
>
> > On irc today we were discussing handling 'this' in gcj. We can add an
> > attribute to the argument to mark it as non-null... but strangely
> > there doesn't seem to be a way to mark other local variables as
Jeffrey A Law writes:
> On Thu, 2006-03-30 at 18:39 +0100, Andrew Haley wrote:
> > Jeffrey A Law writes:
> > > On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
> > >
> > > > On irc today we were discussing handling 'this' in gcj. We
Adriaan van Os writes:
> Steven Bosscher wrote:
>
> > Ed Smith-Rowland <[EMAIL PROTECTED]> wrote:
> >> All,
> >>
> >> FWIW, I would like to add my support for creating a branch for gpc
> >> with
> >> the eventual goal
> >> of integrating Pascal into mainline.
> >
> > While I agree with
testcase missing?
There's one in mauve. I added this to the libgcj testsuite.
The libgcj testsuite isn't a complete test of the Java language, and I
don't think gcc developers would thank us if we made it one!
Andrew.
2006-04-03 Andrew Haley <[EMAIL PROTECTED]>
Ashwin writes:
> I have a combiner pattern that converts a sub-cmp pattern to a cmp insn,
> something like this -
> "if (a-1 < 0)"
> is converted to
> "if (a<1)"
>
> Now consider the following test case -
>
>
> f(long a){return (--a > 0);}
> main(){if(f(0x8000L)==0)abort();exit(0
Rémy Saissy writes:
> > It would take a massive target-specific backend hack to make that
> > happen, as GCC > currently only supports flat address spaces. ;-)
>
> I don't understand why.
> gcc currently consider every data access on i386 to be %ds:offset or
> %ss:offset
> depending on th
Daniel Bratell writes:
> This is likely to be the one FAQ you've all learned to answer but
> as I was bitten by it, I just wanted to make sure that what I saw
> was expected.
>
> I've used -ffast-math for a slight speedup of floating point
> arithmetics, but I've also used doubles to store
Roger Sayle writes:
>
> Increasingly, there have been examples of patches getting checked-in
> without maintainer approval, or without posting to gcc-patches, etc...
Are you absolutely sure that's true? i.e., do you believe that these
days there is a greater _proportion_ of unapproved patches
Converting a vector of floats (via a cast) to a vector of ints of the
same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
converted. This is different from a cast from scalar float to int,
where a conversion is performed.
>From what I can see of the source, this is deliberate.
Paolo Bonzini writes:
> Andrew Haley wrote:
> > Converting a vector of floats (via a cast) to a vector of ints of the
> > same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> > converted. This is different from a cast from scalar float to int,
>
Paolo Bonzini writes:
>
> > > The short answer is that AltiVec dictated this behavior. :-( Longer
> > > answers were given by Ian and Paul, and I agree with them.
> >
> > OK, so: firstly, is this behaviour actually documented anywhere? In
> > AltiVec docs, maybe?
> >
> http://publi
Janis Johnson writes:
> On Wed, Apr 19, 2006 at 05:30:54PM +0200, Paolo Bonzini wrote:
> >
> > The C spec for Altivec (not the ISA) is a horrible spec that set a
> > horrible de facto standard. To some extent, gcc already departed from
> > Altivec, for example by disallowing the (vector in
Thibaud GUERIN writes:
> hi,
> I'm actually writing a program in C and i'm fighting with an address
> dereferencing since some days now.
>
> intthe_bug(const char *fmt, ...)
> {
> char**ap;
> char**s = (char **)(&fmt);
>
> /* __asm__ volatile ( */
> /*
YH writes:
>
> Is the following example legal in current GCC compilation for C
> program? I thought the static array allocation can only used by a
> defined constant such as char buf[MAX_SIZE], where #define MAX_SIZE 10?
>
> void DoSomthing(int size)
> {
>char buf[size];
>
Rene Rebe writes:
> Hi,
>
> not such an high priority, but testing the latest gcc 4.1.0 in
> "whole system builds" I stumble over:
>
> jackd: error while loading shared libraries: /usr/lib64/libjack.so.0:
> R_PPC64_ADDR32 4056b70 for symbol `' out of range
>
> There only R_PPC64_AD
Rene Rebe writes:
> On Tuesday 25 April 2006 14:21, Andrew Haley wrote:
> > Rene Rebe writes:
> > > Hi,
> > >
> > > not such an high priority, but testing the latest gcc 4.1.0 in
> > > "whole system builds" I stumble over:
> >
Jack Howarth writes:
> What on earth would make you think that the linker on Darwin
> would reject non-PIC code in linking a shared library. The linker
> on Linux doesn't do any such thing (hence the discussion on the
> Debian mailing list of adopting this as check on their builds).
x86 i
Daniel Jacobowitz writes:
> On Tue, May 02, 2006 at 07:21:24PM -0700, Mike Stump wrote:
> > >Otherwise, would it be possible to generate the DWARF Tables and
> > >add those tables dynamically to the running program?
> >
> > Yes (could require OS changes).
> >
> > >Under windows, Microsof
Jakub Jelinek writes:
> On Wed, May 03, 2006 at 10:14:23AM +0100, Andrew Haley wrote:
> > Adding an entry point to register debug info should not be a big deal.
> > We're going to need it for gcj when we add a JIT.
> >
> > Another interesting possibilit
Andrew Haley writes:
> Jakub Jelinek writes:
> > On Wed, May 03, 2006 at 10:14:23AM +0100, Andrew Haley wrote:
> > > Adding an entry point to register debug info should not be a big deal.
> > > We're going to need it for gcj when we add a JIT.
>
Richard Henderson writes:
> On Tue, May 02, 2006 at 01:23:56PM +0200, jacob navia wrote:
> > Is there an equivalent API for linux?
>
> __register_frame_info_bases / __deregister_frame_info_bases.
Are these an exported API?
I metioned the existence of these entry points in a reply to Jacob
jacob navia writes:
> Andrew Haley a écrit :
>
> >Richard Henderson writes:
> > > On Tue, May 02, 2006 at 01:23:56PM +0200, jacob navia wrote:
> > > > Is there an equivalent API for linux?
> > >
> > > __register_frame_info_bases / _
Art Haas writes:
>
> The output above was on my Debian machine; the Fedora machine (Rawhide)
> fails in a similiar manner, and likewise bootstrap succeeds if the
> initial compiler is the system compiler and not my most recent GCC
> build.
>
> Anyone else seeing this problem?
Yes. Exac
Recently (I can't tell when this changed, exactly, but it's within the
last few weeks) I've been unable to compile a big Java program because
my computer runs out of memory. gcj version 4.1 compiles this program
correctly, although it uses about a gigabyte of RAM. gcj version 4.2
can't do it even
With recent gcc we're blowing up in unshare because the use of
COMPOUND_EXPRs in Java leads to very deep recursion.
The easisest thing seems to be to use a STATEMENT_LIST rather than a
COMPOUND_EXPR.
Andrew.
2006-05-24 Andrew Haley <[EMAIL PROTECTED]>
* decl.c (java_add
mmitchel at gcc dot gnu dot org writes:
>
>
> --- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-04 19:02
> ---
> Java is not release critical.
I protest. This is not a Java bug but an exception handling bug.
The simple fact that the test case for this bug is written
the bit in this way isn't very nice, but it
is fast and backward compatible.
Bootstrapped x86_64.
Andrew.
2006-06-08 Andrew Haley <[EMAIL PROTECTED]>
* expr.c (build_field_ref): Pass NULL_TREE as SPECIAL arg to
get_symbol_table_index().
(maybe_rewrite_invoc
Andrew Pinski writes:
>
> On Jun 10, 2006, at 9:03 AM, Jack Howarth wrote:
>
> > Andrew,
> > What is the release branch called? I can't get anything pulled
> > down with...
>
> There is no release branch but the release branch rules are in effect
> on the mainline (trunk).
>
[EMAIL PROTECTED] writes:
> I want a reduced test case for this problem for bugzilla, but don't
> really know the exact cause. I _think_ code is being improperly
> optimized away, but I don't know. This function is part of a
> BigInteger library, and works perfectly upto and including -O2, but
[EMAIL PROTECTED] writes:
> On Mon, Jun 12, 2006 at 12:32:36PM +0100, Andrew Haley wrote:
> > [EMAIL PROTECTED] writes:
> > > I want a reduced test case for this problem for bugzilla, but don't
> > > really know the exact cause. I _think_ code is being improp
[EMAIL PROTECTED] writes:
> On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> >
> > I'm starting to be a little suspicious about host2little(). I wonder
> > if that's well-defined.
> >
> > I'm just guessing he
601 - 700 of 1072 matches
Mail list logo
