Patrick Olinet writes:
> Hi there,
>
> I'm running an embedded platform based on a powerpc 405EP CPU and a
> gcc 4.1.0 cross-toolchain. My initial problem was that gcj compiled
> binaries crash at runtime when interpreting java bytecode ("Illegal
> instruction" message).
>
> After many in
J.C. Pizarro writes:
> there are any news from JavaOne?
Yes, there is.
You are *way* off-topic. Please desist from spamming this list with
questions about non-GNU code. Go to http://openjdk.java.net/ and
pester them instead.
Andrew.
Geert Bosch writes:
>
> On May 11, 2007, at 08:26, Rahul wrote:
> > But for the following example
> > int a = 1;
> > int b = 2;
> > int c = 3;
> > c = c + a * b;
> > the MAC pattern is not getting recognized, instead it is still using
> > PLUS and MULT patterns.
>
> In general, thi
[top-posting fixed]
Patrick Olinet writes:
> On 5/8/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> > Patrick Olinet writes:
> > > Hi there,
> > >
> > > I'm running an embedded platform based on a powerpc 405EP CPU and a
> > > gc
Patrick Olinet writes:
> > > I've compiled again my cross toolchain with the "--with-float=soft"
> > > option, hoping that it would emulate FPU instruction, but this
> > > unfortunately doesn't help... I'm nevertheless not sure that this
> > > option is the right one...
> >
> > If your entire
Patrick Olinet writes:
> Finally, I've tried it the dirty way, ie by commenting out all the
> "stfd" instructions at the beginning of the ppc_closure.S file and
> things seem to work !!!
>
> "stfd" are used to save fpu registers and were always executed, even
> if no float/double arguments w
Patrick Olinet writes:
> > > I thought that fpu emulation worked by trapping cpu exceptions when a
> > > fpu instruction is being executed and then emulating this instruction
> > > on software level.
> >
> > Yes.
> >
> > > Isn't the mechanism implemented by the "--with-float=soft" option
Lu
Kevin Handy writes:
> Diego Novillo wrote:
> > We are *always* interested in making GCC faster. All you need now is a
> > copyright assignment, the willingness to do the work (or find someone to
> > do it for you) and the time to implement it.
> >
> > 200% speed gains are nice, especially if
Aaron Gray writes:
> There is something weird with the switch statement in cp/decl.c:7105.
>
> GITWeb :-
>
> http://git.infradead.org/?p=gcc.git;a=blob;f=gcc/cp/decl.c;h=407e5db8d650f1d19c618c7b67566407c2d35fce;hb=master#l7105
>
> Can someone verify this.
>
> Take a close look in a tex
Andrew Pinski writes:
> On 6/5/07, Aaron Gray <[EMAIL PROTECTED]> wrote:
> > There is something weird with the switch statement in cp/decl.c:7105.
> > I dont think it will effect the decl.c's logic, but what does it say about
> > the GCC's C parser, is this legal C ?
>
> Yes this is legal C
Steve Kargl writes:
> Can someone explain why libjava *must* commit binary files to the
> repository? A merge of trunk to the fortran-experiments branch
> generated 70 conflicts that I need to resolve. This is a complete
> waste of time that would have been spent towards cutting a diff
> of
Please don't top-post.
Simon Brenner writes:
> On 6/6/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> > On 06 June 2007 12:04, Simon Brenner wrote:
> >
> > > According to my manpage, printf returns 0 on success, 1 on failure. No
> > > mention of the number of characters written.
> >
> > Well,
Robert Dewar writes:
> Andrew Haley wrote:
>
> > Yes we can. gcc is written in ISO C, and ISO C says that the printf
> > function returns the number of characters transmitted, or a negative
> > value if an error occurred. We don't support bootstrappin
Robert Dewar writes:
> Ross Ridge wrote:
> t formal definition.
>
> > Most of GCC's long list of extensions to C are also implemented as
> > extensions to C++, so you've already lost this battle in GNU C++.
>
> And many of them are ill-defined (and some would agree ill-considered).
> Mist
Dmitry Antipov writes:
>
> with write barrier inside ? The short answers are:
> 1) If 'struct obj' has 100 trapped members, having 100 set_XXX functions
> or macros just to set the fields is ugly;
> 2) Migration from explicit memory management to garbage collection - if you
> h
"Hans Kester " <[EMAIL PROTECTED]> writes:
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed. If you have received this email in error please
> notify Ellips B.V. This message contains conf
Alex Gonzalez writes:
> Hi, trying to come up with a testcase we figured out what the problem could
> be.
>
> When the optimizer is on and memcpy sees that it is copying a
> struct with double words in it, it will assume that the struct
> starts on an 8 byte boundary and use double word loa
ings. It
would certainly be nice to have full interoperability for backtraces,
but in my opinion that's not really essential at the present time.
Comments?
Andrew.
2007-08-08 Andrew Haley <[EMAIL PROTECTED]>
* config/arm/libunwind.S (UNWIND_WRAPPER _Unwind_Backtrace):
Daniel Jacobowitz writes:
> On Tue, Aug 14, 2007 at 03:31:58PM +0100, Andrew Haley wrote:
> > This is one of the last pieces in the jigsaw for gcj on ARM.
> >
> > Unwind_Backtrace is not defined in the ARM exception handling spec at
> > http://www.arm.com/pd
David Daney writes:
> Stephen M. Kenton wrote:
> > Hello all,
> >
> .
> .
> .
> > I realize that there are various "solutions" for specific
> > platforms. Dan Kegel's excellent crosstool and the cross-lfs website,
> >
> .
> .
> .
> >
> > So, my open questions to the list are, wh
Emmanuel Fleury writes:
> # BLOCK 14 freq:1053
> # PRED: 12 [99.0%] (false,exec)
> :;
> *D.5198 = (char) __c;
> stdout.10->_IO_write_ptr = D.5198 + 1B;
> goto ();
> # SUCC: 16 [100.0%] (fallthru,exec)
>
> What does exactly does mean '1B' in this case ?
I think it just mea
This simple test case:
#include
int ten = 10;
int main()
{
printf ("%lld\n", 92233720368547758LL % ten);
return 0;
}
returns
0
because (afaics) __moddi3 is miscompiled.
Breakpoint 4, __moddi3 (u=92233720368547758, v=10)
at /home/aph/gcc/trunk/libgcc/../gcc/libgcc2.c:923
(gdb) fin
Ru
Michael_fogel writes:
> Hello
>
> For my diploma thesis I have to implement a new back-end for GCC.
> The microcontroller is based on an FPGA and was developed one year ago.
> Only an Assembler is available and now my university lecturer wants an C
> compiler too. I decided to use GCC in v
Denys Vlasenko writes:
> On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
> > While profiling a test case of exporting data from PostgreSQL, I noticed
> > that a lot of CPU time was spent in sprintf, formatting timestamps like
> > "2007-10-01 12:34". I could speed that up by an order
Darryl L. Miles writes:
>
> On SPARC there is an ABI that is V8+ which allows the linking (and
> mixing) of V8 ABI but makes uses of features of 64bit UltraSparc
> CPUs (that were not available in the older 32bit only CPUs).
> Admittedly looking at the way this works it could be said that Sun
Darryl Miles writes:
> Andrew Haley wrote:
> > This doesn't sound very different from the small memory model. With
> > the small model, the program and its symbols must be linked in the
> > lower 2 GB of the address space, but pointers are still 64 bits. This
&g
The symptom is that if you segfault and then throw an exception in the
segfault handler call-saved fields in the Condition Register are
corrupted.
The reason is that the unwinder data for CR in the vDSO is wrong. The
line that affects the CR is here in
arch/powerpc/kernel/vdso64/sigtramp.S:
rs
Jakub Jelinek writes:
> On Tue, Oct 16, 2007 at 06:02:13PM +0100, Andrew Haley wrote:
> > The reason is that the unwinder data for CR in the vDSO is wrong. The
> > line that affects the CR is here in
>
> According to __builtin_init_dwarf_reg_size_table on ppc64-linux
Jakub Jelinek writes:
> On Tue, Oct 16, 2007 at 07:22:31PM +0100, Andrew Haley wrote:
> > > and similarly linux-unwind.h should do:
> > >
> > > fs->regs.reg[R_CR2].loc.offset = (long) ®s->ccr - new_cfa;
> > > /* CR? regs are just 32-
Macy Gasp writes:
> Hi everybody,
>
> I'm experiencing a weird behaviour when using va_list with gcc 4.1.2
> on a x86_64 linux distribution.
>
> Below is my test program (yes, I know about the possible buffer
> overflows but please, bear with me, this is just a proof of concept):
>
> #i
Tomash Brechko writes:
> On Mon, Oct 22, 2007 at 00:07:50 +0100, Dave Korn wrote:
> > Because of the 'as-if' rule. Since the standard is neutral
> > with regard to threads, gcc does not have to take them into
> > account when it decides whether an optimisation would satisfy the
> > 'as-if'
Tomash Brechko writes:
> On Mon, Oct 22, 2007 at 11:19:31 +0100, Andrew Haley wrote:
> > Please have a read of [1]. Let us know if anything you have observed
> > isn't covered in that paper.
> >
> > [1] Hans-Juergen Boehm. Threads cannot be implemented as a l
Tomash Brechko writes:
>
> Several people already suggested to use volatile for shared data.
> Yes, it will help because we know it will disable all access
> optimizations, including thread-unaware ones. But I don't want to
> disable _all_ optimizations, I rather vote for thread-aware
> op
Tomash Brechko writes:
> On Mon, Oct 22, 2007 at 18:33:37 +0100, Andrew Haley wrote:
> > We do understand what you're saying, and simply repeating the same
> > thing doesn't help.
> >
> > I think we should wait to see what the C++ working group comes u
Tomash Brechko writes:
> On Mon, Oct 22, 2007 at 18:48:02 +0100, Andrew Haley wrote:
> > Err, not exactly. :)
> >
> > See http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/why_undef.html
>
> Why, I'd say that page is about original races in the program, not
Ian Lance Taylor writes:
> perhaps we should implement the draft C++0x memory model for both C
> and C++.
Yes. I'm sure that's the right answer, given the way that
if-conversion breaks simple code such as
> res = pthread_mutex_trylock(&mutex);
> if (res == 0)
> ++acquires_count;
Bart Van Assche writes:
> On 10/22/07, Andrew Haley wrote:
>
> > The core problem here seems to be that the "C with threads" memory
> > model isn't sufficiently well-defined to make a determination
> > possible. You're assuming that you have
Ian Lance Taylor writes:
> As I understand it, the draft C++0x memory model has acquire release
> semantics for annotated variables. Of course, it wouldn't help the
> originalk test case unless the global variable was annotated.
Mmm, but one of the authors of the draft C++0x memory model tell
Dave Korn writes:
> On 26 October 2007 15:59, Ian Lance Taylor wrote:
>
> > Andreas Schwab <[EMAIL PROTECTED]> writes:
> >
> >> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> >>
> >>> The above code happens to use pthread_mutex_trylock, but there is no
> >>> need for that.
> >>
> >> p
Dave Korn writes:
> On 26 October 2007 16:27, Andrew Haley wrote:
>
> > Dave Korn writes:
> > > On 26 October 2007 15:59, Ian Lance Taylor wrote:
>
> > > > Sure. But the argument that gcc is doing something wrong stands up
> > > > jus
Richard Guenther writes:
> >
> > This is legal POSIX threads code: counter is not accessed when we do
> > not hold the mutex. According to POSIX we do not have to declare
> > volatile memory that we only access when we hold a mutex.
>
> I hope we're not trying to support such w/o volatile c
Dave Korn writes:
> On 26 October 2007 17:11, Andrew Haley wrote:
>
> > > Perhaps I've jumped into the wrong one of the two near-identical
> > > threads we have going on this, but my understanding of the original
> > > complaint was that gcc writes
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > The problem is code like this:
> >
> > int counter;
> >
> > ...
> >
> > if (we_hold_counters_mutex)
> > counter++;
> >
> > This
skaller writes:
>
> On Fri, 2007-10-26 at 14:24 -0700, Ian Lance Taylor wrote:
>
> > This is basically a public relations exercise. I doubt this
> > optimization is especially important, so I think it's OK to
> > disable it to keep people happy. Even though the optimization
> > has been
Bart Van Assche writes:
> On 10/27/07, Florian Weimer <[EMAIL PROTECTED]> wrote:
>
> > And this isn't really specific to threads.
> What I was trying to explain is that it is not necessary to declare
> shared variables volatile, not for any C/C++ compiler that is
> compliant with the langua
Florian Weimer writes:
> * Samuel Tardieu:
>
> > On 27/10, Florian Weimer wrote:
> >
> > | (I can't reproduce the conditional store with my GCC 4.2 installation,
> > | though.)
> >
> > You need "-O -fno-inline" to trigger it on this particular example
> > (you don't need "-fno-inline" if
Bart Van Assche writes:
> We need a solution today for the combination of C/C++ and POSIX
> threads, we can't wait for the respective language standardization
> committees to come up with a solution.
And, in the proposed memory model, I believe we have one. If there is
some reason you believe
Richard Guenther writes:
> On 10/28/07, Erik Trulsson <[EMAIL PROTECTED]> wrote:
> > Unfortunately it seems that the POSIX standard for threads say that as long
> > as access to a shared variable is protected by a mutex there is no need to
> > use 'volatile'.
>
> Which is a very unpracticab
Jakub Jelinek writes:
> On Tue, Oct 30, 2007 at 10:20:34AM +0000, Andrew Haley wrote:
> > That's what the proposed standard language says, kinda-sorta. There's
> > an informal description at
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.h
Schipper, K. - SPLXM writes:
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee
> only. If you are not the addressee, you are notified that no par
Joe Buck writes:
> On Wed, Nov 07, 2007 at 04:06:11AM +1100, skaller wrote:
> > I understand I ask for something gcc may not be doing, I'm not
> > asking for a change, just to understand what it actually does.
>
> You are misusing C++, I'm afraid, and there are no promises that
> some day a
David Daney writes:
> With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> impossible for GCC's exception unwinding machinery to unwind through
> signal frames. The cause of the problems is the
> ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> impossib
Ian Lance Taylor writes:
> [EMAIL PROTECTED] (Richard Kenner) writes:
>
> > > I don't believe this is a strong argument. My contention is,
> > > and has always been, that GCC is _already_ trivial to integrate
> > > into a proprietary compiler. There is at least one compiler I
> > > know th
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > > If gcc supports plugins, then all we've eliminated is the need to
> > > plug that code into passes.c. But that is the easiest part of the
> > > job. Adding plugins is
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > > Most new gcc back-ends are private, so I don't buy that part of the
> > > argument. And in any case nobody is talking about plug-ins for gcc
> > > backends. We'
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Ian Lance Taylor writes:
> > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > >
> > > > > Most new gcc back-ends are private, so I don't buy that
Howard Chu writes:
> A bit of a minor mystery. Not a problem, just a curiosity. If
> someone knew off the top of their head a reason for it, that'd be
> cool, but otherwise no sweat.
It's possible, although unlikley, that the optimized code has worse
cache behaviour. No way to know better wit
Andi Kleen writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Howard Chu writes:
> >
> > > A bit of a minor mystery. Not a problem, just a curiosity. If
> > > someone knew off the top of their head a reason for it, that'd be
>
J.C. Pizarro writes:
> You're wrong. My suggestions are not based from school and are not useless.
> My suggestions are based from university, books, papers and internet, and
> i did put those by a same reason, my freedom.
You have the freedom to make useless postings to this list, just as we
Robert Dewar writes:
> Ian Lance Taylor wrote:
> > Alexandre Oliva <[EMAIL PROTECTED]> writes:
> >
> >> A plan to fix local variable debug information in GCC
> >>
> >> by Alexandre Oliva <[EMAIL PROTECTED]>
> >>
> >> 2007-12-18 draft
> >
> > Thank you fo
Robert Dewar writes:
> Andrew Haley wrote:
> =
> > > I don't think it is fine, we have constant complaints from our
> > > users about this. I think we definitely need an optimization
> > > level that avoids this.
> >
> > Short of puttin
Die: DW_TAG_interface_type (abbrev = 23, offset = 4181)
has children: FALSE
attributes:
DW_AT_declaration (DW_FORM_flag) flag: TRUE
Dwarf Error: Cannot find type of die [in module /home/aph/a.out]
I suppose this means that gcj is generating bad debug info, but I
don
Daniel Jacobowitz writes:
> On Wed, Dec 19, 2007 at 05:21:50PM +0000, Andrew Haley wrote:
> > Die: DW_TAG_interface_type (abbrev = 23, offset = 4181)
> >has children: FALSE
> >attributes:
> >DW_AT_declaration (DW_FORM_flag) flag: TRUE
> >
Daniel Jacobowitz writes:
> On Wed, Dec 19, 2007 at 05:54:10PM +0000, Andrew Haley wrote:
> > > That DIE doesn't have any content. It says "I am a declartion of an
> > > interface". But not which interface or what it's called or what the
> &g
Alexandre Oliva writes:
> On Dec 19, 2007, Andrew Haley <[EMAIL PROTECTED]> wrote:
>
> > Right, so read_type_die() doesn't know how to handle
> > DW_TAG_interface_type. The weird thing is that I have never seen
> > this error mesage before today, and
Alexandre Oliva writes:
>
> How about this patch, instead? It will restore debuggability to Java
> while at the same time maintaining the progress of using the
> long-supported-by-GDB DW_TAG_class_type in both C++ and Java.
>
> for gcc/java/ChangeLog
> from Alexandre Oliva <[EMAIL PROT
Alexandre Oliva writes:
> On Dec 21, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
>
> > Alexandre, I have to say that in my opinion absurd arguments like this
> > do not strengthen your position.
>
> I'm sorry that you feel that way, but I don't understand why you and
> so many ot
be far more
expensive than atomic CAS. It may well be that on N1 an LDX
followed quickly by an STX fails frequently under high contention,
which it really should not do.
It looks like the sample code provided is fantastically highly-
contended, which is IMVHO a perverse thing to optimize for.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
faster.
>
> IIRC, idiv requires that the quotient fit in 32 bits, while your C code
> doesn't. (1LL << 60) / 3 would cause an error with idiv.
Isn't that an integer overflow, which is undefined behaviour?
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK
aybe you
> might suggest a new name for the project (~:
We could just rename it to "GCC", in much the same way that Acorn Risc
Machine became Advanced Risc Machines, then just "Arm". But I'd much
prefer that the FSF got its house in order.
--
Andrew Haley (he/him)
J
On 3/30/21 11:34 AM, Jonathan Wakely wrote:
> On Tue, 30 Mar 2021 at 11:14, Andrew Haley wrote:
>> We could just rename it to "GCC", in much the same way that Acorn Risc
>> Machine became Advanced Risc Machines, then just "Arm". But I'd much
>&
1001 - 1072 of 1072 matches
Mail list logo
