From: Richard Wai <richard@annexi-strayline.com>
To: gcc-patches@gcc.gnu.org
Cc: 'Eric Botcazou' <ebotcazou@adacore.com>,
'Arnaud Charlet' <charlet@adacore.com>,
'Stephen Baird' <baird@adacore.com>
Subject: [PING][PATCH 1/2] Ada: Synchronized private extensions are always limited
Date: Wed, 23 Aug 2023 14:22:54 +0000 [thread overview]
Message-ID: <010d018a22c6e28b-dec61310-ac9d-44db-ab50-f08bedcd2ebe-000000@ca-central-1.amazonses.com> (raw)
In-Reply-To:
[-- Attachment #1: Type: text/plain, Size: 4084 bytes --]
From: Richard Wai <richard@annexi-strayline.com>
Sent: Thursday, August 10, 2023 12:55 AM
To: 'gcc-patches@gcc.gnu.org' <gcc-patches@gcc.gnu.org>
Cc: 'Eric Botcazou' <ebotcazou@adacore.com>; 'Arnaud Charlet'
<charlet@adacore.com>; 'Stephen Baird' <baird@adacore.com>
Subject: [PATCH 1/2] Ada: Synchronized private extensions are always limited
GNAT currently considers a synchronized private extension that derives from
an interface to be limited only when said interface is a concurrent
interface. However it is of course legal for a synchronized private
extension to derive from a limited interface. In this case GNAT fails to
correctly determine that the private extension is limited.
This causes two separate problems that makes discriminated types in such a
case impossible:
1. GNAT inappropriately rejects compilation, claiming default
discriminants on such a private extension are illegal.
2. GNAT fails to generate the expected discriminals for the
unconstrained discriminanted case, leading to the corresponding
discriminants of the "corresponding record" of the underlying concurrent
type to have no identifiers, and thus compilation fails.
Fairly simple fix. If "synchronized" appears in the private extension
declaration, it is limited. This is explicit in the RM as well (7.3(6/2)).
Fixing this bug uncovered of a related bug wrt. TSS address finalizer
generation for constrained subtypes of synchronized private extensions with
no default discriminants. That patch is to follow separately.
Patch file is attached.
-- Begin change log entry --
ada: Private extensions with the keyword "synchronized" are always limited.
GNAT was relying on synchronized private type extensions deriving from a
concurrent interface to determine its limitedness. This does not cover the
case where such an extension derives a limited interface. RM-7.6(6/2) makes
is clear that "synchronized" in a private extension implies the derived type
is limited. GNAT should explicitly check for the presence of "synchronized"
in a private extension declaration, and it should have the same effect as
the presence of "limited".
gcc/ada/
* sem_ch3.adb (Build_Derived_Record_Type): Treat presence of
keyword "synchronized" the same as "limited" when determining if a private
extension is limited.
-- End change log entry --
This patch was bootstrapped on x86_64-*-freebsd13.2. Two new test cases were
added. Note that 4 gnat test cases fail currently on master and are
unrelated to this patch.
Check-ada output of this patch:
=== acats tests ===
Running chapter a ...
Running chapter c2 ...
Running chapter c3 ...
Running chapter c4 ...
Running chapter c5 ...
Running chapter c6 ...
Running chapter c7 ...
Running chapter c8 ...
Running chapter c9 ...
Running chapter ca ...
Running chapter cb ...
Running chapter cc ...
Running chapter cd ...
Running chapter ce ...
Running chapter cxa ...
Running chapter cxb ...
Running chapter cxf ...
Running chapter cxg ...
Running chapter cxh ...
Running chapter cz ...
Running chapter d ...
Running chapter e ...
Running chapter l ...
=== acats Summary ===
# of expected passes 2328
# of unexpected failures 0
Native configuration is x86_64-unknown-freebsd13.2
=== gnat tests ===
Schedule of variations:
unix
Running target unix
FAIL: gnat.dg/specs/alignment2.ads (test for warnings, line 14)
FAIL: gnat.dg/specs/alignment2.ads (test for warnings, line 20)
FAIL: gnat.dg/specs/alignment2.ads (test for warnings, line 38)
FAIL: gnat.dg/specs/alignment2.ads (test for warnings, line 42)
=== gnat Summary ===
# of expected passes 3402
# of unexpected failures 4
# of expected failures 23
# of unsupported tests 10
gnatmake version 14.0.0 20230809 (experimental)
Richard Wai
ANNEXI-STRAYLINE
next reply other threads:[~2023-08-23 14:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-23 14:22 Richard Wai [this message]
2023-09-01 12:06 ` Arnaud Charlet
2023-09-01 12:08 ` Arnaud Charlet
2023-09-12 21:46 ` [PATCH 1/2 v2] " Richard Wai
2023-09-13 7:54 ` Arnaud Charlet
[not found] ` <010d018aa45bb0cf-8a7f2370-3e66-40b4-9ce4-c609f0532443-000000@ca-central-1.amazonses.com>
2023-09-18 8:31 ` [PATCH 1/2 v3] " Marc Poulhiès
2023-09-19 3:40 ` Richard Wai
2023-09-19 12:03 ` [COMMITTED] ada: Private extensions with the keyword "synchronized" " Marc Poulhiès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=010d018a22c6e28b-dec61310-ac9d-44db-ab50-f08bedcd2ebe-000000@ca-central-1.amazonses.com \
--to=richard@annexi-strayline.com \
--cc=baird@adacore.com \
--cc=charlet@adacore.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).