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]: Leavin
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 arc
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 '$' chraca
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
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 la
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 no
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
> > > actual
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
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.
[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 min
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
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.
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
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 -fstr
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).
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
[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 t
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 ?? ()
>
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
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, probabl
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 %
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 tha
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 t
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.
>
#x27;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&
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 rath
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.
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 =
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.
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, tha
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:
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 c
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
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 t
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'
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)
>
>
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] a
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
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
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 n
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 so
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();/* C
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())"
> > &
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
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
Sergei Organov writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Sergei Organov writes:
> > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > Sergei Organov <[EMAIL PROTECTED]> writes:
> > > >
> > > int
Sergei Organov writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Sergei Organov writes:
> > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > >
> > > > Sergei Organov writes:
> > > > > Ian Lance Taylor <[E
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 compatibl
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'
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.
I
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.
> >
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
> t
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
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.
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 rem
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) implemen
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 o
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
> | > > overf
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
&
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 sta
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_DA
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
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 wit
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
> >
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 tha
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.
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
&
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
> | > |
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
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 diff
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
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
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
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 a
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 w
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.
Ind
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 li
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 buil
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
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
> 0maxres
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
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 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 eve
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
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
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.
> >
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.
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
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.
> >
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.
... 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.
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 to
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
> >
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:
> > > >
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
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
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 pr
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.
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
> > >pres
1 - 100 of 1072 matches
Mail list logo
