https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
--- Comment #5 from Martin Uecker ---
Am Freitag, dem 08.11.2024 um 14:22 + schrieb rguenth at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
>
> Richard Biener changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117145
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #9 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117245
--- Comment #6 from Martin Uecker ---
The commit causing this was like this where the middle end code was removed,
which then exposed the cases where the FE did not emit DECL_EXPR correctly.
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=42d16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117245
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98623
--- Comment #3 from Martin Uecker ---
PATCH https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657253.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87588
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767
--- Comment #7 from Martin Uecker ---
I wonder whether there should be a warning when a declaration has the "const"
attribute, but the actual definition does not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767
--- Comment #4 from Martin Uecker ---
You are right about both. It gets miscompiled also with side effects and if you
are remove the forward declaration, you get:
:10:21: warning: initialization makes '__attribute__((const))'
qualified functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #8 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663123.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #7 from Martin Uecker ---
(In reply to Peter Damianov from comment #6)
> Another testcase:
> not an ICE, but I think rejects-valid
> ```
> typedef void f(struct s1);
> struct s1 {
> int f1;
> };
> typedef void f(struct s1);
> ```
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #5 from Martin Uecker ---
Fix being tested.
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 58b2724b39e..ba6d96d26b2 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -1686,8 +1686,11 @@ tagged_types_tu_compatible_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #5 from Martin Uecker ---
Sorry, mixed this up with the other bug. Here I would say the behavior is
correct as specified in ISO C23. Note that incomplete structs could be
completed later also before ISO C23. But incomplete struct t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #4 from Martin Uecker ---
Although the new example doesn't crash and the error I get seems correct to me.
What is the problem you see here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #4 from Martin Uecker ---
I will look at this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46073
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116456
Bug ID: 116456
Summary: initialization of auto / __auto_type variable at file
scope with compound literal with const
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116284
Bug ID: 116284
Summary: incorrect classification of zero-sized array as
variably modified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98539
--- Comment #3 from Martin Uecker ---
Another symptom is the incorrect warning we get here:
void foo(char (*a)[*], int (*x)[*]);
void foo(char (*a)[*], int (*x)[sizeof *a]);
:3:30: warning: mismatch in bound 1 of argument 2 declared as 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116193
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116141
Bug ID: 116141
Summary: ICE with conditional operator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115515
Bug ID: 115515
Summary: constexpr ICE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177
--- Comment #5 from Martin Uecker ---
If we do want to constrain the type, we should make them incompatible at the
language level. Aliasing is secondary. From a safety perspective, it is always
safer to allow aliasing, because the optimizer bre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157
--- Comment #2 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652669.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177
Martin Uecker changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177
Bug ID: 115177
Summary: incorrect TBAA for derived types involving hardbool
types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157
Bug ID: 115157
Summary: incorrect TBAA for derived types involving enum types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114831
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959
--- Comment #2 from Martin Uecker ---
The GCC FE has all the necessary logic to compute type compatibility and this
could easily be adapted to compute equivalence classes and then set a
TYPE_CANONICAL. All function types in the same class would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959
Bug ID: 114959
Summary: incorrect TBAA for drived types involving function
types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #30 from Martin Uecker ---
Am Donnerstag, dem 18.04.2024 um 11:57 + schrieb jakub at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
>
> --- Comment #29 from Jakub Jelinek ---
> (In reply to uecker from c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #19 from Martin Uecker ---
It would still work for other arguments that are used in the active branch, but
not arguments you may not use in active branch or other subexpressions not used
in the active branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
--- Comment #13 from Martin Uecker ---
A C compiler has to diagnose all constraint violations. Alternatively, it could
also reject the program with an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
--- Comment #11 from Martin Uecker ---
A conforming C compiler has to diagnose all violations of constraints with the
same correct type of x in all branches (not the type it would have in another
context where a different is taken).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114727
Bug ID: 114727
Summary: ICE with c23 with aligned attribute and .-g
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114713
Bug ID: 114713
Summary: incorrect TBAA for struct with flexible array member
or GNU zero size
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
Martin Uecker changed:
What|Removed |Added
Resolution|FIXED |---
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #20 from Martin Uecker ---
(In reply to Martin Uecker from comment #18)
> >
> > + TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> > As has been discussed, this is wrong, it should have been
> > TYPE_CANONICAL (x) = build_qualified_ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #18 from Martin Uecker ---
>
> + TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> As has been discussed, this is wrong, it should have been
> TYPE_CANONICAL (x) = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS
> (x));
> or so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Martin Uecker changed:
What|Removed |Added
Attachment #57874|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #15 from Martin Uecker ---
Created attachment 57874
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57874&action=edit
patch
Tentative patch for the fix that makes the incomplete types have structural
equivalence at the beginni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #14 from Martin Uecker ---
(In reply to Jakub Jelinek from comment #12)
> Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL
> TYPE_CANONICAL is just an optimization to speed up type comparisons (but it
> seems c-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
Martin Uecker changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
--- Comment #3 from Martin Uecker ---
Created attachment 57834
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57834&action=edit
patch
Tentative patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
Bug ID: 114361
Summary: ICE with c23 when creating mutually nested and
compatible types with statement expressions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113879
Bug ID: 113879
Summary: missed optimization - not exploiting known range of
integers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113878
Bug ID: 113878
Summary: missed optimization with sanitizer and signed integer
overflow
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438
--- Comment #5 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644124.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263
Bug ID: 113263
Summary: ICE for invalid code for compound literal and type
definition in return type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488
--- Comment #10 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639961.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #9 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112791
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
--- Comment #9 from Martin Uecker ---
(In reply to Richard Biener from comment #8)
> (In reply to uecker from comment #7)
>
> > >
> > > Note that even without LTO when you enable inlining you'd expose two
> > > different structures with two di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
--- Comment #5 from Martin Uecker ---
It works (and is required to work) for other types, e.g.
[[gnu::noinline,gnu::noipa]]
int foo(void *p, void *q)
{
int n = 5;
int (*p2)[n] = p;
(*p2)[0] = 1;
bar(q);
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
Bug ID: 112716
Summary: LTO optimization with struct of variable ssize
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112429
Bug ID: 112429
Summary: Wnonnull should warn for multi-dimensional arrays
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428
Bug ID: 112428
Summary: Wnonnull outputs wrong type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #11 from Martin Uecker ---
This is one possible way to read it. But as written, I think one can easily
understand it the other way, because calloc never mentions requested total size
but only about space for an array of objects of s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #9 from Martin Uecker ---
(In reply to jos...@codesourcery.com from comment #7)
> I believe "size requested" refers to the product nmemb * size in the case
> of calloc, so getting the arguments the "wrong" way round does not affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #20 from Martin Uecker ---
Ah, this is how it works. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #18 from Martin Uecker ---
I think this can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #6 from Martin Uecker ---
For reference, this is were the revised wording in C comes. This is
intentional. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #16 from Martin Uecker ---
I agree that the C++ should have this warning as well, although it seems less
important there. This would be an enhancement request for the C++ FE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #14 from Martin Uecker ---
"I think calloc is available in C++, so the warning is wrong."
I am happy to revise the warning if it is wrong or annoying, but I do not
understand what C++ has to do with this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #4 from Martin Uecker ---
Interesting. But independently of alignment, the description of calloc makes it
clear that it allocates an array of nmemb objects of size x. So in any case I
think the code should be changed accordingly, wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #2 from Martin Uecker ---
I don't think this is correct. The requirement is "The pointer returned if the
allocation succeeds is suitably aligned so that it may be assigned to a pointer
to any type of object with a fundamental align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
Bug ID: 112364
Summary: calloc used incorrectly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #12 from Martin Uecker ---
I filed a bug for libfortran:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #11 from Martin Uecker ---
In this case this is by design because the size of an element should be second
argument to calloc. ("The calloc function allocates space for an array of nmemb
objects, each of whose size is size.")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Martin Uecker changed:
What|Removed |Added
Attachment #56490|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Martin Uecker changed:
What|Removed |Added
Attachment #56489|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #4 from Martin Uecker ---
Created attachment 56489
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56489&action=edit
patch
This should fix it. I am running some tests and will commit this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #3 from Martin Uecker ---
Thanks for reporting. I will fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98608
--- Comment #3 from Martin Uecker ---
PATCH (but unclear about n == 0)
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/634896.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70954
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
--- Comment #7 from Martin Uecker ---
Am Mittwoch, dem 25.10.2023 um 11:08 + schrieb siddhesh at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
>
> --- Comment #6 from Siddhesh Poyarekar ---
> So basically,
>
> __b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #25 from Martin Uecker ---
I agree that they are not idiomatic C++ and that there exist good reasons why a
programmer may want to avoid them (including standards compliance). But code
not being idiomatic is not a terrible good reas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #22 from Martin Uecker ---
There may be many good reasons to prefer std::vector over VLAs in C++ but
security and safety is not one of them. There are plenty of CVEs caused by
std::vector out-of-bounds accesses. The question is whet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #20 from Martin Uecker ---
And what alternative do you think is fundamentally safer than VLAs?
VLAs know their bound. Thus, they integrate with _FORTIFY_SOURCE, and UBSan
bounds checking. Also UBSan address checking at run-time. At
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #16 from Martin Uecker ---
I do not think -Wall should warn about GNU extensions when used with
-std=gnu++XX in C++ and I think it is annoying that clang does it now. It only
drives people to use alloca or other alternatives with wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #8 from Martin Uecker ---
There are certainly other similar portability issues, e.g.:
enum : long { X = 0xUL };
https://godbolt.org/z/hKsqPe9c1
BTW: Are there better examples where we have similar build failures also in
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #6 from Martin Uecker ---
Adding a note is a good idea, but it doesn't really solve the issue. The
problem I see is that somebody developing on x86-64 does not get a warning that
the code is not strictly conforming and then it fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #2 from Martin Uecker ---
On i386 1. / 3. is computed with higher precision than double and then the
initializer changes the value which is a contraint violation in C23. But
whether this happens or not depends on the architecture,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
Bug ID: 111808
Summary: [C23] constexpr
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
--- Comment #8 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632999.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
--- Comment #7 from Martin Uecker ---
Created attachment 56075
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56075&action=edit
patch adding error external / internal mismatch of functions
Untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #48 from Martin Uecker ---
Indicating a null terminated string should certainly use a different attribute
name.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71219
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109021
--- Comment #6 from Martin Uecker ---
Note that I do not propose to add variably modified types to C++. This would
indeed be a major extension. I simply propose to ignore the size expressions
in C headers as a usability improvement. My patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109021
--- Comment #4 from Martin Uecker ---
Sorry, how can an enhancement request that addresses a real C/C++ compatibility
problem be marked "resolved invalid" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84510
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #56 f
1 - 100 of 268 matches
Mail list logo
