The "#pragma once" directive can cause spurious "Multiple include guards may be
useful for:" messages.
$ cat bar.h
#pragma once
$ cat foo.c
#include "bar.h"
$ gcc -S -H foo.c
. bar.h
Multiple include guards may be useful for:
bar.h
--
Summary: #pragma once and -H
Product
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-02-27 01:20
---
*** Bug 43194 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-27 01:20 ---
*** This bug has been marked as a duplicate of 41818 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I'm building a cross toolchain for ultrasparc, and when I build the final gcc
(with a proper glibc 2.11.1 built), I get:
checking for C compiler default output file name... configure: error: in
`/tmp/nix-build-fg665ygndf0l90symznxdarn7cpffbhz-gcc-4.4.3-sparc64-unknown-linux-stage-final.drv-0/build
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-27 00:04 ---
Draft patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (Revision 157097)
+++ gcc/fortran/resolve.c
@@ -4902,10 +4902,11 @@ check_
Found by Damian - and ask at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f5ec99089ea72b79#
gfortran rejects
call type%abstract_parent%tbp()
with
Error: Base object for type-bound procedure call at (1) is of ABSTRACT
type 'abstract_parent'
As long as "abstract_parent
--- Comment #10 from burnus at gcc dot gnu dot org 2010-02-26 23:19 ---
Created an attachment (id=19972)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19972&action=view)
Next try - regtested, but not poofread
--
burnus at gcc dot gnu dot org changed:
What|Remove
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-02-26 23:12
---
This should be fixed. Reopen if not.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-02-26 23:10
---
Subject: Bug 43096
Author: ebotcazou
Date: Fri Feb 26 23:10:24 2010
New Revision: 157102
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157102
Log:
PR ada/43096
* tree-ssa-alias.c (same_ty
--- Comment #4 from hjl dot tools at gmail dot com 2010-02-26 22:57 ---
(In reply to comment #3)
> Created an attachment (id=19971)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19971&action=view) [edit]
> patch
>
> HJL, could you test this patch in your setup?
>
> I am testing i
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-26 22:52 ---
(In reply to comment #2)
>&& has_default_initializer (sym->ts.u.derived))
s/)//
> + && (gfc_notify_std (GFC_STD_F2008, "Fortran 2008: Implied SAVE for "
s/(//
> + "the default in
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-26 22:28 ---
Created an attachment (id=19971)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19971&action=view)
patch
HJL, could you test this patch in your setup?
I am testing in the compile farm right now.
--
http://gc
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-26 22:26 ---
Index: resolve.c
===
--- resolve.c (Revision 157097)
+++ resolve.c (Arbeitskopie)
@@ -8938,12 +8938,11 @@
&& !sym->ns->save_all && !sym->attr.
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-26 22:13 ---
Do you get errors for direct2 and direct2s?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43192
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-26 21:29 ---
Mine. Something must be broken in my setup because I do test with -m32.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
On Linux/ia32, revision 157097 gave:
FAIL: gcc.dg/990506-0.c (test for excess errors)
FAIL: gcc.dg/990506-0.c reminder message (test for errors, line 6)
FAIL: gcc.dg/cpp/pragma-1.c (test for excess errors)
FAIL: gcc.dg/cpp/pragma-1.c reminder message (test for errors, line 9)
FAIL: gcc.dg/cpp/prag
--- Comment #9 from dominiq at lps dot ens dot fr 2010-02-26 21:07 ---
Additional failures (both -m32 and -m64)
FAIL: gfortran.fortran-torture/execute/data.f90 execution, -O0
FAIL: gfortran.fortran-torture/execute/data.f90 execution, -O1
FAIL: gfortran.fortran-torture/execute/data.f
--- Comment #6 from jason at gcc dot gnu dot org 2010-02-26 20:47 ---
The patch looks good. I don't think we want to add an extension for this; if
we need an additional feature, it should be standardized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42805
--- Comment #7 from rguenther at suse dot de 2010-02-26 19:56 ---
Subject: Re: [4.5 regression] miscompilation of ACATS c37105a
at -O2
On Fri, 26 Feb 2010, ebotcazou at gcc dot gnu dot org wrote:
>
>
> --- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-26 17:46
> --
--- Comment #8 from dominiq at lps dot ens dot fr 2010-02-26 19:37 ---
First failures
FAIL: gfortran.dg/auto_dealloc_1.f90 -O scan-tree-dump-times original
"__builtin_free" 5 <- should be 4
FAIL: gfortran.dg/common_resize_1.f -O0 execution test
FAIL: gfortran.dg/common_resize_1
--- Comment #7 from dominiq at lps dot ens dot fr 2010-02-26 19:27 ---
> Change attr.is_main_program to sym->ns->proc_name->attr.is_main_program
This change fixes most of the failures I have seen. Is
if (TREE_STATIC (decl) && !sym->attr.use_assoc
&& (sym->attr.save || sym->att
--- Comment #6 from changpeng dot fang at amd dot com 2010-02-26 19:06
---
>
> Actually it is a totally different case. Please file a new bug with that
> case;
> though there might already be a bug about that one.
>
I could not see the difference even though j is not a compile-tim
--- Comment #4 from sje at cup dot hp dot com 2010-02-26 19:05 ---
Was the patch from comment #3 ever sent to gcc-patches? I couldn't find it. I
did see earlier discussions about some other patches but the patch in comment
#3 seems to have been put here after those discussions.
I test
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-26 18:55 ---
(In reply to comment #4)
> Here is another similar case but more general.
Actually it is a totally different case. Please file a new bug with that case;
though there might already be a bug about that one.
--
h
--- Comment #4 from changpeng dot fang at amd dot com 2010-02-26 18:53
---
Here is another similar case but more general. We know that a(j) and a(i)
never access the same memory location. intel ifort can vectorize this
triangular
loop:
do 10 j = 1,n
do 20 i = j+1, n
--- Comment #12 from wirawan0 at gmail dot com 2010-02-26 18:50 ---
I'm positive that the libraries used for compilation and running are the same.
The package was built on my own computer. I'm posting this bug at gentoo
bugzilla (http://bugs.gentoo.org/show_bug.cgi?id=306833) . Still wai
--- Comment #5 from danglin at gcc dot gnu dot org 2010-02-26 18:15 ---
This bug was introduced in revision 147980:
2009-05-29 Martin Jambor
* tree-sra.c: New implementation of SRA.
--
danglin at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-26 18:04
---
I see that you are around... ;)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-26 17:46
---
> We might be able to save the day with the help of TYPE_CANONICAL in this case
> since the size is fixed.
TYPE_CANONICAL is too strong, it will cause useless_type_conversion_p to return
true for conversions betw
--- Comment #11 from kargl at gcc dot gnu dot org 2010-02-26 17:36 ---
(In reply to comment #10)
> Created an attachment (id=19970)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19970&action=view) [edit]
> valgrind --leak-check=full output
>
> I attach this as a more verbose repor
--- Comment #5 from baldrick at gcc dot gnu dot org 2010-02-26 17:24
---
I was also surprised, because I couldn't see the relevance. To double check I
rebuilt one commit before (no crash) and at that commit (crash). That seems
pretty conclusive, especially as the testcase seems to fai
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-02-26 17:15
---
I'll fix the bug, but are you sure about the commit? It looks unrelated to the
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-26 17:11 ---
Thanks for the report. FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from manu at gcc dot gnu dot org 2010-02-26 17:10 ---
Subject: Bug 20631
Author: manu
Date: Fri Feb 26 17:09:29 2010
New Revision: 157096
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157096
Log:
2010-02-26 Manuel López-Ibáñez
PR c/20631
*
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-26 17:04 ---
Thanks for the report in any case. This will be FIXED in GCC 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
--- Comment #7 from manu at gcc dot gnu dot org 2010-02-26 17:03 ---
(In reply to comment #4)
> My employer does not permit employees to contribute to open source projects
> due
> to IP concerns. What's your second choice?
You could lobby your employer to change their policy. I am sure
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-26 17:03 ---
(In reply to comment #4)
> My employer does not permit employees to contribute to open source projects
> due
> to IP concerns. What's your second choice?
You could lobby your employer to change their policy. I am sure
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-26 16:56 ---
Subject: Bug 24577
Author: manu
Date: Fri Feb 26 16:56:09 2010
New Revision: 157095
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157095
Log:
2010-02-26 Manuel López-Ibáñez
PR c/24577
*
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-26 16:52 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-26 16:37 ---
(In reply to comment #4)
> The first obvious wrong code is for gcc/testsuite/gfortran.dg/streamio_6.f90:
> but without the patch a[100] is not intialized
> > static integer(kind=4) a[100];
In trans-decl.c:
if (T
--- Comment #5 from dominiq at lps dot ens dot fr 2010-02-26 16:29 ---
Another failing test is gcc/testsuite/gfortran.dg/data_char_2.f90:
without patch
< static character(kind=1) intstr[1:10] = "0123456789";
with patch
> static character(kind=1) intstr[1:10];
Note that in order
--- Comment #10 from wirawan0 at gmail dot com 2010-02-26 16:08 ---
Created an attachment (id=19970)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19970&action=view)
valgrind --leak-check=full output
I attach this as a more verbose report. Not sure if it is of any use.
--
htt
--- Comment #4 from pault at gcc dot gnu dot org 2010-02-26 16:06 ---
(In reply to comment #3)
> > by chance local changes which fix this issue?
> I will go back and confirm that the tree on my machine at work is clean.
No, it wasn't, so my comment was incorrect.
Cheers
Paul
--
--- Comment #9 from wirawan0 at gmail dot com 2010-02-26 16:06 ---
Here's a brief run with valgrind 3.5.0: I had to recompile glibc (2.10.1) with
"splitdebug" feature in Gentoo OS for it to work.
~/toys/gfortran/ch10 $ valgrind
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/f951 testme5.no
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-26 16:02 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-26 16:02 ---
Subject: Bug 43186
Author: rguenth
Date: Fri Feb 26 16:01:52 2010
New Revision: 157093
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157093
Log:
2010-02-26 Richard Guenther
PR tree-optimization/
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-26 15:59 ---
Subject: Bug 43190
Author: jakub
Date: Fri Feb 26 15:58:57 2010
New Revision: 157092
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157092
Log:
PR debug/43190
* function.c (used_types_insert):
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-26 15:56 ---
The reason for the two different VALUEs for the same thing here (where we have
just one normal bb) is that vt_add_function_parameters does
cselib_lookup/cselib_preserve_value calls after processing the last bb, so of
c
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-26 15:46 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
79-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r157079-install --program-prefix=r157079-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 201002
--- Comment #6 from hjl dot tools at gmail dot com 2010-02-26 14:49 ---
Fixed in 4.5.0.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|
--- Comment #5 from hjl at gcc dot gnu dot org 2010-02-26 14:49 ---
Subject: Bug 37074
Author: hjl
Date: Fri Feb 26 14:49:02 2010
New Revision: 157089
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157089
Log:
Add -mno-mmx to x86 in gcc.dg/torture/stackalign/stackalign.exp.
201
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-02-26 14:39
---
I don't think this test case is valid.
Unfortunately, the division function is not completely pure. If a division by
zero occurs, then a handler function may be invoked, which might cause the
contents pointed to
--- Comment #4 from dominiq at lps dot ens dot fr 2010-02-26 14:38 ---
The first obvious wrong code is for gcc/testsuite/gfortran.dg/streamio_6.f90:
The original dump without the patch shows
< static integer(kind=4) a[100] = {13, 9, 34, 41, 25, 98, 6, 12, 11, 44, 79,
3, 64, 61, 77, 5
--- Comment #3 from dominiq at lps dot ens dot fr 2010-02-26 14:30 ---
With the patch in comment #2, I see a dozen runtime failure on my tests. I'll
need some time to analyse them (I have to separate invalid codes that pass by
chance from valid code that are miscompiled).
So keep tuned!-
--- Comment #4 from ubizjak at gmail dot com 2010-02-26 14:24 ---
(In reply to comment #3)
MMX arguments are passed via %mm registers when __builtin_apply_args is used.
Touching %mm in any way will switch FP regstack to MMX mode, and since no emms
is emitted, reading %st will always ret
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-26 14:07 ---
The initial question is whether to implement these for easily reversible insns
in vt_initialize, or when a VALUE becomes dead because nothing uses it.
Implementing it in vt_initialize (add_stores and count_uses) would
--- Comment #3 from hjl dot tools at gmail dot com 2010-02-26 14:05 ---
gcc.dg/torture/stackalign/builtin-apply-4.c will
fail on x86-64 since -march=x86_64 will be added
by default since:
http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00664.html
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #7 from kaushik dot phatak at kpitcummins dot com 2010-02-26
13:55 ---
Created an attachment (id=19969)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19969&action=view)
Patch to generate bit instructions for H8 target and other minor enhancements
Patch to generate bit
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-26 13:35 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-26 13:34 ---
Subject: Bug 43188
Author: rguenth
Date: Fri Feb 26 13:34:38 2010
New Revision: 157088
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157088
Log:
2010-02-26 Richard Guenther
PR tree-optimization/
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-26 13:29 ---
For some reason we inline 8 recursive calls of foo resulting in a load of
loops that we all completely unroll. And in fact this is profitable but
very slow because we estimate induction variable computations to be o
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-26 13:20 ---
,,. but a duplicate
*** This bug has been marked as a duplicate of 32824 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-26 13:20 ---
*** Bug 43184 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-26 13:20 ---
So this is not invalid...
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from hjl at gcc dot gnu dot org 2010-02-26 13:18 ---
Subject: Bug 43175
Author: hjl
Date: Fri Feb 26 13:18:17 2010
New Revision: 157087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157087
Log:
Correct expand_vec_perm_blend in i386.c for V8HImode merge.
gcc/
2
--- Comment #5 from dodji at gcc dot gnu dot org 2010-02-26 12:58 ---
Created an attachment (id=19968)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19968&action=view)
Candidate patch
Here is what I think is happening, at least on gcc 4.5.
A/ The deleting dtor's DIE *is* being ge
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-26 12:40 ---
Small correction, VALUE 13:13 has initial location %edi, before it is
equivalenced to VALUE 2:2. So, at that point it is fine to have 13:13 as
cur_loc for VALUE 2:2, it is the same as having %edi there directly as cur
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-26 12:10 ---
So, the problem seems to be in the equivalencing of VALUEs. val_resolve does:
1659/* Map incoming equivalences. ??? Wouldn't it be nice if
1660 we just started sharing the location lists? Maybe a
1661 ci
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-26 11:25 ---
Created an attachment (id=19967)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19967&action=view)
gcc45-pr43190.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
// { dg-options "-gdwarf-2 -dA" }
// { dg-final { scan-assembler
"DW_TAG_structure_type\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"S\[^\\r\\n\]*DW_AT_name"
} }
// { dg-final { scan-assembler
"DW_TAG_typedef\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"T\[^\\r\\n\]*DW_AT_name" }
}
typedef struct S { int i; } *T;
#
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-26 11:05 ---
This has been transformed into PR43177 now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.5 |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-26 11:05 ---
This issue is fixed, there are other issues in vla-1.c unfortunately, but
IMNSHO it is better to track each issue separately.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-26 11:03 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-26 11:03 ---
Subject: Bug 43160
Author: jakub
Date: Fri Feb 26 11:02:39 2010
New Revision: 157084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157084
Log:
PR debug/43160
* var-tracking.c (dv_onepart_p): R
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-26 11:01 ---
Subject: Bug 43161
Author: jakub
Date: Fri Feb 26 11:01:28 2010
New Revision: 157083
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157083
Log:
PR debug/43161
* regcprop.c (struct queued_debug_
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-26 10:26 ---
> gfortran already bails out with:
> Error: Allocate-object at (1) is not a nonprocedure pointer
> or an allocatable variable
If you are already patching, can you also improve the wording for this old
error messa
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-02-26 10:19
---
It looks like only c87b39a still fails as of this writing, but the 3 mentioned
tests (c37105a, c46051a, c87b39a) use a common pattern, namely discriminated
record types with fixed size and associated subtypes:
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-26 10:06 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-26 10:06 ---
Confirmed. It's the vectorizer adjusting alignment of p.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from baldrick at gcc dot gnu dot org 2010-02-26 09:47
---
The reason I occasionally use a thin pointer is because they can be stored
atomically. This is sometimes useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
> cat gcc_private_inheritance.cpp :
class A {};
class B : public A {};
class C : private B {
public:
operator A& () {return *this;}
};
void doSomething (const A&) {}
int main (int argc, char** argv){
C instC;
// Attempt 1. Causes compiler error, not expected
doSomething (instC.op
85 matches
Mail list logo
