https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #6 from Thomas Koenig ---
The machine is gcc220.fsffrance.org ; if anybody has an account there
and wants to peek into /home/tkoenig to look into more details, be my
guest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #5 from Thomas Koenig ---
Created attachment 49422
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49422=edit
Generated gimple-match.c
All the temporary files were generated by manually adding -save-temps
to the Makefile in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
Thomas Koenig changed:
What|Removed |Added
Target||x86_64-unknown-openbsd6.8
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #3 from Thomas Koenig ---
Created attachment 49421
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49421=edit
config.log from the main build directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #2 from Thomas Koenig ---
Created attachment 49420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49420=edit
Resulting assember file (which is incomplete)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #1 from Thomas Koenig ---
Created attachment 49419
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49419=edit
Preprocessed source of gimple-match.ii (compressed)
NCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 49418
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49418=edit
co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #9 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #7)
> So, can we use this for anything but modulo 3, or 5, or 17, or 257 (all of
> those have 2^32 mod N == 2^64 mod N == 2^128 mod N == 1)
I think so, too.
>
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
$ cat pure.f90
pure function foo(x) result (ret)
integer :: ret
integer, value :: x
x = x / 2
ret = x
end function foo
$ gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95037
--- Comment #5 from Thomas Koenig ---
Fixed in 10.2, 9.4 and 11.1 will have it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
--- Comment #13 from Thomas Koenig ---
(In reply to Bill Long from comment #12)
> Original submitter asking which GCC version(s) have / will have the fix.
10.2 already has been released with the fix. 9.4 and 11.1 will have it in when
they are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #5 from Thomas Koenig ---
OK, so here is a benchmark with its function names corrected. It also
includes one version (_v5) which is a bit faster.
(Note I increased the number of iterations to get more accuracy out
of the cycle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #4 from Thomas Koenig ---
Here's a complete program for benchmarks on x86_64, using Jakub's
functions (so they are indeed correct):
#include
#include
#include
#include
#include
#include
unsigned r3_128u_v2 (__uint128_t n)
{
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following two functions are equivalent:
unsigned r3_128u_v1 (__uint128_t n)
{
unsigned long a;
a = (n >> 64) + (n & 0x);
re
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=96168
Last reconfirmed||2020-10-16
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Currently, the decls for Fortran library procedures are inconsistent,
which causes, among other things, segfaults on Darwin for ARM
(PR96168).
We should fix them all. For maxval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92422
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Thomas Koenig changed:
What|Removed |Added
Component|target |bootstrap
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
Thomas Koenig changed:
What|Removed |Added
Component|fortran |bootstrap
--- Comment #7 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
--- Comment #4 from Thomas Koenig ---
Created attachment 49320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49320=edit
config.log from failing libgomp
OK, so that one isn't a bug.
I hope you don't mind if I put in the next failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
--- Comment #2 from Thomas Koenig ---
Created attachment 49319
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49319=edit
config.log from gmp subdirectory
Here it is.
For what it is worth, I now tried bootstrapping with CC=cc and CXX=c++,
NCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 49318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49318=edit
config.lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #9 from Thomas Koenig ---
WORKSFORME on OpenBSD 6.7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Thomas Koenig changed:
What|Removed |Added
Component|bootstrap |target
--- Comment #3 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #2 from Thomas Koenig ---
Created attachment 49316
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49316=edit
output from compilation that failed with -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #1 from Thomas Koenig ---
Created attachment 49315
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49315=edit
config.log from failed attempt
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
With PR 97302 out of the way (fixed by Tobias' patch in that PR),
compilation now fails with
ld: error: unable to find library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302
--- Comment #3 from Thomas Koenig ---
Comment on attachment 49313
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49313
configure.ac patch
Seems to work, at least the compilation is proceeding now.
Thanks for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302
--- Comment #1 from Thomas Koenig ---
Created attachment 49311
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49311=edit
Output from the attempt
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 49310
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49310=edit
config.log from the attempt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89256
--- Comment #2 from Thomas Koenig ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282#c1 for one
example how this could be done for small integers (base 10 in that
case). The solution with the precomputed tables is probably not feasible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282
--- Comment #1 from Thomas Koenig ---
And here is a version which uses two 64-bit numbers for calculation of he
sum of decimal digits as a benchmark for the division and modulo:
unsigned long digsum3 (myint x)
{
unsigned long ret;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Currently, gcc calls the (long and slow) division routines for 128-bit
integers twice when both the residual and the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97181
Thomas Koenig changed:
What|Removed |Added
Version|unknown |11.0
--- Comment #1 from Thomas Koenig
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following two programs are functionally equivalent:
$ cat v1.f90
program main
implicit none
integer, parameter :: ip = selected_int_kind(15)
integer
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following program is wrongly rejected. I don't find anything
wrong with it from my reading of the F2018 standard
||tkoenig at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Thomas Koenig ---
The loop
for (a = 20; a; a++) {
increases a, which is a char, beyond its value range, and then tests
against zero.
This is undefined behavior.
N4659
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96735
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96735
--- Comment #2 from Thomas Koenig ---
Checking out master instead of the branch I was on "fixed" things.
So, I guess may just be random timestamps in git, which do not
get updated correctly with contrib/gcc_update.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96735
--- Comment #1 from Thomas Koenig ---
(And yes, I did run contrib/gcc_update)
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 49095
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49095=edit
config.log from failed attempt
Current master is
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96469
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96469
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
What's checked at runtime in do_check_4.f90
PROGRAM test
IMPLICIT NONE
INTEGER :: i
DO i=1,100
CALL do_something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96319
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
--- Comment #5 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #4)
> so it is likely that this patch just started issuing a warning
> for a pre-existing bug in the front end.
That is indeed the case. Grepping for tmp in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
Thomas Koenig changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
--- Comment #3 from Thomas Koenig ---
Let's see what bisection brings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
Thomas Koenig changed:
What|Removed |Added
Target Milestone|9.4 |10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
Thomas Koenig changed:
What|Removed |Added
Summary|Reallocation on assignment |[10/11 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
--- Comment #21 from Thomas Koenig ---
(In reply to Tiziano Müller from comment #19)
> I have yet another (more complicated) case, but this time not reproducible
> with gcc-7.5, only with 9 and 10:
This is a different issue. I have opened PR
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504#c19 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96220
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #50 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #49)
> The second loop:
>
> .L3:
> leaq8(%rsp), %rdi
> callintent_in_
> movl%ebx, 8(%rsp)
> addl$1, %ebx
> cmpl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #49 from Thomas Koenig ---
(In reply to Tobias Schlüter from comment #48)
> Forgive me, I wasn't aware of this oversight which may have turned away
> people who could fix this for the past 6 years.
That didn't happen :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92628
--- Comment #5 from Thomas Koenig ---
Any progress in this direction? Should we revisit PR 67202
(maybe do this in trans-*), or maybe even it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Ever confirmed|0 |1
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
$ cat foo.f90
module f_global_vars_m
use, intrinsic :: iso_c_binding, sp => c_float, dp => c_double
implicit none
real(dp), bind(c) :: one= 1.0_dp, four= 4.0_dp !
dot gnu.org |tkoenig at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-07-16
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following is not flagged:
DOUBLE PRECISION X (1000)
DOUBLE PRECISION A
INTEGER NCP
NCP = 10
CALL XYZ (NCP, X, X (NCP + 1))
CALL XYZ (NCP, X (NCP+1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
--- Comment #10 from Thomas Koenig ---
(In reply to AJM from comment #8)
> If you really need to know, on the C side there is a struct with fields that
> match the order and size of the variables in the common statement / module
> declaration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678
Thomas Koenig changed:
What|Removed |Added
Summary|[9/10/11 Regression] ICE in |[9/10/11 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678
--- Comment #5 from Thomas Koenig ---
A somewhat smaller test case, which of course does nothing useful,
but still reproduces the ICE:
module mo_a
implicit none
type t_b
integer :: n = 0
integer :: nr = 0
character, pointer
in
|happening in previous |9.2/9.2.1 not happening in
|gfortran versions |previous gfortran versions
Target Milestone|--- |9.4
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
Thomas Koenig changed:
What|Removed |Added
Keywords|needs-bisection |patch
--- Comment #15 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95998
--- Comment #2 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #1)
> Is static in C/C++ equivalent of SAVE in fortran (at least in the context of
> gfc_typename)?
Yes.
> If yes, AFAIU the code the odd access to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96122
Thomas Koenig changed:
What|Removed |Added
Blocks||37336
--- Comment #3 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
--- Comment #10 from Thomas Koenig ---
... and thanks for the timely bug report!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
--- Comment #7 from Thomas Koenig ---
Two things: We should not warn about INTENT mismatches when
we artificially generate the prototypes, and we should set a
valid gfc_locus.
Both done with the attached patch.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
--- Comment #6 from Thomas Koenig ---
What we have here is, in gfc_check_externals0,
(gdb) call debug(def_sym->formal)
|| symbol: '_formal_0'
type spec : (INTEGER 4)
attributes: (VARIABLE ARTIFICIAL DUMMY)
|| symbol: '_formal_1'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
Thomas Koenig changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
--- Comment #3 from Thomas Koenig ---
(In reply to kargl from comment #2)
> I won't comment on the questionable programming idiom of placing
> a common block in a module, which kind of defeats the niceties of
> a module.
If somebody wants to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92913
--- Comment #4 from Thomas Koenig ---
The first part has now been fixed with the fix for PR 27318,
r11-1814-gcc9a9229285a26ac12bc8de53237ce9c4d42f867 .
The second test case, where interfaces are checked vs. interfaces,
subroutine sub_1()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #14 from Thomas Koenig ---
Created attachment 48852
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48852=edit
Patch which ought to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
--- Comment #13 from Thomas Koenig ---
In the last comment I meant -fdump-fortran-original, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
--- Comment #12 from Thomas Koenig ---
I don't have a debuggable source here at the moment, but I think there
may be a problem with implicit_pure, which was either introduced by
a patch in the range that Dominique provided (maybe for PR 85599?),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29670
Bug 29670 depends on bug 27318, which changed state.
Bug 27318 Summary: gfortran should warn if a interface does not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
--- Comment #8 from Thomas Koenig ---
Comment on attachment 48817
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48817
Minimal example to demonstrate the issue.
Hm, I cannot reproduce this because I do not have the hdf5 library
installed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
--- Comment #7 from Thomas Koenig ---
I can not test at the moment, that will have to wait for a few days.
A general comment:
In Fortran, functions exist to return a value. C-style „return an error status“
fit rather badly to the language,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #3 from Thomas Koenig ---
The problem is in the hash, only a single bit seems to be different:
+++ mod1.f90.004t.original 2020-06-30 07:14:25.582667830 +
@@ -105,7 +105,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95743
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #14 from Thomas Koenig ---
Because the version in bugzilla is set to 10.0, so I assumed it occurred there,
too.
Even better if it is not there.
301 - 400 of 3578 matches
Mail list logo
