https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056
--- Comment #18 from Dominik Vogt ---
Seems to be fixed.
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: dje at gcc dot gnu.org
Target Milestone: ---
Target: AIX, Power
The file rs6000.h contains the macros
--
#define STACK_BOUNDARY \
((TARGET_32BIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #21 from Dominik Vogt ---
Patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00266.html
This needs to pass the AIX testsuite which I cannot run with the available
resources.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #16 from Dominik Vogt ---
There's nothing wrong with applying that change, but it does not fix the
problem. I'm still debugging this and have it narrowed down to being related
with functions that use alloca() and call another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #14 from Dominik Vogt ---
Okay, it looks like outgoing_args_size is rounded up to a multiple of
preferred_stack_boundary, so there's no problem on s390 or other targets with a
stack allocation size smaller than STACK_BOUNDARY. So,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #13 from Dominik Vogt ---
> What do you mean by size of a stack slot?
On s390, if we have one "int" variables on the stack, this uses a "slot" 4
bytes. The stack pointer maintains an 8 byte alignmet though, i.e. SP is
changec by 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #11 from Dominik Vogt ---
But does that really match the Abi? On s390 (31 bit) we have an 8 byte aligned
stack pointer, but the size of a stack slot is just 4 bytes, so the offset from
the stack pointer may just be a multiple of 4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #9 from Dominik Vogt ---
> AIX increased the alignment when Altivec support was added. It
> appears that STACK_DYNAMIC_OFFSET should add a test for AIX.
Is the alignment of the dynamic area part of the AIX Abi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #8 from Dominik Vogt ---
Something like this:
-- snip --
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 353f388..3158c24 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -1719,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #6 from Dominik Vogt ---
> Presumably something in the rs6000 backend is not maintaining or not
> instructing the common part of GCC to maintain the alignment on AIX,
> but presumably is maintained on Linux.
Might be a problem with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #5 from Dominik Vogt ---
Sounds fair. So, either the bug is that the stack pointer has 8 byte
alignment, or the formula for STACK_DYNAMIC_OFFSET results in the the wrong
amount:
-- rs6000.h --
/* Offset from the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
Dominik Vogt changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #2 from Dominik Vogt ---
It's a bit awkward because I don't have access to an AIX machine right now.
What's the "configure" line fron config.log, please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71144
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860
--- Comment #13 from Dominik Vogt ---
By the way, I think the value of y should be tested *after* the asm statement
in line 17 not before it in line 16. At higher optimization levels the
assignement may not have happened yet when gdb reaches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860
--- Comment #12 from Dominik Vogt ---
We've just been looking at this today for s390x which fails these tests for
various reasons too (actually we've located at least four different Gcc bugs by
looking at this test case). Some of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70787
--- Comment #2 from Dominik Vogt ---
The Go runtime seems to register a handler for SIGPROF even if it does not want
to profile. So it always uninstalls the handler installed by Glibc on behalf
of the -pg option. To me it looks like -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70787
--- Comment #1 from Dominik Vogt ---
(I've also tried setting GMON_OUT_PREFIX so that the gmon.out file does not get
overwritten by different threads, but in either case only one dump file is
created.)
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com, krebbel at gcc dot gnu.org
Target Milestone: ---
It looks like the -pg option does something wrong for Go programs. Example:
This program just wastes time in sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70561
Dominik Vogt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70561
--- Comment #2 from Dominik Vogt ---
(Ah, probably add_clobbers should have added the clobber, but it hasn't. It
doesn't have any code for that pattern.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70561
--- Comment #1 from Dominik Vogt ---
P.S.:
(gdb) p debug_rtx(pat)
(set (reg:SI 67 [+4 ])
(and:SI (not:SI (subreg:SI (reg/v:DI 65 [ b+-4 ]) 4))
(mem:SI (plus:DI (reg:DI 2 %r2 [ a ])
(const_int 4 [0x4])) [1 *a_2(D)+4
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
This code in recog_for_combine_1 doesn't look right:
--
if (num_clobbers_to_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70404
--- Comment #3 from Dominik Vogt ---
Andreas is already working on the issue, so before anybody spends any more work
on this, you should probably coordinate your efforts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70404
--- Comment #1 from Dominik Vogt ---
Configured with --with-arch=zEC12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70174
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
The new test case from #70174 triggers an ICE on s390x (svn rev 234414):
.../build/gcc/xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70236
--- Comment #1 from Dominik Vogt ---
Created attachment 37967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37967=edit
rnreg dump
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: vmakarov at gcc dot gnu.org
Target Milestone: ---
Created attachment 37966
--> https://gcc.gnu.org/bugzilla/attachment.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70078
--- Comment #2 from Dominik Vogt ---
(I'll make a patch with these and some more corrections once it's clear how the
wording should be.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70078
--- Comment #1 from Dominik Vogt ---
Hijacking this bug report for more unclear documentation in that section;
proposed changes in marked with <...>.
Apart from the bad grammar, the meaning of this sentence is a mystery:
Splitting of jump
iority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Target Milestone: ---
The section "Defining How to Split Instructions" in the gccint manual claims
The preparation-statements are similar to those statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #20 from Dominik Vogt ---
Created attachment 37860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37860=edit
vrp1 dump for s390x (-m64)
vrp1 dump for s390x attached (-m64, give me a shout if you need the -m31 dump).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69987
--- Comment #7 from Dominik Vogt ---
Fixed on s390x.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659
--- Comment #22 from Dominik Vogt ---
Successfully bootstrapped and regression tested on s390x biarch.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555
--- Comment #11 from Dominik Vogt ---
Successfully bootstrapped and regression tested on s390x biarch.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #18 from Dominik Vogt ---
Which dumps do you need?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
Dominik Vogt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69987
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69760
--- Comment #14 from Dominik Vogt ---
The regression is fixed with the latest patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983
--- Comment #8 from Dominik Vogt ---
Successfully bootstrapped and regression tested on s390x (biarch).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #16 from Dominik Vogt ---
(In the ChangeLog entry, the "-1" is missing from the name of the new
testfile.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70025
--- Comment #10 from Dominik Vogt ---
Successfully bootstrapped and regression tested on s390x (-m31 and -m64).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70025
--- Comment #6 from Dominik Vogt ---
Shouldn't this rather check whether the *value* of the register in in_rtx
appears in out_rtx?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
--- Comment #7 from Dominik Vogt ---
Sorry, comment 6 is wrong, I was thinking about stack *guard* support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
--- Comment #6 from Dominik Vogt ---
S390 does have stack checking support, so the question is really just whether
Ada has extra requirements.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
--- Comment #5 from Dominik Vogt ---
We have zero test failures with the patched code. Is that good enough or
should I still take a closer look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
--- Comment #3 from Dominik Vogt ---
It looks like no more than activating Stack_Check_Probes is required. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70025
--- Comment #5 from Dominik Vogt ---
Yup.
debug_rtx(out_rtx) = (mem/f:DI (plus:DI (reg/v/f:DI 164 [orig:129 p ] [129])
(const_int 16 [0x10])) [4 p_8(D)->d3+0 S8 A64])
debug_rtx(in_rtx) = (reg/v/f:DI 151 [orig:129 p ] [129])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70025
--- Comment #3 from Dominik Vogt ---
Looks like the extra condition in that patch is still not good enough:
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -945,6 +945,12 @@ match_reload (signed char out, signed char *ins, enum
reg_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #36 from Dominik Vogt ---
(Sorry, comment 35 belongs to the follow-up report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70025 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #35 from Dominik Vogt ---
Looks like the extra condition in that patch is still not good enough:
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -945,6 +945,12 @@ match_reload (signed char out, signed char *ins, enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70025
--- Comment #2 from Dominik Vogt ---
This is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
Dominik Vogt changed:
What|Removed |Added
Summary|Ada: c52103x test failure |c52103x and c52104x test
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: ebotcazou at gcc dot gnu.org, krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
My knowledge of Ada is practically zero, but I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69760
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69920
--- Comment #12 from Dominik Vogt ---
The Ice in 42704.c is gone on s390[x] with trunk (but not the other FAILs). Is
the Ice below related to this bug report or is it something totally different?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69920
--- Comment #9 from Dominik Vogt ---
(Fails only with -m31.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69920
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451
--- Comment #15 from Dominik Vogt ---
The problem is gone on today's trunk for s390 and s390x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709
--- Comment #10 from Dominik Vogt ---
We've located the bug in the s390 backend. No further help is needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709
--- Comment #9 from Dominik Vogt ---
(-fpeel-loops is activated by -fprofile-use, so this is the connection to
profilesbootstrap.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709
--- Comment #8 from Dominik Vogt ---
Created attachment 37790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37790=edit
Test case
The option -fpeel-loops triggers the bug. The attached program has a different
result with -fpeel-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709
--- Comment #7 from Dominik Vogt ---
The stage1 compiler does something wrong when compiling gcc/real.c (with
-fprofile-generate). The function div_significands() (inlined into
do_divide()) returns a wrong result due to bad register usage in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
Dominik Vogt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
--- Comment #12 from Dominik Vogt ---
(The test just finished; the Ice is present without the patch too.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
--- Comment #11 from Dominik Vogt ---
If that is unrelated, the patch does not cause any regressions on a biarch
build. Sould I also test it in a 31-bit changeroot?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
--- Comment #9 from Dominik Vogt ---
I think I've already tested this commit without the patch and did not get that
Ice, but maybe my memory fails me. I'm just running the test suite again with
the commit reverted to make sure ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
--- Comment #7 from Dominik Vogt ---
With the patch I get an Ice with -m31:
spawn -ignore SIGHUP .../build/gcc/xgcc -B.../build/gcc/
.../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709
--- Comment #5 from Dominik Vogt ---
@Matthias: So far it only happens for me when building a gcc rpm from source on
a (very slow VM), but not when compiling the same sources. Is there anything
special about your build machine or environment on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
Dominik Vogt changed:
What|Removed |Added
Component|rtl-optimization|regression
--- Comment #3 from Dominik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
--- Comment #1 from Dominik Vogt ---
Created attachment 37705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37705=edit
Reload dump (broken)
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Target Milestone: ---
Host: s390x
Target: s390x
Created attachment 37704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37704=edit
Ira dump (ok)
It looks like Lra d
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
Target Milestone: ---
Host: s390x
When testing with
make -k check-go RUNTESTFLAGS="--target_board=unix\{-m31,-m64\}"
The testgo.test/test/en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69766
--- Comment #1 from Dominik Vogt ---
If I understand the GOARCH environtment variable right it's value is just the
architecture of the build system. So, this test is bound to fail for any
multiarch target with the non-standard architecture, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69766
--- Comment #2 from Dominik Vogt ---
Created attachment 37663
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37663=edit
Experimental patch
Is the attached patch the right way to deal with this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451
--- Comment #12 from Dominik Vogt ---
The patch works on s390x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451
--- Comment #9 from Dominik Vogt ---
I.e. free(0x1) is called:
Load foobar.1497 to r12
0x8998 <+40>:larl%r12,0x80002408
(gdb) p /x $r12
0x80002408
First malloc call, store mem pointer in foobar.1497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69625
Dominik Vogt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69625
--- Comment #1 from Dominik Vogt ---
It's a bug in the S/390 backend that sometimes trashes r6 in vararg functions.
We're working on a fix.
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Target: s390x
Created attachment 37554
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37554=edit
.s file of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089
--- Comment #5 from Dominik Vogt ---
No, up to now you're the only one who commented on it. I keep pinging it once
in a while.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555
--- Comment #5 from Dominik Vogt ---
Hm, actually the chapter about "private" says nothing about how to actually
*handle* a reference type whereas it states that for "firstprivate" and
"lastprivate" the reference must bind to the same object for
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: jakub at gcc dot gnu.org, krebbel at gcc dot gnu.org
Target Milestone: ---
Target: s390x
The test case libgomp.c++/target-6.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555
--- Comment #6 from Dominik Vogt ---
Example:
-- snip --
#include
int main ()
{
int a;
int = a;
printf("a %p\n", );
printf("g %p\n", );
#pragma omp target private (c)
{
printf("t %p\n", );
}
return 0;
}
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555
--- Comment #2 from Dominik Vogt ---
Does it work on other platforms?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555
--- Comment #4 from Dominik Vogt ---
Sure. Can I provide any debug information or another kind of help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69529
Dominik Vogt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69528
Dominik Vogt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Target: s390x
The hyperg functions fails to stay inside the tolerance allowed by the new
test. Either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69528
--- Comment #1 from Dominik Vogt ---
3: 1.25024e-12 2.5e-13
test(data233, toler233)
0: 1.09304e-12 2.5e-13
1: 8.62418e-13 2.5e-13
test(data236, toler236)
0: 1.87073e-10 2.5e-13
1: 6.94984e-12 2.5e-13
2: 9.47298e-12 2.5e-13
3: 3.09248e-12 2.5e-13
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Target: s390x
The assoc_legendre function exceeds the allowed tolerance on s390x for
data033[19
201 - 300 of 464 matches
Mail list logo
