n were intended
to provide a guarantee or warranty, or if there was any expectation
that there was any assumption of liability for GCC's failure to
perform as indicated.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
ts in convergence to representable values.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
ewlib/2006/msg00181.html).
There are references to malloc in eh_alloc.c and
unwind-dw2-fde.c. It looks like these are being
included even when there are no exception handlers.
Any suggestions on how to eliminate the references
to these routines?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd.,
cture. Intel & AMD
have announced that they are developing large multi-core symmetric processors.
The timelines I've seen say that the number of cores on each chip will
double every year or two. Moore's law hasn't stopped. The number of
gates per chip doubles every 18 months.
--
nt, but each is independent of each other.
Separate threads could process the tree/RTL for each function
independently, with the results merged on completion. This
may interact adversely with some global optimizations, such
as inlining.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo
system, the overhead is distributed across all processors, but
results in a net gain. For parallelizations pprograms, a
4-way processor might achieve 3X performance improvement.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Mark Mitchell wrote:
Michael Eager wrote:
GCC 4.1.1 for PowerPC generates a 162K executable for a
minimal program "int main() { return 0; }". GCC 3.4.1
generated a 7.2K executable. Mark Mitchell mentioned the
same problem for ARM and proposed a patch to remove the
reference to
? One of the C++ percepts is that there
is no overhead for features which are not used.
Why should the personality routine be included in all C++ programs?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Mark Mitchell wrote:
Michael Eager wrote:
Why should the personality routine be included in all C++ programs?
Because all non-trivial, exceptions-enabled programs, may need to do
stack unwinding.
It would seem that the place to require the personality
routine would be in the routine which
x27;t need unwinding
shouldn't have a superfluous reference to it.
There is a check in doing_eh() in except.c which checks that
-fexceptions is set if any exception-specific functions are
used. It seems that this would be the place to generate the
reference to __gxx_personality_v0.
--
Michael
better to do
work in parallel that is likely to be needed but possibly may
turn out to be unnecessary than wait until it's known for
sure that it is needed.
Ok maybe its just me.
Well, maybe. ;-)
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Olivier Galibert wrote:
On Sun, Nov 12, 2006 at 02:46:58PM -0800, Michael Eager wrote:
It would seem that the place to require the personality
routine would be in the routine which causes the stack
unwinding, not in every C++ object file, whether needed
or not.
Doesn't that otherwise
) What is the correct way to set the reset vector?
Use a linker script to load a jump to the start routine in the reset vector.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
t;floatdidf2"
[(set (match_operand:DF 0 "gpc_reg_operand" "=f")
(float:DF (match_operand:DI 1 "gpc_reg_operand" "*f")))]
"TARGET_POWERPC64 && TARGET_HARD_FLOAT && TARGET_FPRS"
"fcfid %0,%1"
[(set_attr &qu
find the correct
one for your particular application, you will find that there
are an infinite number of configurations.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
contribute to the project.
You can feel sad all you want, but being patronizing is
not going to get much sympathy.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Ulf Magnusson wrote:
On 11/29/06, Michael Eager <[EMAIL PROTECTED]> wrote:
Ulf Magnusson wrote:
> While searching for an answer, I noticed that lots of people seem
> to have had problems with cross-compilation that to me look more
> like problems in the documentation, which I
B_MATCHES
option and don't mention using '?'.)
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Michael Eager wrote:
I'm having some trouble understanding how to write
a MULTILIB_MATCHES specification.
I need to treat a simple option like "-mhard-float" the
same as an option with a value "-mfp=hard". Here's what
I came up with:
MULTILIB_OPTIONS = mfp=ha
ate change? If so, where?
The PPC EABI says that arrays are aligned on the boundary
of the type, which suggests that this was a bug fix. But
unaligned char arrays make strcpy much slower.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Andrew Pinski wrote:
On Tue, 2007-01-16 at 20:04 -0800, Michael Eager wrote:
But unaligned char arrays make strcpy much slower.
Actually it depends on the processor unless you are messed up by using
-mstrict-align which is a huge hammer for most (if not all) PowerPC
processors even though the
data types, use a union:
union {
long l;
char c[4];
} a;
a.l = 0x12345678;
a.c[0] = 0x01;
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
submit proposals by using
the form on the website. If you are interested in being an active
participant on the DWARF Standard Committee, please contact me
directly.
--
Michael Eager, Chair, DWARF Standard Committee
ore about to use gdb for embedded development with very poor
uControllers?
Try "info gdb" as a start.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Standard
is planned for early 2006. Information about the DWARF
mailing list is also available on the website.
--
Michael Eager, DWARF Workgroup Chair
Eager Consulting
1960 Park Blvd., Palo Alto, CA 94306
650-325-8077
[EMAIL PROTECTED]
p may be directed to the Chair, Michael Eager,
at [EMAIL PROTECTED]
--
Michael Eager, DWARF Workgroup Chair
Eager Consulting
1960 Park Blvd., Palo Alto, CA 94306
650-325-8077
[EMAIL PROTECTED]
participating on the DWARF Committee please
contact me privately.
--
Michael Eager, DWARF Committee Chair
NOTE_VAR_LOCATION_STATUS is taken into account (anyway,
there's no such notes for variables a, b, c in this case).
So, here are my questions:
1) Wouldn't it be nice if GCC marked such stack variables either as
uninitialized (with DW_OP_GNU_uninit) or as ?
2) Is it feasible t
On 07/20/2015 09:55 AM, Nikolai Bozhenov wrote:
On 07/17/2015 08:31 PM, Michael Eager wrote:
A related issue is where the breakpoint is taken. GCC sets breakpoints
at the first instruction generated for a statement, which in this case,
appears to be before any of the arguments to bar are
tectures.
As a first pass, maybe something like this:
...
> Drop
...
MicroBlaze—config/microblaze/constraints.md
MicroBlaze should continue to be supported.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
version will be published. Additional information about
DWARF, including how to subscribe to the DWARF mailing list, can also be found on the website.
Questions about the DWARF Debugging Information Format or the DWARF Committee can be directed to the
DWARF Committee Chair, Michael Eager at i
of
(zero_extract:SI (mem:QI)...) over (zero_extract:SI (mem:SI)...).
3. What's the best way to fix this?
- Remove the down-sizing of MEM in make_extract()?
- Define patterns for extz*?
- Do something so zero_extend accepts QI?
--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
On 11/18/2018 08:14 AM, Jeff Law wrote:
On 11/18/18 8:44 AM, Michael Eager wrote:
On 11/16/18 14:50, Segher Boessenkool wrote:
Hi!
On Wed, Nov 14, 2018 at 11:22:58AM -0800, Michael Eager wrote:
The (mem:SI) is converted to (mem:QI).
The return from make_extract() is
(zero_extract:SI
On 11/21/2018 08:33 AM, Segher Boessenkool wrote:
On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
The internal RTL should not be dictating what the target arch can or
cannot implement. Reload should insert any needed conversions,
especially ones which narrow the size.
Well
On 11/21/18 11:47, Segher Boessenkool wrote:
On Wed, Nov 21, 2018 at 08:52:21AM -0800, Michael Eager wrote:
On 11/21/2018 08:33 AM, Segher Boessenkool wrote:
On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
The internal RTL should not be dictating what the target arch can or
option which I have overlooked or
maybe set incorrectly?
--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
On 11/28/18 09:10, Jeff Law wrote:
On 11/28/18 10:00 AM, Michael Eager wrote:
I have a small test case which generates poor quality code on my target.
Here is the original:
if (cond1 == 2048 || cond2 == 8)
{
x = x + y;
}
return x;
This ends up generating a series of
On 11/28/18 14:37, Andrew Pinski wrote:
On Wed, Nov 28, 2018 at 9:47 AM Michael Eager wrote:
On 11/28/18 09:10, Jeff Law wrote:
On 11/28/18 10:00 AM, Michael Eager wrote:
I have a small test case which generates poor quality code on my target.
Here is the original:
if (cond1 == 2048
On 11/29/18 10:28, Michael Eager wrote:
On 11/28/18 14:37, Andrew Pinski wrote:
On Wed, Nov 28, 2018 at 9:47 AM Michael Eager wrote:
On 11/28/18 09:10, Jeff Law wrote:
On 11/28/18 10:00 AM, Michael Eager wrote:
I have a small test case which generates poor quality code on my
target.
Here
On 8/20/19 4:07 PM, Jeff Law wrote:
On 11/20/18 4:39 PM, Michael Eager wrote:
On 11/20/2018 03:10 PM, Jeff Law wrote:
On 11/20/18 11:07 AM, Michael Eager wrote:
On 11/18/2018 08:14 AM, Jeff Law wrote:
On 11/18/18 8:44 AM, Michael Eager wrote:
On 11/16/18 14:50, Segher Boessenkool wrote
On 8/28/19 12:33 PM, Segher Boessenkool wrote:
Hi!
On Tue, Aug 27, 2019 at 09:37:59AM -0700, Michael Eager wrote:
Combine is complex, but I don't think that target descriptions should
conform to its behaviors;
But they have to, in some ways. If combine writes something that can be
wr
Format or the DWARF
Committee can be directed to the DWARF Committee Chair, Michael Eager at i...@dwarfstd.org.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
.
What can we do about it?
I will revert this commit in GCC.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
On 05/27/2017 09:09 AM, Michael Eager wrote:
On 05/27/2017 01:51 AM, Waldemar Brodkorb wrote:
Hi,
Buildroot and OpenADK have samples to create a Linux system to be
bootup in Qemu system emulation for microblaze architecture.
With gcc 6.3 and 7.1 the samples are not working anymore,
because
e Fortran program into comparable C++ and
see what g++ generates, then try to match it with gfortran.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
d up in the awkward position of a language
standard being revised so that the DWARF definition no longer matched.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
bug data in the
object files is localized in format-specific routines, actual collection
of the data is more implicit than explicit.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
., is described in the Dwarf Standard on page 166.
See http://dwarfstd.org.
If you are looking for translation between gcc register numbers
and the Dwarf register numbers, look in dwarf2out.c. Search for
DBX_REGISTER_NUMBER.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306
ing a link from libdecnumber/dpd/gstdint.h to libgcc/gstdint.h fixes the
problem.
Is there a better fix?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
from the
top of tree. Configure parameters are the same.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
On 10/29/2011 08:44 PM, Ian Lance Taylor wrote:
Michael Eager writes:
I'm seeing a build failure when building a bootstrap gcc
because it is attempting to build target-libiberty. This
is happening for --target=powerpc-linux with the gcc-4.6.1
release and --target=microblaze-xilinx-elf
On 10/29/2011 11:55 PM, Michael Eager wrote:
On 10/29/2011 08:44 PM, Ian Lance Taylor wrote:
Michael Eager writes:
I'm seeing a build failure when building a bootstrap gcc
because it is attempting to build target-libiberty. This
is happening for --target=powerpc-linux with the gcc-
urn' and does not define 'simple_return'.
My guess is that the #ifdef HAVE_return in function.c
which surrounds the undefined functions should be removed.
What is the correct model for the back end? Define only
'return' like ARM, define both 'return' and 'simple_retu
se of the .loc at (2). When the code is
executed, the branch (1) is taken, jumping over the the breakpoint.
I think that the .loc at (2) should not be generated, since it is
in the middle of the prologue code.
I'll file a bug report unless someone already has done so.
--
Michael Eagerea.
GDB's side proved to be harder than in GCC's side (since we're
already assuming things, it would just be another workaround).
Luis
On Tue, 2009-07-21 at 08:38 -0500, Peter Bergner wrote:
On Thu, 2009-07-16 at 13:55 -0700, Michael Eager wrote:
I've tracked down a failure in
Hi --
This is just a heads-up that I'm working on GCC support
for the Xilinx MicroBlaze. It is currently based on
gcc-4.1.2 and I'm porting it to gcc-4.5.0.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Michael Eager wrote:
Hi --
This is just a heads-up that I'm working on GCC support
for the Xilinx MicroBlaze. It is currently based on
gcc-4.1.2 and I'm porting it to gcc-4.5.0.
Paolo Bonzini suggested that I create a branch off the
gcc-4.1.2 tag and commit the original port to t
sumanth wrote:
Hi,
How can I make sure the debugging information printed by my
compiler for extern variables is correct.
Make sure you compile with -g. If you don't generate
debug info for the variable, gdb will default to printing
it as an unknown symbol.
--
Michael Eager
Gerald Pfeifer wrote:
On Sat, 1 Aug 2009, Michael Eager wrote:
Paolo Bonzini suggested that I create a branch off the
gcc-4.1.2 tag and commit the original port to this branch.
Then move this branch up to 4.3.x and then head.
OK to create a microblaze branch?
If you have write access to the
Gerald Pfeifer wrote:
On Sun, 2 Aug 2009, Michael Eager wrote:
Created gcc.gnu.org/svn/gcc/branches/microblaze. Here is the update
to svn.html:
Looks good to me, you just may want to add a closing .
Checked in with .
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
I've checked in patches to the microblaze branch
to bring it into sync with gcc-4.4.2. This has been
tagged with microblaze-4.4.2.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
frequency;
The alternative doesn't allow memory, so I'm unclear why
mem_cost is being set. allows_mem[] is zero for all
operands in the insn.
Can anyone give me some guidance here?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Jeff Law wrote:
On 11/30/09 14:17, Michael Eager wrote:
I've run into a situation where assign_hard_reg()
decides that there are no registers available.
That can certainly happen. It's also the case that assign_hard_reg may
decide that memory is cheaper than a register and refuse t
Jeff Law wrote:
On 11/30/09 14:48, Michael Eager wrote:
Jeff Law wrote:
On 11/30/09 14:17, Michael Eager wrote:
I've run into a situation where assign_hard_reg()
decides that there are no registers available.
That can certainly happen. It's also the case that assign_hard_reg
may d
Jeff Law wrote:
On 11/30/09 14:48, Michael Eager wrote:
Jeff Law wrote:
On 11/30/09 14:17, Michael Eager wrote:
I've run into a situation where assign_hard_reg()
decides that there are no registers available.
That can certainly happen. It's also the case that assign_hard_reg
may d
://lists.dwarfstd.org/listinfo.cgi/dwarf-announce-dwarfstd.org
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
comparison results
in registers and require the condition?
Any suggestions on better ways to model the MicroBlaze
comparison operations?
Are there some restriction on using eq/ne/lt/... the
way I am?
Any suggestions on how to fix the problem in CSE?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Joern Rennecke wrote:
Quoting Michael Eager :
Hi --
I'm working on creating the cstore and cbranch templates
for the Xilinx MicroBlaze processor.
In theory cstore / cbranch should be the future, but the last time I tried
to use them, they didn't quite work right yet, particular
you do not need any CC mode:
Thanks. I'll take a look at this.
There are some other quirks with the MicroBlaze architecture.
The cmp/cmpu instructions only take a register. Other instructions
which can be used for equality or signed comparisons (xor or sub)
can take an immediate operand
I've updated the Microblaze branch to gcc-4.5.
It has passed gcc regression tests reasonably well.
I still have some minor cleanup to do -- updating
copyright notices, checking indents, and so forth.
What's the best process for merging this into head?
Should I submit a patch?
--
Mic
tter question might by why there is no DW_TAG_typedef
DIE which looks like
DW_TAG_typedef
DW_AT_name: BASE_UNION
DW_AT_type: <1279>
BTW gcc-4.3.2 generates
DW_AT_name:
which is also incorrect.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
output? Is this a GNU
bug or just an unsupported feature?
It looks like a GCC bug to me. GCC does generate DW_TAG_typedef
for other typedefs.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
The microblaze branch has been synced with gcc-head and
updated to gcc-4.5.0.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
finalized version will be
published. Additional information about DWARF, including how to subscribe to the
DWARF mailing list, can also be found on the website. Questions about the DWARF
Debugging Information Format or the DWARF Committee can be directed to the DWARF
Committee Chair, Michael Eager, a
ate a load from reg-equiv to a reg
rather than replace the pseudo-reg with the reg-equiv?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Ian Lance Taylor wrote:
Michael Eager <[EMAIL PROTECTED]> writes:
I'm running into a situation where reload is replacing
a pseudo-register in an insn with a memory reference.
The problem is that this is happening in a memory ref.
The initial pattern is something like
(set (reg/v
Richard Henderson wrote:
Ian Lance Taylor wrote:
Michael Eager <[EMAIL PROTECTED]> writes:
I'm running into a situation where reload is replacing
a pseudo-register in an insn with a memory reference.
The problem is that this is happening in a memory ref.
The initial pattern is som
Jeff Law wrote:
Richard Henderson wrote:
Michael Eager wrote:
Another possibility is illegal rtl sharing.
If you mean that an rtx would be pointed to by two different
insn's, how would that happen? (Excluding someone mucking
things up deliberately or accidentally.)
Generally this so
()’:
.../build/powerpc-eabi/libstdc++-v3/include/powerpc-eabi/bits/ctype_noninline.h:43: error: ‘_ctype_’ was not declared in
this scope
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
ng that this is a problem only on powerpc
and perhaps only powerpc-eabi.
Does anyone have any suggestions on how to get one of
these tests to fail consistently, or a different approach
to finding the cause of the intermittent failures?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo
Dave Korn wrote:
Michael Eager wrote:
Does anyone have any suggestions on how to get one of
these tests to fail consistently, or a different approach
to finding the cause of the intermittent failures?
Perhaps hack the testsuite to run the tests under gdb, setting a breakpoint
on abort
Dave Korn wrote:
Michael Eager wrote:
Does anyone have any suggestions on how to get one of
these tests to fail consistently, or a different approach
to finding the cause of the intermittent failures?
Perhaps hack the testsuite to run the tests under gdb, setting a breakpoint
on abort
Is there any documentation on the contents of .eh_frame
and the augmentations used? IIRC, the data describes the
try blocks and the catch handlers, but I'm looking for
the gory details.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Ian Lance Taylor wrote:
Michael Eager writes:
Is there any documentation on the contents of .eh_frame
and the augmentations used? IIRC, the data describes the
try blocks and the catch handlers, but I'm looking for
the gory details.
I don't know of any docs. Docs would be nice
Michael Matz wrote:
Hi,
On Fri, 15 May 2009, Michael Eager wrote:
Is there any documentation on the contents of .eh_frame
and the augmentations used?
.eh_frame simply contains normal unwinding information, in DWARF2(34)
format, you're familiar with that :)
And nothing more, specifi
Michael Matz wrote:
Hi,
On Sun, 17 May 2009, Michael Eager wrote:
But the _format_ of the LSDA is not specified. It's really an
implementation detail of the compiler/language and doesn't have to be
agreed upon for mixing .o files from different compilers, as every
compilation uni
Olivier Hainque wrote:
Michael Eager wrote:
I'll reverse-engineer the table unless I can find something
more descriptive than the comments in gcc or gdb.
FWIW, I did a similar exercise long ago and synthesized my
understanding in ada/raise-gcc.c, where the Ada personality routin
-04/msg01907.html
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01906.html
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
The final version of DWARF Version 4 is available
for download from http://dwarfstd.org.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Michael Eager wrote:
The final version of DWARF Version 4 is available
for download from http://dwarfstd.org.
A technical problem generating the PDF of the DWARF
Version 4 standard has been corrected. Please see
following announcement.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd
broad range of companies,
including Apple, ARM, CodeSourcery, Concurrent Computer, Eager Consulting,
Google, Hewlett-Packard, IBM, RedHat, SGI, Sun Microsystems, and TotalView, as
well as unaffiliated individuals with significant experience in compiler and
debugger development.
Michael Eager
stics and see if I can make some
sense of what is going on.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
accepted the Microblaze port for inclusion in GCC and appointed
Michael Eager as port maintainer.
Thanks!
Adding myself to maintainer list.
Index: MAINTAINERS
Joel Sherrill wrote:
On 09/28/2010 01:56 PM, Michael Eager wrote:
David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
accepted the Microblaze port for inclusion in GCC and appointed
Michael Eager as port maintainer.
Thanks!
Congratulations!
Does your
garble the result. (This doesn't happen with soft-fp.)
int r = 0, s = 0;
float a = 1.0, x = NaN;
r = (a <= x);
s = (a > x);
should result in r == s == 0. CSE translates this (more
or less) into
r = (a <= x);
s = !r;
Is there a way to prevent CSE from optimizing FP
this problem?
Is this supposed to work in a different way?
Anyone come up with a fix?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Paolo Carlini wrote:
On 10/22/2010 08:43 PM, Michael Eager wrote:
Hi --
I'm seeing test suite failures in g++ caused by
linking with the wrong libstdc++.so.
It looks like g++.exp always appends the default
directory
append flags -L${gccpath}/libstdc++-v3/src/.libs
instead of
append
Ralf Wildenhues wrote:
Hello Michael,
* Michael Eager wrote on Fri, Oct 22, 2010 at 10:35:48PM CEST:
Paolo Carlini wrote:
On 10/22/2010 08:43 PM, Michael Eager wrote:
I'm seeing test suite failures in g++ caused by
linking with the wrong libstdc++.so.
It looks like g++.exp always ap
1 - 100 of 203 matches
Mail list logo
