On Tue, May 17, 2022 at 11:06 AM liuhongt via Gcc-patches
wrote:
>
> backend has
>
> 16550(define_insn "*bmi2_bzhi_3_2"
> 16551 [(set (match_operand:SWI48 0 "register_operand" "=r")
> 16552(and:SWI48
> 16553 (plus:SWI48
> 16554(ashift:SWI48 (const_int 1)
> 16555
Hi Uros:
This patch fix Zhaoxin CPU vendor ID detection problem and add zhaoxin
"lujiazui" processor support.
Currently gcc can't recognize Zhaoxin CPU(vendor ID "CentaurHauls" and
"Shanghai") if user use -march=native option, which is confusing for users.
This patch
backend has
16550(define_insn "*bmi2_bzhi_3_2"
16551 [(set (match_operand:SWI48 0 "register_operand" "=r")
16552(and:SWI48
16553 (plus:SWI48
16554(ashift:SWI48 (const_int 1)
16555 (match_operand:QI 2 "register_operand" "r"))
16556
I've committed the patch.
On Fri, May 13, 2022 at 5:22 PM liuhongt via Gcc-patches
wrote:
>
> Here's updated patch which adds ix86_pre_reload_split () to those 2
> define_insn_and_splits.
>
> Assembly Optimization like:
> - vmovq %xmm0, %xmm2
> - vmovdqa .LC0(%rip), %xmm0
>
On Mon, May 16, 2022 at 5:21 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Sat, May 7, 2022 at 7:05 AM liuhongt wrote:
> >
> > This is adjusted patch only for OImode.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > gcc/ChangeLog:
> >
> > PR
On 5/10/22 5:35 PM, Segher Boessenkool wrote:
> Out of interest, did you try using v,?wa (so just two alternatives, not
> four)? Or did you think it wouldresult in measurably worse code? Or
> did you decide it is not such bad backend code size explosion after
> all :-)
So I tried using just
On Sun, 15 May 2022, Iain Buclaw wrote:
> Excerpts from Marc Aurèle La France's message of Mai 12, 2022 10:29 pm:
>> No compiler has any business rejecting files for the sole crime of
>> being symlinked to. The following applies, modulo patch fuzz, to the
>> 9, 10 and 11 series of compilers.
>>
On Mon, 16 May 2022, Jason Merrill via Gcc-patches wrote:
> Ping.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
The validator would not have caught this - `grep -r` rules. :-)
Gerald
---
htdocs/gcc-13/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index f21b546b..a1b64df3 100644
--- a/htdocs/gcc-13/changes.html
+++
On Sat, 14 May 2022, Jakub Jelinek wrote:
> I often just copy from git diff from a year ago, which has the
> disadvantages that issues that are fixed later on keep reappearing.
Ah, makes sense. ;-)
Any idea how we/I might help avoid or mitigate this? (Even a validator
would not catch all, as I
When processing a class template specialization, lookup_template_class
uses structural equality for the specialized type whenever one of its
template arguments uses structural equality. This the sensible thing to
do in a vacuum, but given that we already effectively deduplicate class
This patch adds support to the analyzer for checking usage of ,
with four new warnings.
It adds:
(a) a state-machine for tracking "started" and "ended" states on va_list
instances, implementing two new warnings:
-Wanalyzer-va-list-leak
for complaining about missing va_end after a va_start
libgomp/ChangeLog
2022-05-15 Mohamed Atef
*config/darwin/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
*config/hpux/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
*config/posix/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
*configure: Regenerate.
*Makefile.am (toolexeclib_LTLIBRARIES): Add
Hello,
Gentle ping on this patch.
Thank you!
On Mon, Apr 25, 2022 at 09:04:51AM -0700, Joel Brobecker wrote:
> Hello,
>
> We have noticed that, when running the GCC testsuite on AArch64
> RTEMS 6, we have about 150 tests failing due to a link failure.
> When investigating, we found that all
On Sun, May 08, 2022 at 10:31:04AM +0300, Dimitar Dimitrov wrote:
> This patch fixes a spurious warning for pru-unknown-elf target:
> gcc/testsuite/gcc.dg/mallign.c:12:27: warning: ignoring return value of
> 'malloc' declared with attribute 'warn_unused_result' [-Wunused-result]
>
> For 8-bit
On Sun, May 15, 2022 at 04:18:12PM +0200, Mohamed Atef wrote:
> Ping
>
> في الجمعة، ١٣ مايو، ٢٠٢٢ ٩:١٩ م Mohamed Atef
> كتب:
>
> > Hello Jakub,
> >I am sorry, but should #ifdef __ELF__ put and separate file and also
> > the actual functions (e.g. extern ompd_dll_location_valid (void))
> > I
dynamic_cast can legally return nullptr, so I don't think it's helpful
for -Waddress to warn for
if (dynamic_cast())
// ...
More generally, it's likely not useful to warn for the artificial
POINTER_PLUS_EXPRs created by build_base_path.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok
Hi,
Upstream dmd has now released v2.100.0, this patch merges in the
latest bug fixes since the last sync-up of the release branch, as well
as all new feature changes on development branch.
D front-end changes:
- Import dmd v2.100.0.
- Add bit fields to D, enabled via the
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, May 16, 2022 2:24 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
>> jeffreya...@gmail.com
>> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target
On Mon, 9 May 2022, Jan Hubicka wrote:
> > On second thought, it might be better to keep the assert, and place the loop
> > under 'if (optimize)'?
>
> The problem is that at IPA level it does not make sense to check
> optimize flag as it is function specific. (shlib is OK to check it
> anywhere
On Sat, May 14, 2022 at 11:13:28PM -0400, Jason Merrill wrote:
> On 5/13/22 19:41, Marek Polacek wrote:
> > --- a/gcc/cp/typeck2.cc
> > +++ b/gcc/cp/typeck2.cc
> > @@ -1371,6 +1371,70 @@ digest_init_flags (tree type, tree init, int flags,
> > tsubst_flags_t complain)
> > return digest_init_r
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, May 16, 2022 2:24 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
> jeffreya...@gmail.com
> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target decide
> the method of argument
On Mon, 16 May 2022, Martin Liška wrote:
> I've implemented first version of the patch, please take a look.
I'll comment on the patch, feel free to inform me when I should back off
with forcing my opinion in this thread :)
> --- a/include/plugin-api.h
> +++ b/include/plugin-api.h
> @@ -483,6
Ping.
On 5/10/22 16:48, Jason Merrill wrote:
Ping?
On 5/5/22 14:07, Jason Merrill wrote:
In my patch for PR100545 I added an assert to check for broken
typedefs in
set_underlying_type, and it found one in this case:
rs6000_handle_altivec_attribute had the same problem as
A warning about target-nesting inside target makes sense,
but not if the inner target is one for reverse offload ("device(ancestor:1)").
Thus, silence the warning in this case.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
This documents the partial support for P2231 in the gcc-11 branch,
pushed to that branch.
commit 5d418194ccb39346d2ad022c5b143fe00b2340ac
Author: Jonathan Wakely
Date: Mon May 16 15:33:06 2022
libstdc++: Document support for constexpr optional (P2231R1)
The changes for
Pushed to trunk. Backport to gcc-12 to follow.
-- >8 --
These are the C++23 proposals supported in the gcc-12 branch.
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2023.xml: Update with gcc-12 support.
* doc/html/*: Regenerate.
---
libstdc++-v3/doc/html/manual/status.html
Pushed to trunk. Backports to follow.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/prerequisites.xml: Fix attributes for external
hyperlink.
* doc/html/manual/setup.html: Regenerate.
---
libstdc++-v3/doc/html/manual/setup.html | 2 +-
Pushed to trunk. Backports to gcc-11 and gcc-12 to follow.
-- >8 --
These are the C++23 proposals already supported in the gcc-11 branch.
libstdc++-v3/ChangeLog:
* doc/xml/manual/intro.xml: Include new chapter.
* doc/xml/manual/status_cxx2020.xml: Tweak release numbers.
Pushed to trunk. Backports to all branches needed.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx2020.xml: Fix supported version for
C++20 bit operations.
---
libstdc++-v3/doc/html/manual/status.html | 2 +-
This patch adds support for trunc and extend operations between HF
mode (_Float16) and Decimal Floating Point formats (_Decimal32,
_Decimal64 and _Decimal128).
For simplicity we rely on the implicit conversions inserted by the
compiler between HF and SD/DF/TF modes. The existing bid*_to_binary*
On Mon, 16 May 2022, Rui Ueyama wrote:
> > @Rui: Am I correct that you're interested in thread-safe claim_file? Is
> > there any
> > other function being called paralely?
>
> Yes, I want a thread-safe claim_file. And that function seems to be
> the only function in mold that is called in
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, May 16, 2022 1:18 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
>> jeffreya...@gmail.com
>> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target
On Mon, May 16, 2022 at 8:04 PM Martin Liška wrote:
>
> On 5/16/22 12:28, Richard Biener wrote:
> > On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
> >>
> >> Version handshaking is doable, but it feels like we are over-designing
> >> an API, given that the real providers of this plugin API
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, May 16, 2022 1:18 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
> jeffreya...@gmail.com
> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target decide
> the method of argument
Another comment-only change.
Otherwise, just re-diffed Frederik's patch. Mostly s/.c/.cc/, but I
added one '. ' that got lost.
On 15.12.21 16:54, Frederik Harwath wrote:
* graphite-sese-to-poly.c (build_poly_sr_1): Fix a typo and
a reference to a variable which does not
Rediffed Frederik's patch. Actual change is just s/.c/.cc/ but also a
missing space → tab.
On 15.12.21 16:54, Frederik Harwath wrote:
The SSA names for which this function gets used are always SCoP
parameters and hence "isl_id_for_parameter" is a better name. It also
explains the prefix "P_"
As requested by Richard: Rediffed patch.
Changes: s/.c/.cc/ + some whitespace changes.
(At least in my email reader, some were lost. I also fixed too-long line
issues.)
In addition, FOR_EACH_LOOP was replaced by 'for (auto loop : ...'
(macro was removed late in GCC 12 development →
On Mon, 16 May 2022, liuhongt wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
> Ok for trunk?
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> PR tree-optimization/105591
> * tree-ssa-forwprop.cc (simplify_bitfield_ref): Clamp
> vec_perm_expr index.
>
>
A generous [snip], as this has been getting a bit long.
On Sun, 15 May 2022 at 03:21, Palmer Dabbelt wrote:
> I am worried about bad
> actors leveraging any policy to make a bunch of noise, as that's a
> pretty persistent problem in RISC-V land and it looks like things are
> going to get worse
This removes is_gimple_condexpr, note the vectorizer via patterns
still creates COND_EXPRs with embedded GENERIC conditions and has
a reference to the function in comments. Otherwise is_gimple_condexpr
is now equal to is_gimple_val.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
This goes away with the selection operand allowed to be a GENERIC
tcc_comparison tree. It keeps those for vectorizer pattern recog,
those are short lived and removing this instance is a bigger task.
The patch doesn't yet remove dead code and functionality, that's
left for a followup. Instead
Richard Sandiford via Gcc-patches writes:
> Tamar Christina writes:
>>> -Original Message-
>>> From: Richard Sandiford
>>> Sent: Monday, May 16, 2022 12:36 PM
>>> To: Tamar Christina
>>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
>>> jeffreya...@gmail.com
>>> Subject: Re:
On 5/13/22 18:35, Richard Sandiford wrote:
Christophe Lyon via Gcc-patches writes:
@@ -19352,7 +19363,9 @@ aarch64_legitimate_constant_p (machine_mode mode, rtx x)
{
/* Support CSE and rematerialization of common constants. */
if (CONST_INT_P (x)
- || (CONST_DOUBLE_P (x) &&
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, May 16, 2022 12:36 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
>> jeffreya...@gmail.com
>> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the
On 5/16/22 12:28, Richard Biener wrote:
> On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
>>
>> Version handshaking is doable, but it feels like we are over-designing
>> an API, given that the real providers of this plugin API are only GCC
>> and LLVM and the users of the API are BFD ld, gold
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, May 16, 2022 12:36 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
> jeffreya...@gmail.com
> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target decide
> the method of
"Pop, Sebastian" writes:
> Please see attached the patch back-ported to branches 12, 11, 10, and 9.
> Tested on aarch64-linux with bootstrap and regression test.
> Ok to commit to the GCC active branches?
OK, thanks. Only very safe patches are supposed to be going into GCC 9
at this stage, and
This finishes the remaining parts of the gimple_build API enhancement,
converting the remaining workers to receive a gimple_stmt_iterator,
direction and update argument. It also moves the code_helper
receiving functions from gimple-match.h to gimple-fold.h.
Bootstrapped and tested on
Tamar Christina writes:
> Hi All,
>
> Some targets require function parameters to be promoted to a different
> type on expand time because the target may not have native instructions
> to work on such types. As an example the AArch64 port does not have native
> instructions working on integer 8-
On Mon, 16 May 2022, Tobias Burnus wrote:
> Hi all,
>
> I would like to ping the following patches from Frederik's
> "[PATCH 00/40] OpenACC "kernels" Improvements" series
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586901.html
> patch set thread link:
>
On 5/11/22 18:43, Joseph Myers wrote:
There are various coding style issues in the patch; at least missing space
before '(' and '&&' at end of line (should be at start of line). It will
also need to be updated for .c files having been renamed to .cc in the GCC
source tree.
Thanks, I've fixed
On 16/05/2022 11:28, Tobias Burnus wrote:
While 'vendor' and 'kind' is well defined, 'arch' and 'isa' isn't.
When looking at an 'metadirective' testcase (which oddly uses 'arch(amd)'),
I noticed that LLVM uses 'arch(amdgcn)' while we use 'gcn', cf. e.g.
Hi all,
I would like to ping the following patches from Frederik's
"[PATCH 00/40] OpenACC "kernels" Improvements" series
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586901.html
patch set thread link:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/thread.html#586901
(A)
Richard Biener writes:
> tree.h already contains combined_fn handling at the top and moving
> code_helper away from gimple-match.h makes improving the gimple_build
> API easier.
Nice. Thanks for doing this.
Richard
>
> Bootstrapped on x86_64-unknown-linux-gnu.
>
> Will push this if there are
On Mon, May 16, 2022 at 6:28 PM Richard Biener
wrote:
>
> On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
> >
> > Version handshaking is doable, but it feels like we are over-designing
> > an API, given that the real providers of this plugin API are only GCC
> > and LLVM and the users of the
tree.h already contains combined_fn handling at the top and moving
code_helper away from gimple-match.h makes improving the gimple_build
API easier.
Bootstrapped on x86_64-unknown-linux-gnu.
Will push this if there are no comments when I've finished
enhancing the gimple_build API (and moving
Christophe Lyon via Gcc-patches writes:
> These tests exercise exception handling with Decimal Floating-Point
> type.
>
> dfp-1.C and dfp-2.C check that thrown objects of such types are
> properly caught, whether when using C++ classes (decimalXX) or via GCC
> mode attributes.
>
>
On Mon, May 16, 2022 at 11:18 AM Richard Sandiford via Gcc-patches
wrote:
>
> Martin Liška writes:
> > It's the warning I see every time I build GCC:
> >
> > In file included from /home/marxin/Programming/gcc/gcc/coretypes.h:478,
> > from
On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
>
> Version handshaking is doable, but it feels like we are over-designing
> an API, given that the real providers of this plugin API are only GCC
> and LLVM and the users of the API are BFD ld, gold and mold. It is
> unlikely that we'll have
While 'vendor' and 'kind' is well defined, 'arch' and 'isa' isn't.
When looking at an 'metadirective' testcase (which oddly uses 'arch(amd)'),
I noticed that LLVM uses 'arch(amdgcn)' while we use 'gcn', cf. e.g.
'clang/lib/Headers/openmp_wrappers/math.h'.
(Side note: we use the target triplet
On Sat, 14 May 2022, Palmer Dabbelt wrote:
> > Hmm, should we? We only support `-misa-spec=<2.2|20190608|20191213>'
> > already and this update is fine for r.2.2+. If someone has pre-r.2.2 hw,
> > then it's been already unsupported even before this change (as from GCC 11
> > AFAICS). Have I
On Mon, May 16, 2022 at 11:50 AM Jan Hubicka wrote:
>
> > On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
> > >>
> > >> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
> > >> is useful if bugs are discovered in old versions that you by definition
> > >> cannot
> >
Tested on x86_64-unknown-linux-gnu, pushed.
2022-05-16 Richard Biener
PR rtl-optimization/105577
* g++.dg/torture/pr105577.C: New testcase.
---
gcc/testsuite/g++.dg/torture/pr105577.C | 156
1 file changed, 156 insertions(+)
create mode 100644
Hi Tobias,
On Sat, 14 May 2022, Tobias Burnus wrote:
> Jakub and I discussed the other day that it would be useful
> to have a page similar to
> https://gcc.gnu.org/projects/cxx-status.html
> to provide by-GCC-version information of the which OpenMP are supported.
this looks like a great idea,
Version handshaking is doable, but it feels like we are over-designing
an API, given that the real providers of this plugin API are only GCC
and LLVM and the users of the API are BFD ld, gold and mold. It is
unlikely that we'll have dozens of more compilers or linkers in the
near future. So, I
> On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
> >>
> >> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
> >> is useful if bugs are discovered in old versions that you by definition
> >> cannot
> >> fix but can apply workarounds to. Note the actual compiler used
Hi all,
small update (interdiff): s/s/S/ for consistency, missed one GCC 13 commit, and
improved wording of the enter/exit change. (New wording better captures the
effect; I was thinking too much of the changed spec wording not of the effective
result.)
Plus added some cross-ref hyperlinks to
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR tree-optimization/105591
* tree-ssa-forwprop.cc (simplify_bitfield_ref): Clamp
vec_perm_expr index.
gcc/testsuite/ChangeLog:
* gcc.dg/pr105591.c: New test.
---
On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
>>
>> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
>> is useful if bugs are discovered in old versions that you by definition
>> cannot
>> fix but can apply workarounds to. Note the actual compiler used might still
On 5/12/22 09:00, Richard Biener via Gcc-patches wrote:
> On Wed, May 11, 2022 at 5:10 PM Bruno Haible wrote:
>>
>> The patch that was so far added for documenting --with-zstd is pretty
>> minimal:
>> - it refers to undocumented options --with-zstd-include and
>> --with-zstd-lib;
>> - it
>
> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
> is useful if bugs are discovered in old versions that you by definition cannot
> fix but can apply workarounds to. Note the actual compiler used might still
> differ. Note that still isn't clean API documentation /
The following tries to correct get_origin_and_offset_r not handling
non-constant sizes of array elements in ARRAY_REFs and non-constant
offsets of COMPONENT_REFs. It isn't exactly clear how such failures
should be treated in this API and existing handling isn't consistent
here either. The
On Mon, 16 May 2022, Richard Biener wrote:
> Is there an API document besides the header itself somewhere?
It's on the wiki: https://gcc.gnu.org/wiki/whopr/driver
(sadly the v3 entrypoint was added there without documentation)
Alexander
On Mon, May 16, 2022 at 10:37 AM Rui Ueyama via Gcc-patches
wrote:
>
> On Mon, May 16, 2022 at 2:38 PM Alexander Monakov wrote:
> >
> > On Mon, 16 May 2022, Rui Ueyama wrote:
> >
> > > If it is a guaranteed behavior that GCC of all versions that support
> > > only get_symbols_v2 don't leave a
On Sat, May 7, 2022 at 7:05 AM liuhongt wrote:
>
> This is adjusted patch only for OImode.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/104610
> * config/i386/i386-expand.cc (ix86_expand_branch): Use ptest
>
On Mon, May 16, 2022 at 9:53 AM Martin Liška wrote:
>
> Fixes:
> opts-global.cc:75:15: runtime error: store to address 0x0bc9be70 with
> insufficient space for an object of type 'char'
> which happens when mask == 0, len == 0 and we allocate zero elements.
> Eventually, result[0] is called
Martin Liška writes:
> It's the warning I see every time I build GCC:
>
> In file included from /home/marxin/Programming/gcc/gcc/coretypes.h:478,
> from /home/marxin/Programming/gcc/gcc/expmed.cc:26:
> In function ‘poly_uint16 mode_to_bytes(machine_mode)’,
> inlined from
On Mon, May 16, 2022 at 10:47:53AM +0200, Eric Botcazou wrote:
> > It won't work for types larger than size of address, it would need to use
> > dwarf_OP (DW_OP_const_type) instead of DW_OP_lit0 in that case.
> > But maybe TRUTH_NOT_EXPR will be never seen for such types and after all,
> > even
> It won't work for types larger than size of address, it would need to use
> dwarf_OP (DW_OP_const_type) instead of DW_OP_lit0 in that case.
> But maybe TRUTH_NOT_EXPR will be never seen for such types and after all,
> even the loc_list_from_tree_1 INTEGER_CST case doesn't handle that
> (the RTL
The problem is that the resolution of expanded names implicitly assumes
that the visible and private homonyms in a given scope are segregated on
the homonym chain, and this was no longer the case for equality operators
in the specific case at stake.
Tested on x86_64-pc-linux-gnu, committed on
When expanding attribute Loop_Entry we create constant object
declarations and put them just before the loop. The current values of
variables at the point of Loop_Entry attribute must not be used when
analysing the initialization expressions of these constants, because
they might be different from
The current value propagation applies only to assignable objects and
doesn't make sense for subprogram entities. This was a mistake
introduced when extending the current value propagation years ago.
Cleanup related to fixing interference between expansion of attribute
Loop_Entry and current value
This patch corrects an error in the compiler whereby a function
requiring the generation of a postconditions procedure may cause an
uninitialized memory read when the return type
Has_Unconstrained_Elements or is an unconstrained array.
The error occurs because evaluation of postconditions happens
An object declaration (other than a deferred constant declaration)
causes freezing where it occurs (13.14(6)), which means every name
occurring within it causes freezing (13.14(4/1)), and when the name in a
subtype_mark causes freezing, the denoted subtype is frozen (13.14(11)).
Hence, one needs
Proof of an assertion is not automatic anymore. Add two assertions
before it to guide the prover.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/s-aridou.adb (Double_Divide): Add intermediate
assertions.diff --git a/gcc/ada/libgnat/s-aridou.adb
Before this commit, a GNAT compiled with assertions would crash when
attempting to emit CUDA symbols in ALI files for spark_mode/ghost
packages, whose content is a single null statement.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* lib-writ.adb (Output_CUDA_Symbols):
Setting this parameter to zero when calling the Configure procedure has
the effect of disabling completely the tracking of the biggest memory
users, which wasn't clear from the current documentation. So this patch
enhances the documentation of both the Configure procedure as well as
the Dump
The QNX version of __gnat_install_handler calls sigaction for a number
of signals, and then prints an error message when the the call failed.
But unfortunately, except for the first call, we forgot to store
sigaction's return value, so the check that ensues uses a potentially
uninitialized
On QNX, the sigaction handler is incorrectly installed via the
sa_handler field of struct sigaction, rather than the sa_sigaction
field. This triggers a compilation warning due to a mismatch between the
function's signature and the field's type.
| init.c:2614:18: warning: assignment to 'void
When building the GNAT runtime for QNX, we get the following warning:
| cstreams.c: In function '__gnat_full_name':
| cstreams.c:209:5: warning: implicit declaration of function 'realpath'
| [-Wimplicit-function-declaration]
| 209 | realpath (nam, buffer);
| |
The functions in subpackage Storage_Model_Support (apart from the
Has_*_Aspect functions) are revised to have assertions that will fail
when passed a parameter that doesn't specify the appropriate aspect
(either aspect Storage_Model_Type or Designated_Storage_Model), instead
of returning Empty for
bzero is marked as legacy in POSIX.1-2001, and using it triggers a
deprecation warnings on some systems such as QNX. This change adjusts
the one place where we use it in terminals.c to use memset instead.
This, in turns, allows us to get rid of a hack for HP/UX and Solaris.
Tested on
Fix the escaping of the loop variable from the loop scope in both forms
of iterated element associations (i.e. "for J in ..." and "for J of
..."). Create a dedicated scope around the analyses of both loops. Also
create a copy of the Loop_Parameter_Specification instead of analyzing
(and modifying)
The front-end drops the declaration of a temporary on the floor because
Insert_Actions fails to climb up out of an N_Iterated_Component_Association
when the temporary is created during the analysis of its Discrete_Choices.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
*
Fix a regression in the support for Ada 2022's treatment of calls to
abstract subprograms in pre/post-conditions (thanks to Javier Miranda
for producing this patch).
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_disp.adb (Check_Dispatching_Context): When checking to
The key is that the protected type is a (limited) private type, which
fools a test in Cleanup_Scopes.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* inline.adb (Cleanup_Scopes): Test the underlying type.diff --git a/gcc/ada/inline.adb b/gcc/ada/inline.adb
---
The semantic analysis of predicates involves a fair amount of tree
copying because of both semantic and implementation considerations, and
there is a difficulty with quantified expressions since they declare a
new entity that cannot be shared between the various copies of the tree.
This change
This moves the implementation of AI12-0101 + AI05-0123 from the expander
to the semantic analyzer and completes the implementation of AI12-0413,
which are both binding interpretations in Ada 2012, fixing a few bugs in
the process and removing a fair amount of duplicated code throughout.
Tested on
Finalization of a record object is required to finalize any components
that have an access discriminant constrained by a per-object expression
before other components. This includes the case of a type extension;
"early finalization" components of the parent type are required to be
finalized before
1 - 100 of 120 matches
Mail list logo
