--- Additional Comments From falk at debian dot org 2005-02-24 07:30
---
(In reply to comment #2)
> I tried the -fno-strict-aliasing option, but this generates the same code.
Okay, let's reopen this then for now.
--
What|Removed |Added
-
--- Additional Comments From gschafer at zip dot com dot au 2005-02-24
06:43 ---
Here's the fix to pthread.h from Glibc cvs. I suppose the fixinclude "fix" would
need to replicate this:
http://sources.redhat.com/ml/glibc-cvs/2005-q1/msg00303.html
--
http://gcc.gnu.org/bugzilla/show_
--- Additional Comments From gschafer at zip dot com dot au 2005-02-24
04:39 ---
This also happens for me on i686-pc-linux-gnu. It's a bog-standard unpatched
NPTL-enabled glibc-2.3.4 system. I don't think it classifies as a "bad glibc". I
concur that some fixincludes magic may be require
--- Additional Comments From schlie at comcast dot net 2005-02-24 02:49
---
Subject: Re: 4.0 bootstrap unreasonably requires
64-bit target type mode support.
> Please explain why you think it is a bug for the avr to support long long.
> Your description sounds like an opinion.
>
> Th
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-02-24
02:45 ---
Now that 19878 has been fixed, we can see that this does in fact fail on the
mainline as well.
--
What|Removed |Added
---
--
Bug 19916 depends on bug 19878, which changed state.
Bug 19878 Summary: [4.0 Regression] ICE in import_export_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19878
What|Old Value |New Value
---
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-02-24
02:43 ---
Fixed in 4.0.
--
What|Removed |Added
Status|ASSIGNED|RESOLV
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-24
02:42 ---
Subject: Bug 19878
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-24 02:42:17
Modified files:
gcc/cp : ChangeLog decl.c
gcc/testsui
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-24
01:56 ---
Subject: Bug 19241
CVSROOT:/cvs/gcc
Module name:gcc
Branch: apple-ppc-branch
Changes by: [EMAIL PROTECTED] 2005-02-24 01:56:22
Modified files:
gcc: tree
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bosch at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From ericw at evcohs dot com 2005-02-23 23:32
---
Please explain why you think it is a bug for the avr to support long long. Your
description sounds like an opinion.
The pointer size on the AVR is currently 16 bits. This will change in the near
future to either 2
--- Additional Comments From jay at systech dot com 2005-02-23 23:29
---
Subject: RE: Improper code generation causes
stack corruption
I tried the -fno-strict-aliasing option, but this generates the same code.
Although this may violate aliasing rules, the compiler is not messi
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
23:29 ---
This has a pretty good chance of fixing it.
Proper testing, Changelog entry, ... tomorrow.
Index: string.c
===
RCS file: /cvsroot/gcc/gcc
--- Additional Comments From d_picco at hotmail dot com 2005-02-23 23:27
---
I won't press the issue further because I have other things more pressing ;)
But I think the decision to not change the behaviour here is wrong. I cannot
create an Integer class that acts as an int due to the
Command line options, in particular -D options, should be interpreted in
the locale character set (maybe subject to -finput-charset override).
Instead, the expansion of a -D option is not subject to character set
translation at present.
Consider the program
char *s = S;
compiled with the followi
--- Additional Comments From stevenj at fftw dot org 2005-02-23 23:17
---
Subject: Re: cannot mix C and Fortran I/O
On Wed, 23 Feb 2005, Thomas dot Koenig at online dot de wrote:
> Add "fflush(stdout);" at the end of cio.c, and things work
> as expected.
This is a workaround, but it w
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
23:09 ---
This is two bugs.
The first bug can be reduced to
$ cat open-opt.f
open(unit=10,status="scratch ")
end
$ gfortran open-opt.f
$ ./a.out
At line 1 of file open-opt.f
Fortran runtime error: Ba
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-23
23:08 ---
It should be fixed by the next push from AdaCore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19140
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
23:05 ---
You are violating aliasing rules:
(uint16 *)&V42Parms
try with -fno-strict-aliasing or with an union. Please read
http://gcc.gnu.org/bugs.html which talks
about this problem.
--
What|Rem
The generated code copies an argument to a local (new) stack frame before
allocating that stack frame (adjusting the stack pointer), allowing an
interrupt to corrupt that value. The argument is copied to memory, so that the
argument's address can be passed to another function. As long as an in
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
22:54 ---
Add "fflush(stdout);" at the end of cio.c, and things work
as expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
--- Additional Comments From bosch at gcc dot gnu dot org 2005-02-23 22:32
---
I can't reproduce this bug, so I'm assuming the new libada has fixed this.
However, the GNAT library needs adaptation for new targets and one cannot
expect to retarget GNAT and have it work out of the box..
It
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-23
22:20 ---
Subject: Bug 20100
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-23 22:20:49
Modified files:
gcc/testsuite : ChangeLog
Added files:
gcc/t
--- Additional Comments From falk at debian dot org 2005-02-23 22:18
---
(In reply to comment #2)
> I
> wanted to submit the *.i file just in case you wanted to look at it but the
> file
> is over 1MB and it says it is too large.
Compress it with bzip2 and use "Create a New Attachmen
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
21:27 ---
No, this isn't fixed with the patch I referred to earlier.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
--- Additional Comments From bosch at gcc dot gnu dot org 2005-02-23 21:26
---
The broken code in misc.c that gave rise to this report is now gone, and
frankly, I think it is worth
debating how a misspelled option should be handled. So, I'll change the warning
to an error.
-Geert
--- Additional Comments From adam at adamcarlson dot org 2005-02-23 21:02
---
(In reply to comment #1)
> Not a gcc bug. Tou have bad memory or hardware as it works the second time.
Now it has started failing consistently on one file and I was able to make a *.i
file. The system I'm us
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bosch at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
20:51 ---
(In reply to comment #30)
> I'm not sure what you mean by the system(...) call... I understand that the
> code
> is undefined (meaning its up to the compiler vendor to implement as they see
> fit). I think
--- Additional Comments From d_picco at hotmail dot com 2005-02-23 20:46
---
Here is a better clarification:
Case 1
==
int a = 0;
int b = a++ + a++;
printf("b = %d\n", b); // output is 0
Case 2
==
class A
{
int a_;
public:
A() : a_(0) {}
int operator++() { return a_++;
--- Additional Comments From stevenj at fftw dot org 2005-02-23 20:46
---
Subject: Re: COMPLEX function returns incompatible with
g77
On Wed, 23 Feb 2005, pinskia at gcc dot gnu dot org wrote:
> And gfortran is totally new front-end, written from scratch.
Obviously. That doesn't mea
--- Additional Comments From micis at gmx dot de 2005-02-23 20:45 ---
You where right, it was my fault.
Thank you for your effort.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20170
--- Additional Comments From stevenj at fftw dot org 2005-02-23 20:44
---
Subject: Re: COMPLEX function returns incompatible with
g77
On Wed, 23 Feb 2005, pinskia at gcc dot gnu dot org wrote:
> Well chaning to be more target's C like (because that is what gfortran
> uses now) ABI.
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-23 20:43
---
(In reply to comment #4)
> However, this doesn't really alter the basic question of why you are
> changing the default calling conventions.
You could call it an oversight. The -fno-f2c calling convention is
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
20:41 ---
(In reply to comment #28)
The code is undefined, which means we should be able to do system("rm -Rf /");,
note we don't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
--- Additional Comments From d_picco at hotmail dot com 2005-02-23 20:38
---
The point I was making with my example is that the native types (int, long,
char, etc...) have different behaviour than a user-defined class with the
operator++. If it is compiler dependent which way the expres
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
20:31 ---
And gfortran is totally new front-end, written from scratch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
20:30 ---
(In reply to comment #4)
> However, this doesn't really alter the basic question of why you are
> changing the default calling conventions.
Well chaning to be more target's C like (because that is what gfo
--- Additional Comments From stevenj at fftw dot org 2005-02-23 20:28
---
Subject: Re: COMPLEX function returns incompatible with
g77
I confirm that it works when you compile arg1.f with -fno-f2c:
g77 -fno-f2c -c arg1.f
gfortran arg1tst.f arg1.o -o arg1tst
.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
20:26 ---
*** Bug 20181 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
20:26 ---
*** This bug has been marked as a duplicate of 11751 ***
*** This bug has been marked as a duplicate of 11751 ***
--
What|Removed |Added
--
--- Additional Comments From d_picco at hotmail dot com 2005-02-23 20:24
---
(In reply to comment #0)
> Consider these situations:
>
> int a = 0;
> int b = a++ + a++;
> int c = (a++) + (a++);
> int d = a++ + (a++);
> int e = (a++) + a++;
>
> b == c == d == e == 0. I understand based o
Consider these situations:
int a = 0;
int b = a++ + a++;
int c = (a++) + (a++);
int d = a++ + (a++);
int e = (a++) + a++;
b == c == d == e == 0. I understand based on a previous bug about sequence
points in C++ but I think a common-sense approach takes precident here. If 'a'
were a user-defined
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
20:18 ---
Actually this looks more like mixing stdio functions and unix style functions
(well mmap ones).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-23 20:11
---
g77's documentation of the calling convention:
`-fno-f2c'
Do not generate code designed to be compatible with code generated
by `f2c' use the GNU calling conventions instead.
The `f2c' calling c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
20:08 ---
Werid.
--
What|Removed |Added
Component|fortran |libfortran
h
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
--- Additional Comments From falk at debian dot org 2005-02-23 19:52
---
"int i = i" does not do what you think it does. It initializes i with the
yet-uninitialized new i. So this is invalid code.
--
What|Removed |Added
---
--
What|Removed |Added
Attachment #8268|Simple test case which |Simple test case which
description|demonstrates the bug - .ii |demonstrates the bug - .ii
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-02-
--- Additional Comments From bugzilla-t05k1 at email dot galacticnorth dot
net 2005-02-23 19:48 ---
Created an attachment (id=8268)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8268&action=view)
Simple test case which demonstrates the bug - .ii file
Pretty much the simplest code
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-23 19:47
---
Have 'we' ever agreed not to fix this? I would be interested in the rationale
given at that time. The issue Steven raises is important, even if there are
only four functions returning COMPLEX in BLAS: cdotc,
When declaring a variable which hides a same-named variable from a higher scope.
If the new variable is initialized from the same-named variable using the
assignment-like constructor syntax AND there was an earlier hiding of the same
variable name...
The value used for the initialization value com
When calling a C library from a gfortran-compiled program, C stdio is only
partially written.
Ability to mix languages as needed is really important in many practical
applications these days, so this would be nice to fix. I suspect that
there is simply a missing fflush (or similar) somewhere, si
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
19:02 ---
Yes we know about this and it will not be fixed.
--
What|Removed |Added
Status|U
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
18:59 ---
A C testcase (scanf this time):
#include
int main(void)
{
int i;
int j;
scanf("%d", &i);
for(;i<=0;i--)
printf("H");
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20165
A function returning a COMPLEX value cannot be compiled in g77 and
called from gfortran (or vice versa) - doing so results in a segfault
or incorrect results. (See test case below.)
This is a problem, since for the near future g77 and gfortran are
likely to coexist on many systems, and incompat
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
18:52 ---
Hmm, that means someone is not updating the dead count correct:
gcc_assert (deaths_in_region[rgn]
== count_or_remove_death_notes (blocks, 0));
Maybe related to the fixed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
18:49 ---
Not a gcc bug, as I cannot reproduce this with the correct libstdc++.
--
What|Removed |Added
The options "-O2 -fmodulo-sched" result in an internal compiler error on
powerpc*-linux for most benchmarks in SPEC CPU2000, and also for several
tests from gcc.c-torture/compile. Failing tests from that directory with
-m32 are 2403-1.c, 20040621-1.c, 920723-1.c, 920825-2.c, 931003-1.c,
961004
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
18:41 ---
Are you sure that you are linking with the correct version of libstdc++.
As `__cxa_get_exception_ptr' is new as 2005-02-18.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20170
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
18:39 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
18:39 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
18:36 ---
*** Bug 20174 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
18:36 ---
*** This bug has been marked as a duplicate of 14494 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
18:29 ---
Not a gcc bug. Tou have bad memory or hardware as it works the second time.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
18:27 ---
Confirmed, this was introduced (most likely when the patch to fix for PR 19755
was committed).
Reduced testcase:
struct c { char s[8]; int i;};
struct c a = {"hello", 1};
--
What|Removed
Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/specs
Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld
--verbose --target=i486-slackware-linux --host=i486-slackware-linux
Thread model:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-23
18:21 ---
Subject: Bug 20097
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-23 18:20:53
Modified files:
gcc: ChangeLog simplify-rtx.c
Log messag
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-23
18:21 ---
Subject: Bug 20018
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-23 18:20:53
Modified files:
gcc: ChangeLog simplify-rtx.c
Log messag
--- Additional Comments From gcc at magfr dot user dot lysator dot liu dot
se 2005-02-23 18:15 ---
Created an attachment (id=8267)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8267&action=view)
Program demonstrating the bug
Compile with
g++ -Wmissing-braces -c foo.C
to demonstr
When compiling the attached file foo.C using the flag -Wmissing-braces (part of
-Wall) then the warning
foo.C:3: warning: missing braces around initializer
is printed even though no braces are needed around the char array.
--
Summary: Warnings are issued when initializing struct memb
...and I have another one, this is gcc bug finding day.
it's again related to partial template function specializations, but I open a
new report because this time it is rejects-valid:
(at least I think so)
template
struct A{
template
void function(){}
};
template<>
template
void A::function()
--- Additional Comments From bonniot at users dot sf dot net 2005-02-23
17:40 ---
I tried the patched gcj on the whole jar (containing the Nice compiler), and
this error does not occur (nor any other, yay!).
As far as I can tell, Andrew's patch fixes this bug.
--
http://gcc.gnu.org/
--- Additional Comments From fitzsim at redhat dot com 2005-02-23 17:38
---
Fixed on mainline.
--
What|Removed |Added
Status|NEW |RESOLV
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-23
17:36 ---
Subject: Bug 16923
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-23 17:36:26
Modified files:
gcc/java : ChangeLog gcj.texi
libjava
--
What|Removed |Added
Attachment #8266|text/x-c++src |text/plain
mime type||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-02-23 17:19 ---
Comeau C++ thinks this code is invalid.
If it's right, this bug might be related to #20157
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-02-23 17:16 ---
Created an attachment (id=8266)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8266&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173
attaching testcase.
result should be '1', but is '2', an int is matched to a pointer.
(and the pointer has the value of the integer in the function)
is known to fail for 3.3.5 and 3.4.4.
I can't test with 4.0 atm but I think it also fails because I came across this
by a strange internal tree gene
--- Additional Comments From giovannibajo at libero dot it 2005-02-23
17:11 ---
We could document that in the manual though. Reopening to keep track of this as
a request for enhancement in the manual.
--
What|Removed |Added
--
--- Additional Comments From bonniot at users dot sf dot net 2005-02-23
17:10 ---
Patch works for me on the small testcase (N.jar). I'll try on the whole jar when
I get the chance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18362
--- Additional Comments From micis at gmx dot de 2005-02-23 16:44 ---
Created an attachment (id=8265)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8265&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20170
--
What|Removed |Added
Keywords||accepts-invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20172
--- Additional Comments From overholt at redhat dot com 2005-02-23 16:38
---
After further investigation, I have determined that this is not a bug with the
dbtool. Closing.
--
What|Removed |Added
--
gcc accepts the following ill-formed code (tested with gcc3.4.2 (mingw)
and various cygwin versions (from 3.3.1 to 3.4.3 and an experimental
snapshot 4.0.0-20050130) ):
template
struct foo{
template
static void bar() { }
};
template
foo tester(T) { return foo(); }
int main(){
tester(1.2
--- Additional Comments From micis at gmx dot de 2005-02-23 16:28 ---
was entered twice
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
When I use the actual snapshot of gcc40 to compile ACE 5.4.2 I get link errors.
I don't how to proceed in this case, the link error occurs after ~350 are
compiled and several libraries are generated.
This is a new regression, snapshot 20050213 has no problems.
My gcc is snapshot 20050220 with pat
When I use the actual snapshot of gcc40 to compile ACE 5.4.2 I get link errors.
I don't how to proceed in this case, the link error occurs after ~350 are
compiled and several libraries are generated.
This is a new regression, snapshot 20050213 has no problems.
My gcc is snapshot 20050220 with pat
--- Additional Comments From bonniot at users dot sf dot net 2005-02-23
16:06 ---
I verified the bytecode testcase now passes.
Thanks for the fix! (is it final now?)
--
What|Removed |Added
-
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-23 15:45
---
It deserves mentioning (for the audience) that the right thing happens for
the generated code in the test-case; this problem is mainly an internal
wart (IIUC):
...
now, the problem is that if there is a mix of r
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
15:43 ---
Changing this for Diego.
--
What|Removed |Added
Severity|normal
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org |org
Status|NEW
--
What|Removed |Added
Keywords||alias, missed-optimization
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-23 15:32
---
Please put the jars and .so files somewhere I can see them.
--
What|Removed |Added
Assi
--
What|Removed |Added
Component|java|libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20169
]
true
GIJ: LD_LIBRARY_PATH=/tmp/gcc/lib /tmp/gcc/bin/gij Enum
[EMAIL PROTECTED]
[EMAIL PROTECTED]
false
GCJ: /tmp/gcc/bin/gcj --main=Enum *.class
LD_LIBRARY_PATH=/tmp/gcc/lib ./a.out
[EMAIL PROTECTED]
[EMAIL PROTECTED]
false
/tmp/gcc/bin/gcj --version
gcj (GCC) 4.0.0 20050223 (experimental
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org |
Status|WAITING
Before the fix for PR 20100 and PR 20115, const and pure calls were both treated
as "const". After the fix, both are treated as "pure" by that fix, but
a .GLOBAL_VAR is unnecessarily created because of the bambam call in:
extern int constfun (void) __attribute__ ((__const__));
extern void bambam
1 - 100 of 162 matches
Mail list logo
