On 07/18/2013 08:29 PM, Andy Lutomirski wrote:
On Thu, Jul 18, 2013 at 6:17 PM, David Daney ddaney.c...@gmail.com wrote:
On 07/18/2013 05:50 PM, Andy Lutomirski wrote:
On Thu, Jul 18, 2013 at 5:40 PM, David Daney ddaney.c...@gmail.com
wrote:
On 07/18/2013 05:26 PM, Andy Lutomirski wrote
this on many architectures running on the Linux kernel.
You can do it from C using incantations like those found in the GCC
testsuite's gcc/testsuite/gcc.dg/cleanup-9.c file.
From C++ it is even easier, it is just a normal exception.
David Daney
Windows calls it SEH (structured exception handling
On 07/18/2013 05:50 PM, Andy Lutomirski wrote:
On Thu, Jul 18, 2013 at 5:40 PM, David Daney ddaney.c...@gmail.com wrote:
On 07/18/2013 05:26 PM, Andy Lutomirski wrote:
Windows has a feature that I've wanted on Linux forever: stack-based
(i.e. scoped) exception handling. The upshot
On 04/14/2013 01:27 PM, Moore, Catherine wrote:
-Original Message-
From: David Daney [mailto:ddaney.c...@gmail.com]
Sent: Friday, April 12, 2013 7:29 PM
To: Moore, Catherine
Cc: Rozycki, Maciej; gcc-patches@gcc.gnu.org; Richard Sandiford
Subject: Re: [Patch] [MIPS] Fix Many warnings
of these warnings.
David Daney
On 04/12/2013 10:55 AM, Moore, Catherine wrote:
-Original Message-
From: Maciej W. Rozycki [mailto:ma...@codesourcery.com]
Sent: Friday, April 12, 2013 1:03 PM
To: David Daney
Cc: Moore, Catherine; gcc-patches@gcc.gnu.org; Richard Sandiford
Subject: Re: Many warnings in MIPS port
to test this yet. I may try Monday.
David Daney
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 197836)
+++ gcc/configure.ac (working copy)
@@ -4058,7 +4058,7 @@
[Define if your assembler supports .gnu_attribute
.
David Daney
If you have information here for me I would rather help in assessing whether
the compiler for use in safety-relevant area is suitable.
The second point of my work is concerned with the treatment of releases. Are
you putting any kind of evidences in your source-code and how they look
.
David Daney
/ml/gcc-testresults/2012-12/msg01861.html
[hjl@gnu-4 src-4.7]$ cat gcc/REVISION
[gcc-4_7-branch revision 194514]
[hjl@gnu-4 src-4.7]$
The last time I checked, gcc/REVISION is only set to the proper value by
running contrib/gcc_update.
David Daney
the tests, can we fix the problem instead?
The goal of the testsuite should be to detect problems, not yield clean
results.
If Richard disagrees with me, then I would defer to him.
David Daney
Really I meant this in reply to the 'Fix
gcc.target/mips/octeon-bbit-2.c for -Os' thread. Sorry for confusing
the issue here.
I don't really have an objection to this one.
David Daney
On 10/08/2012 11:28 AM, David Daney wrote:
On 10/08/2012 11:15 AM, Mike Stump wrote:
On Oct 8, 2012
of the art. That could be a bit
of work.
David Daney
On 09/06/2012 01:48 PM, Mike Stump wrote:
On Sep 6, 2012, at 1:09 PM, David Daney ddaney.c...@gmail.com wrote:
On 09/06/2012 01:00 PM, Ian Lance Taylor wrote:
On Thu, Sep 6, 2012 at 11:56 AM, Mike Stump mikest...@comcast.net wrote:
Where in the manual are the machine specific print operand
though.
Thanks,
David Daney
with the -mno-synci
annotation could easily become different than the set that requires it.
David Daney
Steve Ellcey
sell...@mips.com
2012-06-11 Steve Ellceysell...@mips.com
* gcc.target/mips/call-saved-1.c: Add -mno-synci flag.
* gcc.target/mips/call-saved-2.c: Ditto
in a usable .class file, but is error prone and not
very reproducible.
David Daney
On 02/16/2012 03:32 PM, Richard Sandiford wrote:
David Daneydavid.da...@cavium.com writes:
On 02/16/2012 02:12 PM, Richard Henderson wrote:
[...]
Thanks for the patch.
index 1c19f8b..59d4560 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -2920,3 +2920,15 @@ extern
to unwind in kernel mode? */
That's too bad. I guess if we ever want to unwind in kernel mode, we
can say no mips16 and switch it to a low-order bit for that application.
Or write our own unwinder.
David Daney
you can commit this upstream if acceptable.
Thanks,
David Daney
Index: go/syscall/libcall_linux_amd64.go
===
--- go/syscall/libcall_linux_amd64.go (revision 0)
+++ go/syscall/libcall_linux_amd64.go (revision 0)
@@ -0,0 +1,13
for this patch.
David Daney
because of those. I was going to create a patch to move
those two to libcall_linux_{386,amd64}.go. An alternative would be to
remove them too.
David Daney
++
symbols only when present. With RTLD_NOW, the plugin fails to load in cc1 as
symbol resolution is forced at load time.
Can you supply weak binding implementations for the missing functions?
That might allow the linking to succeed.
David Daney
On 09/06/2011 10:55 AM, David Daney wrote:
On 09/05/2011 12:50 AM, Romain Geissler wrote:
Hi
Is there any particular reason to load plugin with the RTLD_NOW option?
This option force .so symbol resolution to be completely made at load
time,
but this could be done only when a symbol is needed
support unwinding through signal handlers,
so adding this makes sense to me.
David Daney
So, suggestions welcome. Is there a nice way to detect a signal frame?
On 07/07/2011 09:57 AM, Matthias Klose wrote:
On 07/07/2011 06:51 PM, David Daney wrote:
On 07/07/2011 09:27 AM, Matthias Klose wrote:
As discussed at the Google GCC gathering, disable the build of static libraries
in libjava, which should cut the build time of libjava by 50%. The static
into GCC.
So am I for the kernel primarily because it's not really a new ABI but
an enhancement of the existing N32 ABI.
The patches are resting peacefully on my laptop. Now with endorcements
like these, I may be forced to actually finish them...
David Daney
just as well as
when compiled for Genuine n32.
However, currently the kernel will only give out 2GB worth of address
space to n32 programs. To get any benefit from the new ABI variant, the
kernel would have to be modified to use the entire 4GB of usable address
space.
David Daney.
think once the OS puts a process into u32 mode, there is no going
back. We would just have ld.so refuse to load any shared objects that
were not compatible with the current mode.
We would continue to place libraries in /lib32, /usr/lib32,
/usr/local/lib32, etc.
David Daney
executing the throw?
David Daney
submit a full bug report,
with preprocessed source if appropriate.
Seehttps://support.codesourcery.com/GNUToolchain/ for instructions.
Look, it tells you exactly what to do. Go visit that web site.
Thanks,
David Daney
the secret differences were, it would
be easier to opine on this topic.
David Daney
On 03/17/2011 11:20 AM, McCall, Ronald SIK wrote:
If you let us in on what exactly the secret differences were, it would
be easier to opine on this topic.
Sure thing! Here is an instruction sequence from the original Solaris
toolchain:
Resending to gcc@. I didn't really want a private
On 02/14/2011 12:29 PM, David Daney wrote:
Background:
Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
user virtual memory space. This is due the way MIPS32 memory space is
segmented. Only the range from 0..2^31-1 is available. Pointer
values are always sign extended
byte region
centered on the split.
The Linux kernel works around this by not using the lower 32kb of
ckseg0. It also never user the top 32kb of useg when in 32bit mode.
David Daney.
On 02/16/2011 02:10 PM, Paul Koning wrote:
On Feb 16, 2011, at 5:08 PM, David Daney wrote:
On 02/16/2011 01:44 PM, Paul Koning wrote:
I'm running into a crash caused by mishandling of address calculation of an
array element address when that array is near the bottom of kseg0
On 02/16/2011 02:32 PM, Paul Koning wrote:
On Feb 16, 2011, at 5:25 PM, David Daney wrote:
What is the state of your C0_Status[{KX,SX,UX}] bits?
0, 0, 0
It is not really a compiler bug, but rather a defect in the n32 ABI. When using
32-bit pointers you can only do 32-bit operations
On 02/14/2011 07:00 PM, Matt Thomas wrote:
On Feb 14, 2011, at 6:50 PM, David Daney wrote:
On 02/14/2011 06:33 PM, Matt Thomas wrote:
On Feb 14, 2011, at 6:22 PM, David Daney wrote:
On 02/14/2011 04:15 PM, Matt Thomas wrote:
I have to wonder if it's worth the effort. The primary
with the high bit (two bits
for mips64) set.
Your complaint is a good summary of why I am thinking about n32-big.
David Daney
type. That would certainly complicate things somewhat.
David Daney
Background:
Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
user virtual memory space. This is due the way MIPS32 memory space is
segmented. Only the range from 0..2^31-1 is available. Pointer
values are always sign extended.
Because there are not already enough MIPS
On 02/14/2011 04:15 PM, Matt Thomas wrote:
On Feb 14, 2011, at 12:29 PM, David Daney wrote:
Background:
Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
user virtual memory space. This is due the way MIPS32 memory space is
segmented. Only the range from 0..2^31-1
!) but lots of paying customers clamored for it.
(I personally don't have an opinion on whether it's worth bothering with).
Also look at the new x86_64 ABI (See all those X32 psABI messages) that
the Intel folks are actively working on. This proposal is very similar
to what they are doing.
David
On 02/14/2011 06:34 PM, Matt Thomas wrote:
On Feb 14, 2011, at 6:26 PM, David Daney wrote:
On 02/14/2011 06:14 PM, Joe Buck wrote:
On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote:
It seems that this proposal would benefit programs that need more than 2 GB but
less than 4 GB
On 02/14/2011 06:33 PM, Matt Thomas wrote:
On Feb 14, 2011, at 6:22 PM, David Daney wrote:
On 02/14/2011 04:15 PM, Matt Thomas wrote:
I have to wonder if it's worth the effort. The primary problem I see
is that this new ABI requires a 64bit kernel since faults through the
upper 2G will go
between both the
o32 and n32 libraries.
How to sort this out?
David Daney
# ...n64
David Daney
default GCC behavior under linux-mips64* is to ignore all
those details.
Based on my almost complete lack of libgo knowlege, I think the
selection of a specific syscall_linux_${GOARCH}.go file would not care
about soft/hard float issues.
David Daney
identical to the existing
i386 syscall ABI. This means that the psABI must use the same size and
alignment rules for in-memory structures as the i386 does.
David Daney
On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
On 12/30/2010 11:34 AM, David Daney wrote:
My suggestion: Since people already spend a great deal of effort
maintaining the existing i386 compatible Linux syscall infrastructure,
make your new 32-bit x86-64 Linux syscall ABI identical
On 12/30/2010 12:28 PM, H.J. Lu wrote:
On Thu, Dec 30, 2010 at 12:27 PM, David Daneydda...@caviumnetworks.com wrote:
On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
On 12/30/2010 11:34 AM, David Daney wrote:
My suggestion: Since people already spend a great deal of effort
maintaining
to have ecj installed, so it's one dependency more and
one less.
I may be mistaken, but I don't think that is true. Building and testing
of libgcj *does not* require ecj.
David Daney
target_flag_state *this_target_flag_state;
Which when preprocessed we get:
expr.i:??? extern struct target_flag_state *(default_target_flag_state);
Which evidently is not valid C.
I am not sure how to go about fixing this.
Do you have any ideas?
David Daney
numbers during this outage? Will bugzilla eventually end up with the
commit comments we have all come to know and love?
David Daney
I don't know the answers to your specific questions, but I do know that
java questions might get faster response if cross posted to java@ (now
CCed).
David Daney
On 09/10/2010 03:50 PM, Steven Bosscher wrote:
Hello,
There is just one front-end file left that still has to #undef
On 08/30/2010 08:36 PM, Adam Jiang wrote:
On Mon, Aug 30, 2010 at 10:43:44AM -0700, David Daney wrote:
On 08/30/2010 09:46 AM, Richard Henderson wrote:
On 08/30/2010 03:45 AM, Adam Jiang wrote:
When I read the source in Linux kerne, it was said that stack canary for
implementing stack
not implemented for MIPS.
For the Linux kernel, the MIPS stack canary would be a constant offset
(that depends on PAGE_SIZE) from register $28.
David Daney
candidates.
David Daney.
On 08/06/2010 10:51 AM, Bruce Korb wrote:
On 08/06/10 10:24, David Daney wrote:
On 08/06/2010 10:19 AM, Bruce Korb wrote:
The problem seems to be that GDB thinks all the code belongs to a
single line of text. At first, it was a file of mine, so I presumed
I had done something strange
to?
The source is available somewhere, I have seen it.
j...@gcc.gnu.org is the best place to ask java questions. Let's see
what they say over there.
David Daney
and
linker.
David Daney
,
and trying to accommodate all of them would surly be determental to GCC.
I think that some potential contributors are discouraged from
contributing because they have been frightened away (by the Vocal
Discontents mentioned above) before they can get started.
David Daney
, it is probably the right
choice.
David Daney
fanqifei wrote:
2010/1/13 Bingfeng Mei b...@broadcom.com:
Your instruction is likely too specific to be picked up by GCC.
You may use an intrinisc for it.
Bingfeng
but insv is a standard pattern name.
the semantics of expression x= (x0xFF00) | ((i16)0x00FF);
is exactly what insv can
Jamie Lokier wrote:
Uwe Kleine-König wrote:
Use the new unreachable() macro instead of for(;;);
*(int *)0 = 0;
/* Avoid noreturn function does return */
- for (;;);
+ unreachable();
Will GCC-4.5 remove (optimise away) the *(int *)0 = 0 because it
knows the branch of
tables that get generated by
the inline asm (as in x86), __builtin_trap() becomes less useful.
David Daney
the problem. Just reloading the page
works as well.
I don't know what it would take to put an expiration date on those pages
that are updated monthly so that the reload wouldn't be necessary.
David Daney
instruction, which would otherwise be a nop.
David Daney
lightly tested, but they could be a starting point.
I will dig them out and post them this weekend.
David Daney.
to see if they should be).
David Daney
; that is much less of a problem with boehm-gc.
It may be less of a problem, but running svn log boehm-gc shows several
non-configure changes since Bryce imported version 6.6 in r110222.
David Daney
willing to acquire such knowledge and background by
attempting to do the merge and presenting the results of their efforts
for review.
David Daney
that are all accessed via mechanisms like the URLConnection,
and the various crypto implementations.
David Daney
insensitive or only try the
lower-upper case?
David Daney
will press on with it.
The main point of this message is to try to avoid duplication of effort.
Thanks,
David Daney
Richard Sandiford wrote:
Hi David,
David Daney [EMAIL PROTECTED] writes:
Richard and others,
I have a (still broken) patch that tries to fix the fallout from the
change in semantics of the __sync_nand faimily of builtins that occurred
recently on the trunk.
If someone else is working
/msg00033.html
David Daney
Zhang Le wrote:
On 10:33 Mon 01 Dec , David Daney wrote:
Zhang Le wrote:
BASE_DRIVER_SELF_SPECS \
+LINUX_DRIVER_SELF_SPECS \
%{!EB:%{!EL:%(endian_spec)}} \
%{!mabi=*: -mabi=n32}
You are missing a comma there between BASE_DRIVER_SELF_SPECS and
LINUX_DRIVER_SELF_SPECS. Without the comma
Geert Uytterhoeven wrote:
On Fri, 21 Nov 2008, Alan Cox wrote:
On Thu, 20 Nov 2008 17:26:36 -0800
David Daney [EMAIL PROTECTED] wrote:
MIPS: Make BUG() __noreturn.
Often we do things like put BUG() in the default clause of a case
statement. Since it was not declared __noreturn, this could
are working on a GCC patch
that adds a new built-in function '__builtin_noreturn()', that you could
substitute for 'for(;;);' that emits no instructions in this case.
David Daney
until it contains an FSF copyright
notice. Before it is committed it is your code, do whatever you want.
David Daney
, but we don't like to make
a big spectacle of it.
I would recommend following [EMAIL PROTECTED] instead.
David Daney
Adam,
As shown here:
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01775.html
gcc.target/mips/octeon-exts-2.c is failing when configured --with-arch=sb1
Do you know if it is failing universally or only on non-octeon targets?
David Daney
Adam,
As shown here:
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01775.html
gcc.target/mips/octeon-exts-2.c is failing when configured --with-arch=sb1
Do you know if it is failing universally or only on non-octeon targets?
David Daney
than compare_tests?
That would be nice, but you could sort your FAILs if it changed and be
able to compare the sorted lists.
But stability within a given revision of the testsuite I think would be
almost essential.
David Daney
Within the last two days my MIPS bootstraps are failing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
It worked back on:
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00118.html
David Daney
on MIPS where there are
similar issues.
David Daney
the repeats are generated by gmail.com. You will note
that NightStrike's messages are repeated as well.
David Daney
patch code remains. If so, probably
a copyright assignment for the original author would be required as well (at
least that is my understanding).
David Daney
of
the __register_frame* family of functions (in libgcc) passing pointers to the
appropriate .eh_frame sections of the generated code.
I imagine that GCJ has do to this ind of thing?
g++ as well.
David Daney
Dave Korn wrote:
David Daney wrote on 12 August 2008 18:19:
Questions like this should probably go to [EMAIL PROTECTED]
Questions about deep compiler internals and EH abis? Seems a bit intense
for the where's-the-any-key list to me...
gcc@ is for questions about development of GCC
, on some basis, for microcontroller usage. Clearly this cannot be
a direct compilation in all cases, especially for graphics, but any such
activity may beat starting from square one.
GCC ships with a fairly complete java runtime library (libgcj).
David Daney
exact situation.
David Daney
Richard Sandiford wrote:
David Daney [EMAIL PROTECTED] writes:
Ralf Baechle wrote:
On Wed, Jun 11, 2008 at 10:04:25AM -0700, David Daney wrote:
The third operand to 'ins' must be a constant int, not a register.
Signed-off-by: David Daney [EMAIL PROTECTED]
---
include/asm-mips/bitops.h
Richard Sandiford wrote:
David Daney [EMAIL PROTECTED] writes:
Richard Sandiford wrote:
David Daney [EMAIL PROTECTED] writes:
Ralf Baechle wrote:
On Wed, Jun 11, 2008 at 10:04:25AM -0700, David Daney wrote:
The third operand to 'ins' must be a constant int, not a register.
Signed-off
Ralf Baechle wrote:
On Wed, Jun 11, 2008 at 10:04:25AM -0700, David Daney wrote:
The third operand to 'ins' must be a constant int, not a register.
Signed-off-by: David Daney [EMAIL PROTECTED]
---
include/asm-mips/bitops.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff
where is the goto setup code created? And is there a bug here?
Perhaps you need to implement one or more of: save_stack_nonlocal,
restore_stack_nonlocal, nonlocal_goto, and/or nonlocal_goto_receiver.
David Daney
FAILures
that are only on the branch.
Although I didn't investigate, the FAILure in libjava/Array_3, usually
indicate that exception handling is broken in some way.
David Daney
.
Having this would allow VRP to eliminate a good bit of dead code for
common java constructs.
See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24825
Thanks,
David Daney
distinguish the second :-).
David Daney
1 - 100 of 265 matches
Mail list logo
