* [Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
2020-04-22 7:05 [Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 jakub at gcc dot gnu.org
@ 2020-04-22 7:06 ` jakub at gcc dot gnu.org
2020-04-22 12:10 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-22 7:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |10.0
CC| |krebbel at gcc dot gnu.org
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
2020-04-22 7:05 [Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 jakub at gcc dot gnu.org
2020-04-22 7:06 ` [Bug target/94704] " jakub at gcc dot gnu.org
@ 2020-04-22 12:10 ` jakub at gcc dot gnu.org
2020-04-22 12:41 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-22 12:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
2020-04-22 7:05 [Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 jakub at gcc dot gnu.org
2020-04-22 7:06 ` [Bug target/94704] " jakub at gcc dot gnu.org
2020-04-22 12:10 ` jakub at gcc dot gnu.org
@ 2020-04-22 12:41 ` jakub at gcc dot gnu.org
2020-04-22 16:38 ` krebbel at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-22 12:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Completely untested guess:
--- gcc/config/s390/s390.c.jj 2020-03-14 08:14:47.097741411 +0100
+++ gcc/config/s390/s390.c 2020-04-22 14:24:17.980091105 +0200
@@ -11917,7 +11917,8 @@ s390_function_arg_vector (machine_mode m
for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
{
- if (TREE_CODE (field) != FIELD_DECL)
+ if (TREE_CODE (field) != FIELD_DECL
+ || cxx17_empty_base_field_p (field))
continue;
if (single == NULL_TREE)
@@ -11967,7 +11968,8 @@ s390_function_arg_float (machine_mode mo
for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
{
- if (TREE_CODE (field) != FIELD_DECL)
+ if (TREE_CODE (field) != FIELD_DECL
+ || cxx17_empty_base_field_p (field))
continue;
if (single == NULL_TREE)
(on top of the today posted cxx17_empty_base_field_p patch).
Though, of course that doesn't handle the -Wpsabi part if s390{,x} wants to
emit such diagnostics; for that the functions or their caller should determine
if they would make a different ABI decisions if the field wouldn't be skipped.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
2020-04-22 7:05 [Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 jakub at gcc dot gnu.org
` (2 preceding siblings ...)
2020-04-22 12:41 ` jakub at gcc dot gnu.org
@ 2020-04-22 16:38 ` krebbel at gcc dot gnu.org
2020-04-23 14:38 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: krebbel at gcc dot gnu.org @ 2020-04-22 16:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Andreas Krebbel <krebbel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2020-04-22
Status|UNCONFIRMED |NEW
--- Comment #2 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
You patch fixes the testcases on IBM Z. I'll run a full bootstrap test over
night.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
2020-04-22 7:05 [Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 jakub at gcc dot gnu.org
` (3 preceding siblings ...)
2020-04-22 16:38 ` krebbel at gcc dot gnu.org
@ 2020-04-23 14:38 ` jakub at gcc dot gnu.org
2020-04-27 7:12 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-23 14:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Bug 94704 depends on bug 94383, which changed state.
Bug 94383 Summary: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
2020-04-22 7:05 [Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 jakub at gcc dot gnu.org
` (4 preceding siblings ...)
2020-04-23 14:38 ` jakub at gcc dot gnu.org
@ 2020-04-27 7:12 ` cvs-commit at gcc dot gnu.org
2020-04-27 7:14 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-27 7:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:9612a4833d761e3beda083a3e4dc92feba3b01bc
commit r10-7985-g9612a4833d761e3beda083a3e4dc92feba3b01bc
Author: Jakub Jelinek <jakub@redhat.com>
Date: Mon Apr 27 09:11:57 2020 +0200
s390: Fix C++14 vs. C++17 ABI incompatibility on s390{,x} [PR94704]
The following patch fixes the C++14 vs. C++17 ABI passing incompatibility
on s390x-linux.
Bootstrapped/regtested on s390x-linux without and with the patch, the
difference being:
-FAIL: tmpdir-g++.dg-struct-layout-1/t032
cp_compat_x_alt.o-cp_compat_y_tst.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t032
cp_compat_x_tst.o-cp_compat_y_alt.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t032
cp_compat_x_tst.o-cp_compat_y_tst.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t055
cp_compat_x_alt.o-cp_compat_y_alt.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t055
cp_compat_x_alt.o-cp_compat_y_tst.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t055
cp_compat_x_tst.o-cp_compat_y_alt.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t055
cp_compat_x_tst.o-cp_compat_y_tst.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t056
cp_compat_x_alt.o-cp_compat_y_alt.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t056
cp_compat_x_alt.o-cp_compat_y_tst.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t056
cp_compat_x_tst.o-cp_compat_y_alt.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t056
cp_compat_x_tst.o-cp_compat_y_tst.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t057
cp_compat_x_alt.o-cp_compat_y_alt.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t057
cp_compat_x_alt.o-cp_compat_y_tst.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t057
cp_compat_x_tst.o-cp_compat_y_alt.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t057
cp_compat_x_tst.o-cp_compat_y_tst.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t058
cp_compat_x_alt.o-cp_compat_y_alt.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t058
cp_compat_x_alt.o-cp_compat_y_tst.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t058
cp_compat_x_tst.o-cp_compat_y_alt.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t058
cp_compat_x_tst.o-cp_compat_y_tst.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t059
cp_compat_x_alt.o-cp_compat_y_alt.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t059
cp_compat_x_alt.o-cp_compat_y_tst.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t059
cp_compat_x_tst.o-cp_compat_y_alt.o execute
-FAIL: tmpdir-g++.dg-struct-layout-1/t059
cp_compat_x_tst.o-cp_compat_y_tst.o execute
when performing ALT_CXX_UNDER_TEST=g++ testing with a system GCC 10
compiler
from a week ago. So, the alt vs. alt FAILs are all expected (we know
before
this patch there is an ABI incompatibility) and some alt vs. tst (or tst
vs.
alt) FAILs too - that depends on if the particular x or y test is compiled
with -std=c++14 or -std=c++17 - if x_tst is compiled with -std=c++14 and
y_alt is compiled with -std=c++17, then it should FAIL, similarly if x_alt
is compiled with -std=c++17 and y_tst is compiled with -std=c++14.
2020-04-27 Jakub Jelinek <jakub@redhat.com>
PR target/94704
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Ignore cxx17_empty_base_field_p fields.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
2020-04-22 7:05 [Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 jakub at gcc dot gnu.org
` (5 preceding siblings ...)
2020-04-27 7:12 ` cvs-commit at gcc dot gnu.org
@ 2020-04-27 7:14 ` jakub at gcc dot gnu.org
2020-04-28 8:27 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-27 7:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk, should not be backported as it is an ABI change.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
2020-04-22 7:05 [Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 jakub at gcc dot gnu.org
` (6 preceding siblings ...)
2020-04-27 7:14 ` jakub at gcc dot gnu.org
@ 2020-04-28 8:27 ` cvs-commit at gcc dot gnu.org
2020-04-29 20:40 ` cvs-commit at gcc dot gnu.org
2021-11-05 23:18 ` timturnerc at yahoo dot com
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-28 8:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:dde5ce541e3258276848aee85229a71c0e5f6965
commit r10-8007-gdde5ce541e3258276848aee85229a71c0e5f6965
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Apr 28 10:26:24 2020 +0200
s390: -Wpsabi diagnostics for C++14 vs. C++17 ABI incompatibility on
s390{,x} [PR94704]
> We probably have to look into providing a -Wpsabi warning as well.
So like this?
2020-04-28 Jakub Jelinek <jakub@redhat.com>
PR target/94704
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Emit -Wpsabi diagnostics if the ABI
changed.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
2020-04-22 7:05 [Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 jakub at gcc dot gnu.org
` (7 preceding siblings ...)
2020-04-28 8:27 ` cvs-commit at gcc dot gnu.org
@ 2020-04-29 20:40 ` cvs-commit at gcc dot gnu.org
2021-11-05 23:18 ` timturnerc at yahoo dot com
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-29 20:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:48e54fea7ba4a7cb7b3d1505951383120220e394
commit r10-8057-g48e54fea7ba4a7cb7b3d1505951383120220e394
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed Apr 29 22:38:01 2020 +0200
s390: Fix up -Wpsabi diagnostics + [[no_unique_address]] empty member fix
[PR94704]
So, based on the yesterday's discussions, similarly to powerpc64le-linux
I've done some testing for s390x-linux too.
First of all, I found a bug in my patch from yesterday, it was printing
the wrong type like 'double' etc. rather than the class that contained such
the element. Fix below.
For s390x-linux, I was using
struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { double a; };
struct B : public X { double a; };
struct C : public Y { double a; };
struct D : public Z { double a; };
struct E : public U { double a; };
struct F { [[no_unique_address]] X x; double a; };
struct G { [[no_unique_address]] Y y; double a; };
struct H { [[no_unique_address]] Z z; double a; };
struct I { [[no_unique_address]] U u; double a; };
struct J { double a; [[no_unique_address]] X x; };
struct K { double a; [[no_unique_address]] Y y; };
struct L { double a; [[no_unique_address]] Z z; };
struct M { double a; [[no_unique_address]] U u; };
#define T(S, s) extern S s; extern void foo##s (S); int bar##s () { foo##s
(s); return 0; }
T (A, a)
T (B, b)
T (C, c)
T (D, d)
T (E, e)
T (F, f)
T (G, g)
T (H, h)
T (I, i)
T (J, j)
T (K, k)
T (L, l)
T (M, m)
as testcase and looking for "\tld\t%f0,".
While g++ 9 with -std=c++17 used to pass in fpr just
A, g++ 9 -std=c++14, as well as current trunk -std=c++14 & 17
and clang++ from today -std=c++14 & 17 all pass A, B, C
in fpr and nothing else. The intent stated by Jason seems to be
that A, B, C, F, G, J, K should all be passed in fpr.
Attached are two (updated) versions of the patch on top of the
powerpc+middle-end patch just posted.
The first one emits two separate -Wpsabi warnings like powerpc, one for
the -std=c++14 vs. -std=c++17 ABI difference and one for GCC 9 vs. 10
[[no_unique_address]] passing changes, the other one is silent about the
second case.
2020-04-29 Jakub Jelinek <jakub@redhat.com>
PR target/94704
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Use DECL_FIELD_ABI_IGNORED instead of
cxx17_empty_base_field_p. In -Wpsabi diagnostics use the type
passed to the function rather than the type of the single element.
Rename cxx17_empty_base_seen variable to empty_base_seen, change
type to int, and adjust diagnostics depending on if the field
has [[no_unique_attribute]] or not.
* g++.target/s390/s390.exp: New file.
* g++.target/s390/pr94704-1.C: New test.
* g++.target/s390/pr94704-2.C: New test.
* g++.target/s390/pr94704-3.C: New test.
* g++.target/s390/pr94704-4.C: New test.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
2020-04-22 7:05 [Bug target/94704] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390 jakub at gcc dot gnu.org
` (8 preceding siblings ...)
2020-04-29 20:40 ` cvs-commit at gcc dot gnu.org
@ 2021-11-05 23:18 ` timturnerc at yahoo dot com
9 siblings, 0 replies; 11+ messages in thread
From: timturnerc at yahoo dot com @ 2021-11-05 23:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Tim Turner <timturnerc at yahoo dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |timturnerc at yahoo dot com
--- Comment #7 from Tim Turner <timturnerc at yahoo dot com> ---
With this patch (not sure yet whether it's relevant) in place:
... http://www-look-4.com/category/computers/
diff --git a/gdb/testsuite/lib/gdbserver-support.exp
b/gdb/testsuite/lib/gdbserver-support.
Exp https://komiya-dental.com/health/healthy-foods/
index a2cc80f28d..7b9c0eef6e 100644
--- a/gdb/testsuite/lib/gdbserver-support.exp
http://www.iu-bloomington.com/services/travel-services/
+++ b/gdb/testsuite/lib/gdbserver-support.exp
@@ -451,8 +451,10 @@ proc gdbserver_exit { is_mi } {
https://waytowhatsnext.com/technology/korean-technology/
# We use expect rather than gdb_expect because
# we want to suppress printing exception messages, otherwise,
http://www.wearelondonmade.com/category/health/
# remote_expect, invoked by gdb_expect, prints the exceptions.
+ set read_prompt 0
expect { http://www.jopspeech.com/category/property/
-i "$gdb_spawn_id" -re "$gdb_prompt $" {
+ set read_prompt 1 http://joerg.li/category/technology/
exp_continue
}
-i "$server_spawn_id" eof {
http://connstr.net/property/mars-researches/
@@ -463,6 +465,7 @@ proc gdbserver_exit { is_mi } {
warning "Timed out waiting for EOF in server after
$monitor_exit" http://the-hunters.org/category/technology/
}
}
+ gdb_assert {$read_prompt}
}
} http://embermanchester.uk/health/social-privacy/
close_gdbserver
...
and running in parallel with:
http://fishingnewsletters.co.uk/category/shopping/
...
$ stress -c 5 http://www.slipstone.co.uk/category/services/
...
I ran into:
...
(gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 2
http://www.logoarts.co.uk/category/travel/
Remote debugging from host ::1, port 34088^M
Process build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target
created; pid http://www.go-mk-websites.co.uk/category/shopping/ = 8649^M
monitor exit^M
(gdb) Killing process(es): 8649^M
http://www.acpirateradio.co.uk/technology/facetime/
#9 0x16a2c57 in pop_all_targets_at_and_above(strata)
/home/vries/gdb_versions/devel/src/gdb/target.c:678
http://www.mconstantine.co.uk/category/shopping/
#10 0x1442749 in remote_unpush_target
http://www.compilatori.com/tech/xiaomi/
/home/vries/gdb_versions/devel/src/gdb/remote.c:5522
#11 0x1458c16 in remote_target::readchar(int)
/home/vries/gdb_versions/devel/src/gdb/remote.c:9137
https://www.webb-dev.co.uk/sports/how-to-choose-sportwear/
#12 0x145b25b in remote_target::getpkt_or_notif_sane_1(std::vector<char,
gdb::default_init_allocator<char, std::allocator<char> > >*, int, int, int*)
^ permalink raw reply [flat|nested] 11+ messages in thread