https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #15 from Jerry DeLisle ---
(In reply to Matt Thompson from comment #14)
> Never mind. I'll send attachment to Jerry offline. It's too big for here.
Got it. It works quite well for our purposes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #11 from Jerry DeLisle ---
I am able to run your reproducer and I can see the increasing times as the
number of modules goes up. I am curious if you could randomize the subroutine
names? These appear fairly repetitive and I wonder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #8 from Jerry DeLisle ---
Martin or Matt,
Can you test the following variation to see if you get better results.
return st;
}
retval = NULL;
if (c <= 0)
retval = find_symbol (st->left, name, module, generic);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2024-04-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
--- Comment #6 from Jerry DeLisle ---
Created attachment 57965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57965=edit
Preliminary patch to fix several issues.
The attached patch is very preliminary and appears to fix the X format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
Jerry DeLisle changed:
What|Removed |Added
Status|REOPENED|NEW
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
Jerry DeLisle changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744
Bug 56744 depends on bug 107068, which changed state.
Bug 107068 Summary: Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #33 from Jerry DeLisle ---
(In reply to Tobias Burnus from comment #30)
> (In reply to rguent...@suse.de from comment #29)
> > Might be for \r\n line endings?
>
> New lines are handled slightly differently – and \f and \v don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #32 from Jerry DeLisle ---
(In reply to Tobias Burnus from comment #28)
> Created attachment 57896 [details]
> Testcase
>
--- snip ---
> I think we need at least an "|| c == '\t'"; I guess '\r' isn't really
> required here, or is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897
Jerry DeLisle changed:
What|Removed |Added
CC||urbanjost at comcast dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |DUPLICATE
|NEW
CC||jvdelisle at gcc dot gnu.org
Last reconfirmed||2024-04-07
--- Comment #1 from Jerry DeLisle ---
Here is a fix. It wiggles on about 5 test cases that will need to be adjusted.
diff --git a/gcc/fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #37 from Jerry DeLisle ---
Created attachment 57855
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57855=edit
Preliminary patch to address some incorrect behavior
This attached patch, gives some better results for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #36 from Jerry DeLisle ---
Created attachment 57854
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57854=edit
Modified extended test case
I modified the extended test case so I could review this and summarize.
Currently this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
--- Comment #9 from Jerry DeLisle ---
The following trivial patch changes gfortran behavior and regression tests Ok
on x86_64.
I will see if I can come up with a test case to catch this.
diff --git a/libgfortran/io/file_pos.c
at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
CC||jvdelisle at gcc dot gnu.org
--- Comment #8 from Jerry DeLisle ---
Thankyou for information, I will take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106295
--- Comment #7 from Jerry DeLisle ---
I don't think that is a bad idea. I realize that this comes up often enough to
consider some solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #21 from Jerry DeLisle ---
The following may be a helpful read.
https://www.ibm.com/docs/en/openxl-fortran-aix/17.1.2?topic=formatting-value-separators
I am auditing our list_read.c code for the various types. The NULL read plays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #20 from Jerry DeLisle ---
Some additional information from the 2023 standard.
13.10.3.1List-directed input forms
8 If the next effective item is default, ASCII, or ISO 10646 character and
• the character sequence does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #17 from Jerry DeLisle ---
(In reply to Jeffrey A. Law from comment #16)
> Per c#12, c#13, c#14 & c#15, dropping the regression marker, but leaving
> open.
Interestingly, the remaining part of this bug is also a regression, it just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #15 from Jerry DeLisle ---
(In reply to Tobias Burnus from comment #14)
--- snip ---
> The question is whether the following show give an error as shown above:
> real :: x(3)
> character(len=1) :: s
> ...
> write(99, '(a)')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 105456, which changed state.
Bug 105456 Summary: Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Bug 105361 depends on bug 105456, which changed state.
Bug 105456 Summary: Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #33 from Jerry DeLisle ---
(In reply to Tobias Burnus from comment #32)
> See PR114304 for an issue that was caused by the fix in comment 27.
Reverted portion of offending commit to fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #11 from Jerry DeLisle ---
Created attachment 57676
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57676=edit
Proposed patch
This patch fixes the issue by reverting the troublesome hunk and regression
tests OK on x86_64. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #9 from Jerry DeLisle ---
Patch on comment #8 breaks all sorts of things. Not so obvious. I will try
reverting the original hunk from pr105473 and then work from there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727
--- Comment #7 from Jerry DeLisle ---
(In reply to Thomas Henlich from comment #6)
--- snip ---
> Just some thoughts:
>
> Have you tried "%LA" for long double?
>
> Have you tried quadmath_snprintf
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727
--- Comment #5 from Jerry DeLisle ---
I have been studying this a bit by looking at the 2023 std and functionality of
printf().
Specifically printf() provides the 'A' descriptor which can be used for float
(kind=4) and double (kind=8). It will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #31 from Jerry DeLisle ---
(In reply to john.harper from comment #30)
> Thank you!
>
I encourage folks to move to gcc/gfortran 13. However, if you need it on 12, I
can do so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #29 from Jerry DeLisle ---
Backported to 13 and closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #13 from Jerry DeLisle ---
Any luck getting a reduced case?
||2024-03-06
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
Ever confirmed|0 |1
CC||jvdelisle at gcc dot gnu.org
--- Comment #2 from Jerry DeLisle ---
Taking a quick look
at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #4 from Jerry DeLisle ---
So I don't lose it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
||jvdelisle at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #5 from Jerry DeLisle ---
I think this should be closed. Dont mix libraries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93550
--- Comment #4 from Jerry DeLisle ---
The LEADING_ZERO specifiers are now included in the 2023 standard, so away we
go! In support of lazy programmers lets make the compiler do it. ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
--- Comment #9 from Jerry DeLisle ---
--- snip ---
> % gfcx -o z a.f90
> a.f90:5:6:
>
> 5 | x%im = 42
> | 1
> Error: 'x' at (1) associated to expression cannot be used in
> a variable definition context (assignment)
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
--- Comment #2 from Jerry DeLisle ---
It looks like the 'selector' in this case is an expr.
The expr must be a pointer object or a 'designator'
A designator must be:
R901
designator
object-name
array-element
array-section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
--- Comment #7 from Jerry DeLisle ---
There two issues going on here. We do not interpret source code that is UTF-8
encoded. This is why in our current tests for UTF-8 encoding of data files we
us hexidecimal codes.
I will have to see what the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
--- Comment #6 from Jerry DeLisle ---
This is an interesting puzzle. I took the -fdump-tree-original output of
compiling the test case and edited out all except the initialization of the two
variables char1 and char2.
I lined these up so we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
--- Comment #4 from Jerry DeLisle ---
Created attachment 57504
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57504=edit
Proposed partial patch
Proposed patch for the original test case with a READ function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #16 from Jerry DeLisle ---
I think I was not being very clear when I opened pr113897. nX descriptors are
very similar to TR code and I meeantt to take care of those in the 113897. The
reason for the separate PR is that the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282
--- Comment #6 from Jerry DeLisle ---
$ gfc -Wall -Werror -pedantic pr83282.f90
pr83282.f90:1:4:
1 |write(*,'(aa)') "ab", "bc"
|1
Error: Unclassifiable statement at (1)
This is not very useful either. :o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282
--- Comment #5 from Jerry DeLisle ---
With -std=f95 we get:
$ gfc -std=f95 pr83282.f90
pr83282.f90:1:13:
1 |write(*,'(aa)') "ab", "bc"
| 1
Error: GNU Extension: Missing comma at (1)
pr83282.f90:2:17:
2 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
--- Comment #8 from Jerry DeLisle ---
After a bit of sleuthing it turns out that the '(' in the name was being
ignored and the comma in '(1,2)' was being treated as a delimiter. Since the
following '=' was not seen yet, the 2 was seen as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #11 from Jerry DeLisle ---
Having done all this, I found:
C8102 (R868) The namelist-group-name shall not be a name accessed by use
association.
What does this mean in the context of renamed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #9 from Jerry DeLisle ---
This seems to work:
/* Build the namelist object name. */
-
- string = gfc_build_cstring_const (var_name);
+ if (sym && !sym->attr.use_only && sym->attr.use_rename)
+string =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #8 from Jerry DeLisle ---
There is an assert just above the patch that implies that sym can be NULL if c
is not. With gdb I checked, and sure enough thats the failure point. I am
testing with sym included in the condition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #7 from Jerry DeLisle ---
Steve, I am getting a boatload of regressions on this. I wonder if something
in the sym structure needs to be guarded here. They appear to be segfaults. Can
you take a look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #6 from Jerry DeLisle ---
I obviously did not get to this last May. Will try now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
--- Comment #7 from Jerry DeLisle ---
Submitted for approval.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
--- Comment #6 from Jerry DeLisle ---
I have reapplied the patch in comment #3 and it regression tests fine and
appears to fix the issue. I have need to work up the test case and submit this
for approval.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
||2024-02-13
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jerry DeLisle ---
Adding to my list, but I do not see any priority needed for it.
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
This issue found while working on pr109358.
program tabs
implicit none
integer :: fd
open(newunit=fd, file="tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
Bug 85836 depends on bug 111022, which changed state.
Bug 111022 Summary: ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #36 from Jerry DeLisle ---
I was looking for my damnit doll until I got to your last post. Is this one
worthy of backport?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #11 from Jerry DeLisle ---
I am going to submit the attached patch to close this PR and open a new PR for
the lingering multiple tab edits in a row. The problem there is we have a
special case if we have different T, TL, and TR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #10 from Jerry DeLisle ---
To clarify. The following is the remaining issue that is not related to stream
I/O:
> program tabs
> implicit none
> integer :: fd
> open(newunit=fd, file="test.txt", form="formatted")
> write(fd,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #9 from Jerry DeLisle ---
Created attachment 57365
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57365=edit
Preliminary patch
The attached patch fixes the stream I/O related tabbing. This regression tests
fine. There is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
Jerry DeLisle changed:
What|Removed |Added
CC||nmm1 at cam dot ac.uk
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53962
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #28 from Jerry DeLisle ---
Created attachment 57260
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57260=edit
A final patch
This patch provides the necessary changes with only minor adjustment to
existing gfortran test cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #27 from Jerry DeLisle ---
(In reply to anlauf from comment #26)
> (In reply to Jerry DeLisle from comment #24)
> > Currently gfortran does the following:
> >
> > character(20) :: fmt
> > character(9) :: buffer
> > fmt =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #24 from Jerry DeLisle ---
Currently gfortran does the following:
character(20) :: fmt
character(9) :: buffer
fmt = "(1a1,d0.2,1a1)"
write(buffer,fmt) ">", 3.0, "<"
print *, buffer
fmt = "(1a1,e0.2,1a1)"
write(buffer,fmt) ">",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
--- Comment #16 from Jerry DeLisle ---
(In reply to Alexander Westbrooks from comment #15)
> Created attachment 57176 [details]
> Proposed Patch to fix PR82943, PR86148, PR86268
I am attempting to roll with this. Steve, do you know where the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #8 from Jerry DeLisle ---
(In reply to Steve Kargl from comment #7)
--- snip ---
> libgfortran is supposedly thread-safe and looking into
> flush_all_units() shows some unlocking and testing for
> locks. With 'print *,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223
--- Comment #3 from Jerry DeLisle ---
Created attachment 56990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56990=edit
Suggested patch including affected test cases
Regression tested OK. Three test cases affected.
$ git status
On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223
--- Comment #2 from Jerry DeLisle ---
(In reply to kargl from comment #1)
> Jerry can you take a look at this issue.
Will do. Minor tweak I hope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
1 - 100 of 2081 matches
Mail list logo
