For the sake of clarity, I've separated out these minor refactoring
changes from the rest of the patches.
Signed-off-by: Daniel Santos
---
gcc/config/i386/i386.c | 21 ++---
gcc/config/i386/i386.h | 4 +++-
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git
msabi --> sysv scenario)
[f] Variant for hard frame pointer (and stack realignment)
[x] Tail-call variant (is the return from function)
Signed-off-by: Daniel Santos
---
libgcc/config.host | 2 +-
libgcc/config/i386/i386-asm.h |
ix86_compute_frame_layout will now populate fields added to structs
machine_function and ix86_frame, which are used by xlogue_layout::get_instance
to determine the correct instance to return.
Signed-off-by: Daniel Santos
---
gcc/config/i386/i386.c | 105
Adds the option to i386.opt and i386.c and adds documentation to
invoke.texi.
Signed-off-by: Daniel Santos
---
gcc/config/i386/i386.c | 3 ++-
gcc/config/i386/i386.opt | 5 +
gcc/doc/invoke.texi | 11 ++-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/gcc
Adds HARD_REG_SET stub_managed_regs to track registers that will be
managed by the pro/epilogue stubs for the function.
Adds a third parameter bool ignore_outlined to ix86_save_reg to specify
rather or not the count should include registers marked in
stub_managed_regs.
Signed-off-by: Daniel
ff-by: Daniel Santos
---
gcc/config/i386/i386.c | 281 +++--
1 file changed, 272 insertions(+), 9 deletions(-)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b3d48ac2e78..f9a02bedbee 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config
the platforms.
I suppose this is either a bug report that we're getting lwsync when we
shouldn't be getting it, or just a question of what the typical tune is
to make generic binaries ?
Thanks for any help,
Daniel
On 02/09/2017 10:08 AM, David Edelsohn wrote:
On Thu, Feb 9, 2017 at 1:00 PM, Daniel Walker wrote:
Hi,
It looks like -mcpu=common (on the powerpc architecture) was removed. My
group is struggling to find a way to compile generic binaries for PowerPC.
We have been getting an LWSYNC
use some
others that might not be superset of those.
Jakub
We tried using e500, but on Freescale t1042 there was another
instruction, evstdd instruction which caused a fault. Andrii did the
testing, he can address it better than I can.
Daniel
, having the logic scattered about makes maintenance ugly.
Daniel
y bug report, but here it is anyway:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771
Daniel
c_assert(is_same::value,
"traits_type::char_type must be equal to _CharT");
Would you agree with that course of action?
Thanks,
- Daniel
2017-03-13 11:56 GMT+01:00 Jonathan Wakely :
> On 12 March 2017 at 13:21, Daniel Krügler wrote:
>> I'm now working on
>>
>> http://cplusplus.github.io/LWG/lwg-defects.html#2861
>>
>> The new wording state is now equivalent to basic_string_view, whose
&g
On 03/10/2017 11:23 AM, Joseph Myers wrote:
On Fri, 10 Mar 2017, Daniel Santos wrote:
3. Wouldn't it be better to move this logic up into DejaGnu and restrict gcc
to using a black-box interface for modifying the environment?
GCC is meant to work with a wide range of different DejaGnu ver
has a vary narrow scope, so
I'm thinking "mcall-ms2sysv-xlogues" is a good and brief descriptor.
Any comments, objections?
Thanks,
Daniel
STSUITEDIR)/$(check_p_tool)-parallel in Makefile.in is supposed to
be for?
Thanks,
Daniel
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp b/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp
new file mode 100644
index 000..8c3a3d2fc1c
--- /dev/null
+++ b/gcc/tes
e_decl_common {
/* DECL_ALIGN. It should have the same size as TYPE_ALIGN. */
unsigned int align : 6;
- /* 20 bits unused. */
+ unsigned int constprop : 1;
+
+ /* 19 bits unused. */
/* UID for points-to sets, stable over copying from inlining. */
unsigned int pt_uid;
Thanks!
Daniel
would appear that it is
already performing some of the constant propagation that I wanted it to
do (without the new attribute), and yet many constancy tests fail unless
the function is "always_inline"ed from the caller "flatten". I'll have
to dig more to figure out why.
Daniel
8d05cc6f387aec6099ea0589f45a22edeb1475fd
Author: jason
Date: Wed May 3 18:50:25 2017 +
* doc/invoke.texi: Note that -faligned-new is on by default
for C++17.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@247564
138bc75d-0d04-0410-961f-82ee72b054a4
Daniel
Thanks for the help, Martin!
On 05/03/2017 03:42 AM, Martin Jambor wrote:
Hi,
On Sat, Apr 29, 2017 at 06:28:31AM -0500, Daniel Santos wrote:
Brievity is not my forte, so let me start with the questions. Can somebody
please point me to the pass and/or function where gcc
1.) decides rather or
investigating why.
You mean debugging and non-debugging build?
Richard.
I got the problem when I built with --enable-checking=yes,rtl. I
haven't tested any other combinations. My first guess would be a
gcc_checking_assert () with side-effects?
Daniel
pression %q+D is not constant in this
context", var);
+ /* TODO: Set something so we don't repeat this warning. */
+ }
+ }
+
/* ??? ivopts calls expander, without any preparation from
out-of-ssa. So fake instructions as if this was an access to the
base variable. This unnecessarily allocates a pseudo, see how we can
Comments, objections, suggestions?
Thanks,
Daniel
Thanks for your feedback!
On 05/09/2017 04:36 AM, Florian Weimer wrote:
On 05/09/2017 01:36 AM, Daniel Santos wrote:
To further the usefulness of such techniques, I propose the addition
of a c-family attribute to declare a parameter, variable (and
possibly other declarations) as "cons
Thanks for your feedback!
On 05/09/2017 08:29 AM, Allan Sandfeld Jensen wrote:
On Tuesday 09 May 2017, Daniel Santos wrote:
The primary aim is to facilitate high-performance generic C
libraries for software where C++ is not suitable, but the cost of
run-time abstraction is unacceptable. A good
t turns out that their
optimization hint don't look like such a good idea. :)
I appreciate everybody's feedback! Thoughts?
Also, still a bit new to GCC, am I missing any formal steps that should
be taken prior to pursuing such changes?
Thanks,
Daniel
Sorry for my delayed response.
On 05/11/2017 09:35 AM, Joseph Myers wrote:
On Thu, 11 May 2017, Jonathan Wakely wrote:
On 10 May 2017 at 23:14, Daniel Santos wrote:
Well my primary goal is programming with values that are constant in the
compiler. There is no language in any C specification
On 05/12/2017 10:49 AM, Martin Sebor wrote:
On 05/10/2017 04:14 PM, Daniel Santos wrote:
Well my primary goal is programming with values that are constant in the
compiler. There is no language in any C specification (that I'm aware
of) for a "compile-time constant", but the
* gcc/testsuite/lib/gcc-defs.exp (num_jobs, load_max, getloadavg_exe):
New global variables.
(check_cpu_load): New proc to check speed limit.
(gcc_parallel_test_run_p): Modify to call check_cpu_load before
acquiring a new lock file.
Thanks,
Daniel
di
On 08/03/2017 11:45 AM, Jeff Law wrote:
> On 08/02/2017 11:34 PM, Daniel Santos wrote:
> So does this perform better than make -j X -l X? I use that with good
> success.
>
> jeff
Sorry for my slow response!
For a short answer, if you have 8 CPU cores and you run make -j8
On 08/03/2017 05:07 PM, Mike Stump wrote:
> On Aug 2, 2017, at 10:34 PM, Daniel Santos wrote:
>> I'm working on a patch to modify the testsuite to obey the
>> --load-average value if one is passed to make.
> The code seems like a reasonable approach. Love to see numbers a
;m doing
wrong, and if it is broken that we are aware of it.
I'm able to get a 7.1 bootstrap using:
/home/daniel/proj/sys/gcc/7.x/configure
--prefix=/home/daniel/local/gcc-7.1.0 --build=x86_64-pc-linux-gnux32
--with-abi=mx32 --enable-checking=yes,rtl --enable-languages=all
--enable-boot
On 08/13/2017 05:52 PM, Daniel Santos wrote:
> cc1plus: out of memory allocating 56137200 bytes after a total of
> 314880 bytes
> make[3]: *** [Makefile:1104: insn-extract.o] Error 1
> make[3]: *** Waiting for unfinished jobs
I apparently misunderstood the "after a total
On 08/13/2017 07:05 PM, H.J. Lu wrote:
> On Sun, Aug 13, 2017 at 3:52 PM, Daniel Santos
> wrote:
>> I've setup an x32 test environment using Gentoo in hopes of being able
>> to both compile and run x32 tests, but I'm having problems getting a
>> successful boots
successful x32 bootstrap using
--enable-checking=yes without rtl -- good enough for all of the tests
that I need to run.
Daniel
w is a backtrace just
prior to the error. I'm not at all intimate with gcc's memory
management, if gcc keeps track of how much each component has allocated.
(gdb) bt
#0 __GI___libc_malloc (bytes=56137200) at malloc.c:2905
#1 0x025bc8dc in xmalloc (size=56137200) at
/home/daniel
iant. Both Clang and Intel compilers did this in my tests.)
Cheers,
Daniel
URL: http://mirror.linux-ia64.org/gnu/gcc/
Country/City: Russia / Novosibirsk
Contact email / name: dan...@volchixin.co.uk (Daniel Volchixin)
As the person who, eons ago, wrote a bunch of the the GDB code for this C++
ABI support, and as someone who helped with DWARF support in both GDB and
GCC, let me try to propose a useful path forward (in the hopes that someone
will say "that's horrible, do it this instead")
Here are the constraint
On Wed, Feb 7, 2018 at 5:44 AM, Simon Marchi
wrote:
> On 2018-02-07 02:21, Daniel Berlin wrote:
>
>> As the person who, eons ago, wrote a bunch of the the GDB code for this
>> C++
>> ABI support, and as someone who helped with DWARF support in both GDB and
>> GCC,
>
>
> This avoids the problem of the demangler gdb is using getting a different
> name than the producer used. It also should always give you the right one.
> If the producer calls the type "vtable fo Foo<2u>" here and "Foo<2>"
> elsewhere, yes, that's a bug. It should be consistent.
>
>
This shoul
Again, please don't do this.
As you can see (see Tom Tromey's email), others have a use to go between
vtable types and the types they are attached to.
We should be getting away from linkage names, not going further towards
them.
There are a bunch of gdb bugs this won't solve, but adding an extensio
ll get
together in the next few weeks. I'll email the Wine list later today.
Daniel
On 19/07/2018 18:56, Eric Gallager wrote:
On 7/19/18, U.Mutlu wrote:
Hi,
it makes me 'crazy' when I see such if-else constructs:
if (x)
return 7;
else
return 4;
(Of course in this case one better would use the shorthand "return x ? 7 :
4;", but that's not the issue here)
free to add these sample plugins. Feedback is also very much welcome.
Regards,
Daniel
Hello Pierre!
It is an interesting plugin. I'll keep an eye on your repository.
Thanks!
Daniel Marjamäki
2011/2/9 Pierre Vittet :
> Hello,
>
> I would like to present you a small plugin, which could be a good exemple of
> a MELT use case.
> This plugin allows to monitor t
we still need 4.3?
--
Daniel Jacobowitz
f the learning curve, I feel optimistic. To an extent the progress has
to be a bit slow because we are looking at the new Fortran standard and
thinking about the best way to add features.
Cheers,
Daniel.
--
I'm not overweight, I'm undertall.
int b;
public:
Fred() : b(0), a(0) { }
};
I think the next step will be to suppress the warning if both the
members that the message is about are initialized with constant
values.
Best regards,
Daniel
Index: gcc/cp/i
an think of to keep this noise is for purely
stylistic reasons. Somebody might think it is a stylistic problem to
initialize members backwards. But then -Wreorder should also warn
about common assignments and I doubt anybody wants that.
Best regards,
Daniel
2011/7/29 Richard Guenther :
> 2011/7/29 Daniel Marjamäki :
>> Hello!
>>
>>> Why doesn't it matter in this case but it matters when the initializer
>>> are non-constant?
>>
>> It doesn't matter because the program will behave the same n
u could call it -Wreorder=relevant or
> somesuch.
>
>
Thanks.
In my humble opinion the -Wreorder=nonconst and -Wreorder=any sounds ok.
> I want to know the mem-initializers are in the wrong order ASAP so I can
> correct them immediately, not when I change the initializer to a non-constant.
ok I understand.
Best regards,
Daniel
Yes. It sounds unlikely. But not impossible of course. I could also
make sure the member variables are POD types before I inhibit the
warning. I just have no idea how I check if a member is POD. But I
could investigate this.
I think, this will still remove most of the -Wreorder warnings that I get.
Best regards,
Daniel
> What if the object being constructed has only POD-type members with constant
> initializers but is declared volatile
I don't understand really... but it doesn't matter, I give up.
s_signal_frame.c;hb=HEAD
>
> I'd also be interested if there are better approaches to detect them. :)
There aren't better ways - this is pretty much the standard for
on-stack signal frames :-)
I thought we used a handler in GLIBC that was properly annotated,
nowadays, but I might be mistaken.
--
Thanks,
Daniel
issue or wouldn't mind taking a quick look
at the differences between these 2 versions to help us cherry-pick the
exact fix, it would be much appreciated.
Here is the diff between the two versions:
http://dev.laptop.org/~dsd/20110924/binutils-2.21.51.0.8-to-binutils-2.21.51.0.9.diff
Thanks,
Daniel
On Sat, Sep 24, 2011 at 1:26 PM, Daniel Drake wrote:
> I have identified that binutils-2.21.51.0.9 is the last binutils
> version that reproduces the problem, binutils-2.21.52.0.1 is fine.
That was a typo, sorry.
binutils-2.21.51.0.8 reproduces the crash
binutils-2.21.51.0.9 works fin
On Sat, Sep 24, 2011 at 8:37 PM, Ian Lance Taylor wrote:
> Daniel Drake writes:
>
>> We have found a ld segfault that occurs early in the gcc compile
>> process - the first time it tries to link cc1. This is testing on
>> armv5tel.
>
> Issues with the GNU binutil
This message is primarily a suggestion -- while the GNU compilers
already do a strong job on threading via OpenMP, I would very much like
to see upcoming GNU compilers support the new OpenACC directives for
accelerator-based computing (e.g. GPUs and the upcoming MICs).
Thanks for everything yo
On Thu, Jul 16, 2009 at 5:00 AM, Li Feng wrote:
> Hi Richard,
> On 7/16/09, Richard Guenther wrote:
>> On Thu, Jul 16, 2009 at 1:15 AM, Tobias
>> Grosser wrote:
>>> On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
On Wed, Jul 15, 2009 at 10:46 PM, Richard
Guenther wrote:
>
sfully pick up files from another
directory?
--
Daniel Jacobowitz
CodeSourcery
On Fri, Aug 21, 2009 at 5:37 AM, Steven Bosscher wrote:
> On Fri, Aug 21, 2009 at 10:52 AM, Laurynas
> Biveinis wrote:
BTW, it does not deal with types that in some instances have variables
allocated in proper GC way (with a path from GC root) and in some
instances not. Fixing these
My guess, witjout seeing the testcase.
In ccp_initialize we have:
for (i = gsi_start_bb (bb); !gsi_end_p (i); gsi_next (&i))
{
gimple stmt = gsi_stmt (i);
bool is_varying = surely_varying_stmt_p (stmt);
if (is_varying)
{
tree d
Hi,
I have already finished CPU port named RICE. The previous version
I did is on gcc 4.0.2. it can be compiled. Now I wanna move it to
v4.3.0. I added the config script just as the CRX architechture.
But when run the configure,
export TARGET=rice-elf
export PREFIX=/usr/local/cross/$TARGE
>
> You've got to get in there with gdb and find out why
> compute_frame_pointer_to_fb_displacement()
> is erroring. There's no way to avoid this.
>
Thank you.
But I don't know how. I mean which execute file, even I can't find the
"conftest.c" file.
Sorry for asking this simple question.
2009/9/21 sumanth :
> Hi ,
> Follow this wiki " http://gcc.gnu.org/wiki/DebuggingGCC"; to know how to
> debug gcc.
> As far as I know compute_frame_pointer_to_fb_displacement is the
> displacement between your
> frame pointer and the frame base ( mostly stack pointer's location after
> yo
2009/9/21 Andrew Haley :
> daniel tian wrote:
>> 2009/9/21 sumanth :
>>> Hi ,
>>> Follow this wiki " http://gcc.gnu.org/wiki/DebuggingGCC"; to know how to
>>> debug gcc.
>>> As far as I know compute_frame_pointer_to_fb_displacement i
d out where to look for a functional version of the gcc
> cross compiler for this cpu.
If you can't build GCC for your target, I suggest you either use a
help list for that purpose (gcc-help or the crosstool or buildroot
lists), or find a pre-compiled ARM Linux toolchain.
--
Daniel Jacobowitz
CodeSourcery
Thank you. I fixed the error. it caused by macro:
#define ELIMINABLE_REGS \
{\
{ARG_POINTER_REGNUM,FRAME_POINTER_REGNUM}, \
{ARG_POINTER_REGNUM,STACK_POINTER_REGNUM}, \
{FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} \
}
because everytime when gcc check the frame_pointer_need
Hi,
When I build gcc first time this which the configure parameter is like this:
../rice-gcc-4.3.0/configure --target=$TARGET --prefix=$PREFIX
--enable-languages=c --without-headers --with-newlib --with-gnu-as
--with-gnu-ld --disable-multilib --disable-libssp
Binutils is ok and install in the $
Sorry, I just found and fixed the bug. the config.host file in /libgcc/.
Sorry.
Hi:
Do I have to write the DImode operations on my *.md target description file?
Now I build my gcc first, there is an error on libgcc2.c. which is
an __muldi3 function.
The error information is:
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function __muldi3:
../../../rice-gcc-4
rror: #error "expand the table"
Did I do something wrong?
Please give me some advice.
Thank you very much.
daniel
ch.
Best wishes.
daniel.
how to make a break point in emit_move_isn, expr.c. Because the
expr.c file doesn't appear in the xgcc file. (I debug it with
insight.)
So anybody also meet the same problem? and how to slove it.
Thank you very much.
daniel
Sorry, Dove, I just gotta the solution to debug the cc1. Dove told me
the link, and I just missed. Now I checked. So sorry, I ask the stupid
question again.
But the former question, I am still puzzled.
Thanks.
pecified.
Any body who can help me.
Thank you very much.
daniel.
Thanks.
But how to debug cc1. Because now I port the gcc to my RISC target.
But when build the libgcc2.c. Some error occurred. So i have to debug
it.
Any advice about how to debug?
gdb --args $(./xgcc -###
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/
-B/usr/local/cross/rice-elf
2009/9/28 Basile STARYNKEVITCH :
> daniel tian wrote:
>>
>> Thanks.
>> But how to debug cc1. Because now I port the gcc to my RISC target.
>> But when build the libgcc2.c. Some error occurred. So i have to debug
>> it.
>> Any advice about how to debug?
&
still need to fix them.
Thanks for all your guys.
Best regards.
daniel
Hi Dave:
when I build the libgcc2.c, an unrecognizable RTL exist. Its about subreg.
Here is the info:
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__mulvsi3':
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:169: error: unrecognizable insn:
(insn 24 26 25 3 ../../../rice-gcc-4.3.0
Hi:
Yeah. You are right. Here is another RTL unrecognized. It happened
after reload.
(insn 749 156 147 22 (set (reg:HI 5 R5)
(subreg:HI (mem/c:SI (plus:SI (reg/f:SI 15 R15)
(const_int 108 [0x6c])) [19 d0+0 S4 A32]) 0)) -1 (nil))
I traced the lots of functions like: r
here are some information from the libgcc2.c.176r.greg. (BTY: the
error happened when cc1 build the libgcc2.c)
Reloads for insn # 147
Reload 0: reload_out (SI) = (reg/v:SI 99 [ __d0 ])
GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg/v:SI 99 [ __d0 ])
reload
Hi,
Thanks for your guys advice. Now the gcc is built succeed first
time(without headers).
Now I have to keep going for newlib.
Thanks very much.
" links at the above
> URLs) these appear to have genuinely originated at rt.gnu.org via the web
> interface:
Isn't this more likely the RT admins closing spam reports?
--
Daniel Jacobowitz
CodeSourcery
lp.
Best Wishes.
daniel
On Wed, Oct 07, 2009 at 04:29:29PM +0200, Basile STARYNKEVITCH wrote:
> I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c
It sounds to me like this confusion comes from "LTO plugins". Isn't
it just "LTO plugin"? That is, a specific pl
eally aimed at compiler developers. I think we would
benefit from more "what is the compiler doing to my code" options
(producing "note:"); things like which functions were inlined, which
loops unrolled. We do already have this for vectorization.
--
Daniel Jacobowitz
CodeSourcery
hanks.
daniel.
ut problem is HOW I could avoid this error.
Thanks.
daniel
2009/10/12 Joern Rennecke :
> Quoting daniel tian :
>
>> hi, everyone:
>> I have ported the gcc to new RISC chip. But when I build the
>> newlib with it, the gcc crashed in simplify-rtx.c.
>> error message is like this:
>>
>> ../../../../../ne
I would like to accepted only register and force all const_int
operand into register first.
Obviously, this may generate low efficiency code compared with your solution.
I still can't get a clear mind with step3. I may need take a while to
think about it.
I am a newcomer. :)
Thanks for your guys advice.
Best wishes.
daniel.
o put them into a separate
> file so the linker won't produce undefined references when they are not
> actually used by lto1.
Yes. Take a look at config/arm/arm-c.c, which does not go into
libbackend.a.
--
Daniel Jacobowitz
CodeSourcery
good idea.
Does any body also meet this problem?
Or I have to edit the gas source code.
Thanks for your guys help.
daniel
nostics are only of
> limited use without (say) #pragma unroll.
Not too limited, I'd say. I've seen a lot of developers willing to
mutilate their critical loops to accomodate the compiler.
--
Daniel Jacobowitz
CodeSourcery
On Mon, Oct 12, 2009 at 5:20 PM, Jason Merrill wrote:
> On 10/12/2009 05:17 PM, Andrew Pinski wrote:
>>
>> That seems like a huge bug in git-svn because we already use multiple
>> directory levels under branches. Hint ibm and redhat and debain.
>
> Yep, that's why I said "expand". I've thought a
other
> functions are not considered to be called once, perhaps a visibility
> issue. We also should say what limit was reached on inlining hlprog.
Maybe because of whatever did that cloning?
--
Daniel Jacobowitz
CodeSourcery
#x27;t know what the relationship between "collect2" and
"ld". It seems they do have some connections between them.
Thanks very much.
Best wishes.
daniel
his?
>
> The color that spells -fuse-linker-plugin seems better, in line
> with other options. How it's implemented, especially regarding
> having to ignore it in middle-end is unimportant wrt. spelling,
> IMVHO.
I agree with H-P.
--
Daniel Jacobowitz
CodeSourcery
ling for other vector sizes.
> >3) Switch to the new mangling
>
> I vote for 2.
Does anyone know of another relevant compiler? What does it do?
For instance, if someone can hand me a test case, I could check how
ARM's compilers mangle it (or don't).
--
Daniel Jacobowitz
CodeSourcery
Hi,
I have a problem about function call insn.
in "CALL @LABEL", only can jump backward/forward 32k SPACE. So
if it overflows, the function symbol_ref could move a register, then
"CALL Ri" (i represent 0 ~ 15).
But the question is gcc doesn't know the function symbol_ref 's
address
1001 - 1100 of 2004 matches
Mail list logo
