https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #19 from Richard Biener ---
There is also tree-core.h:
/* Call argument flags. */
/* Nonzero if the argument is not dereferenced recursively, thus only
directly reachable memory is read or written. */
#define EAF_DIRECT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92686
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92682
Richard Biener changed:
What|Removed |Added
Version|unknown |10.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92681
--- Comment #1 from Richard Biener ---
Is it actually making it worse from non-PGO or do we at least treat missing
profile data as "it wasn't trained"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92680
--- Comment #2 from Richard Biener ---
And gmp has a similar issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92680
Richard Biener changed:
What|Removed |Added
Keywords||build
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91790
Kewen Lin changed:
What|Removed |Added
Attachment #47357|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92687
Bug ID: 92687
Summary: decltype of a structured binding to a tuple component
is a reference type inside a template function
Product: gcc
Version: 9.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92686
--- Comment #1 from Hongtao.liu ---
My local patch shows there's no big performance impact on SPEC2017.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92685
Erick Ochoa changed:
What|Removed |Added
Attachment #47367|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92686
Bug ID: 92686
Summary: Inefficient mask operation for 128/256-bit vector
VCOND_EXPR under avx512f
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92685
--- Comment #1 from Erick Ochoa ---
Created attachment 47368
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47368=edit
Test Cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92685
Bug ID: 92685
Summary: In IPA's execute stage create_version_clone_with_body
fails with non-vNULL callers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684
--- Comment #3 from Andrew Pinski ---
There is a defect report dealing with this in C and such.
Both are correct for C11 but would be incorrect for C90 which defines bit-field
types because of the defect report. GCC decided to follow the C90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684
--- Comment #2 from Andrew Pinski ---
bit-fields in C is a type.
while in C++, it is not.
So:
st.v2 << 3
This is not ((long)st.v2) << 3 but rather (long:45)<<3. So it gets truncated.
C11:
fff8
0xfff8
1ffffff8
1 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684
Bug ID: 92684
Summary: bitfield behavior not matching the declared type
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
--- Comment #13 from Jerry DeLisle ---
Author: jvdelisle
Date: Wed Nov 27 00:50:51 2019
New Revision: 278753
URL: https://gcc.gnu.org/viewcvs?rev=278753=gcc=rev
Log:
2019-11-26 Jerry DeLisle
Backport from mainline
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92664
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 27 00:23:39 2019
New Revision: 278752
URL: https://gcc.gnu.org/viewcvs?rev=278752=gcc=rev
Log:
PR debug/92664
* dwarf2out.c (lookup_filename): Use "" instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 92683, which changed state.
Bug 92683 Summary: [10 Regression] strncmp incorrect result with equal
substrings and non-const bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683
--- Comment #1 from Martin Sebor ---
Author: msebor
Date: Tue Nov 26 23:56:22 2019
New Revision: 278742
URL: https://gcc.gnu.org/viewcvs?rev=278742=gcc=rev
Log:
PR tree-optimization/92683 - strncmp incorrect result with equal substrings and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92671
--- Comment #1 from joseph at codesourcery dot com ---
I don't think this is a confusing case of precedence, i.e. the proposed
change is not an improvement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
--- Comment #12 from Jerry DeLisle ---
Author: jvdelisle
Date: Tue Nov 26 22:56:24 2019
New Revision: 278740
URL: https://gcc.gnu.org/viewcvs?rev=278740=gcc=rev
Log:
2019-11-26 Jerry DeLisle
Backport from mainline
PR
sing /src/gcc/git-svn/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /src/gcc/git-svn/gcc/testsuite/gcc.dg/dg.exp ...
=== gcc Summary ===
# of expected passes15
# of expected failures 8
/ssd/build/gcc-git-svn/gcc/xgcc v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683
Martin Sebor changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683
Bug ID: 92683
Summary: [10 Regression] strncmp incorrect result with equal
substrings and non-const bound
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
--- Comment #12 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Tue Nov 26 22:11:39 2019
New Revision: 278738
URL: https://gcc.gnu.org/viewcvs?rev=278738=gcc=rev
Log:
Update vect_char_add target selector to use its own cache
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92648
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Tue Nov 26 21:58:22 2019
New Revision: 278737
URL: https://gcc.gnu.org/viewcvs?rev=278737=gcc=rev
Log:
PR c++/92648
* parser.c (cp_parser_std_attribute): For unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
--- Comment #23 from Jakub Jelinek ---
Author: jakub
Date: Tue Nov 26 21:57:27 2019
New Revision: 278736
URL: https://gcc.gnu.org/viewcvs?rev=278736=gcc=rev
Log:
PR c++/61414
* c-attribs.c (handle_mode_attribute): Add mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
--- Comment #11 from Jerry DeLisle ---
> Modified:
> trunk/gcc/ChangeLog
Hi hit the wrong log file for the testsuite entry. It has been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92682
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078
fkostenzer at live dot at changed:
What|Removed |Added
CC||fkostenzer at live dot at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92682
Bug ID: 92682
Summary: [10 Regression] maxlocval_4.f90 / minlocval_4.f90
failure on POWER9
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #6 from Iain Sandoe ---
the patch at comment #5 works for powerpc-darwin9, test output looks "nominal"
(given that there's a lot of recent regression/new fails anyway)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92673
--- Comment #3 from Andrew Pinski ---
(In reply to Jürgen Reuter from comment #2)
> (In reply to Richard Biener from comment #1)
> > Try -fcommon, it's default recently was swapped to -fno-common.
>
> The default for gcc was changed? Which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642
--- Comment #5 from Andrew Pinski ---
(In reply to Jonny Grant from comment #4)
> This test case for similar does have a nice warning.
>
> Interestingly, G++ does not indicate that 5147483647 is already 34 bits long:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81205
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92681
Bug ID: 92681
Summary: PGO bootstrap is broken with
--with-build-config=bootstrap-lto-lean is not training
non-C++ frontends
Product: gcc
Version: 10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92680
Bug ID: 92680
Summary: PGO bootstrap is broken with
--with-build-config=bootstrap-lto-lean and in-itree
mpfr
Product: gcc
Version: 10.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92678
Jakub Jelinek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92640
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92679
--- Comment #5 from Jonathan Wakely ---
Or simply:
template
void accept(F f) {
functions[std::type_index(typeid(TArg))]
= [f](std::any ) -> TReturn { return f(std::any_cast(x)); };
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92679
--- Comment #4 from Jonathan Wakely ---
Change the capture from [] to simply [f] and it works fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92679
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92679
--- Comment #2 from Jonathan Wakely ---
Without optimisation it prints your expected output for me (with any version of
GCC). It only fails with optimisation.
ASan seems to show a problem in your code:
==428329==ERROR: AddressSanitizer:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #18 from Jakub Jelinek ---
https://gcc.gnu.org/ml/gcc-patches/2010-04/msg00895.html
contained documentation but in the end we went with an internal "fn spec"
attribute rather than user visible fnspec:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #17 from Tobias Burnus ---
(In reply to Thomas Koenig from comment #16)
> Is there a specification (or even description) for fn spec somewhere?
> I can't say I understand exactly what it does.
Maybe gimple.c's gimple_call_arg_flags:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91944
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91944
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2019-10-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92679
--- Comment #1 from Marcello Mansueto ---
Created attachment 47365
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47365=edit
Preprocessed version of the file that triggers the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92679
Bug ID: 92679
Summary: Test case with failing unordered_map search when key
is type_index
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92678
Bug ID: 92678
Summary: UB sanitizer and pointer to member functions with
multiple inheritance
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92677
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92677
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92677
Bug ID: 92677
Summary: [10 Regression] ICE in get_group_load_store_type, at
tree-vect-stmts.c:2261 since r271704
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #10 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #8)
> Because 5147483647 doesn't fit in an int, so it picks a larger type, because
> that's what the standard requires. 1 does fit in an int, so the compiler
> picks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #6 from Michael Matz ---
(In reply to Jonathan Wakely from comment #5)
>
> Before choosing which conversion operator to use, the compiler considers the
> constructors of S, finding S(const S&) and S(S&&) as candidates. There is a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92676
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675
--- Comment #2 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #1)
> That's an idiomatic way to get the largest unsigned value, it would be a
> shame if it warned.
Personally I would use UINT_MAX from limits.h, feels more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967
Matthijs Kooijman changed:
What|Removed |Added
CC||matthijs at stdin dot nl
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #9 from Jonathan Wakely ---
(In reply to David Brown from comment #6)
> All in all, the whole idea sounds counter-productive to me. If you need
> spoon-feeding about the details of C here, you would be better off reading a
> book on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #8 from Jonathan Wakely ---
Because 5147483647 doesn't fit in an int, so it picks a larger type, because
that's what the standard requires. 1 does fit in an int, so the compiler picks
int, because that's what the standard requires.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #7 from Jonny Grant ---
(In reply to David Brown from comment #4)
> (In reply to Jonny Grant from comment #2)
> > (In reply to Xi Ruoyao from comment #1)
> > > Is it appropriate?
> > >
> > > Though on both 32-bit and 64-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960
Jonathan Wakely changed:
What|Removed |Added
CC||euloanty at live dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92670
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92676
--- Comment #2 from Martin Liška ---
Created attachment 47364
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47364=edit
2.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92676
--- Comment #1 from Martin Liška ---
Created attachment 47363
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47363=edit
1.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92676
Bug ID: 92676
Summary: [10 Regression] lto1: error: comdat-local function
called by construct.constprop outside its comdat since
r278669
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #5 from Jonathan Wakely ---
(In reply to Michael Matz from comment #4)
> the return value of moveme() has type Test&&. There exists a conversion
> operator exactly matching that type,
See Bug 86521 comment 4, it's similar here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92235
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #6 from David Brown ---
(In reply to Xi Ruoyao from comment #3)
> (In reply to Jonny Grant from comment #2)
> > (In reply to Xi Ruoyao from comment #1)
> > > Is it appropriate?
> > >
> > > Though on both 32-bit and 64-bit x86 "1ul"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #5 from Jonathan Wakely ---
(In reply to Xi Ruoyao from comment #3)
> I can't find any specification in C standard saying "the bitwidth of long
> should >= the bitwidth of size_t". So at least theoretically it may be
> insufficient.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
--- Comment #11 from Joel Hutton ---
I see, I think you're right. I was able to replicate the failure when running
the whole 'vect' testsuite. I tried the following change:
diff --git a/gcc/testsuite/lib/target-supports.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
David Brown changed:
What|Removed |Added
CC||david at westcontrol dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92315
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Joel Hutton ---
> Weird, I tested on gcc202.
[...]
> # of unsupported tests 2
I see the same when testing this single test individually. However,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #3 from Xi Ruoyao ---
(In reply to Jonny Grant from comment #2)
> (In reply to Xi Ruoyao from comment #1)
> > Is it appropriate?
> >
> > Though on both 32-bit and 64-bit x86 "1ul" is good for a size_t, but I
> > believe there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #2 from Jonny Grant ---
(In reply to Xi Ruoyao from comment #1)
> Is it appropriate?
>
> Though on both 32-bit and 64-bit x86 "1ul" is good for a size_t, but I
> believe there is some platform where "1ull" is necessary.
>
> Maybe
-objects
=== gcc Summary ===
# of unsupported tests 2
/home/joelh/gcc/objdir/gcc/xgcc version 10.0.0 20191126 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675
Bug ID: 92675
Summary: sign-conversion C++ unsigned int j = -1;
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
Rainer Orth changed:
What|Removed |Added
Attachment #47187|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92673
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92583
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
--- Comment #6 from Joel Hutton ---
This should be fixed with Richard Sandifords changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92582
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92674
--- Comment #3 from Richard Biener ---
Created attachment 47360
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47360=edit
patch
I am testing the attached. The testcase seems to be too much reduced to be
useful for the testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #4 from Michael Matz ---
Even though bugzilla isn't really for educating people, I'd still like to ask
why the two conversion sequences are deemed either incomparable or equal. In
S b { moveme(t) };
the return value of moveme()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92674
--- Comment #2 from Richard Biener ---
Oh, it's not there but
#8 0x011ba073 in expand_call_inline (
bb=, stmt=,
id=0x7fffd6e0) at /tmp/trunk/gcc/tree-inline.c:5160
5160 gimple_purge_dead_eh_edges (return_block);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92673
Jürgen Reuter changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from Jürgen Reuter
1 - 100 of 155 matches
Mail list logo
