On Fri, 6 May 2022 at 16:00, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
> > b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
> > index c24c0548724..1ef4ea2087b 100644
> > --- a/gcc/config/aarch64/aarch64-sve-builtins
On Wed, May 11, 2022 at 07:41:31AM +0530, Siddhesh Poyarekar wrote:
> The asan initializer registers __builtin_object_size for languages that
> don't have it, e.g. Fortran. Register __builtin_dynamic_object_size too
> (we need both because __builtin_dynamic_object_size computation may
> involve ge
On 5/10/22 8:43 PM, Yonghong Song wrote:
On 5/6/22 2:18 PM, David Faust wrote:
On 5/5/22 16:00, Yonghong Song wrote:
On 5/4/22 10:03 AM, David Faust wrote:
On 5/3/22 15:32, Joseph Myers wrote:
On Mon, 2 May 2022, David Faust via Gcc-patches wrote:
Consider the following example:
Hi Jonathan,
Thanks for fixing the tests and the guidance regarding the patch! I rebased the
patch on top of that commit (b6b66006787b0991e94f15c7b5c56403f1eb85fb) and
fixed all issues (I believe) which you pointed out. I also added the original
reproducer to the test case as you suggested.
I
On 5/6/22 2:18 PM, David Faust wrote:
On 5/5/22 16:00, Yonghong Song wrote:
On 5/4/22 10:03 AM, David Faust wrote:
On 5/3/22 15:32, Joseph Myers wrote:
On Mon, 2 May 2022, David Faust via Gcc-patches wrote:
Consider the following example:
#define __typetag1 __attribute__((btf_
On Mon, May 9, 2022 at 4:28 PM Uros Bizjak wrote:
>
> On Mon, May 9, 2022 at 4:03 AM liuhongt wrote:
> >
> > Similarly optimize movl + vmovq to vmovd.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > gcc/ChangeLog:
> >
> > PR target/104915
> >
The asan initializer registers __builtin_object_size for languages that
don't have it, e.g. Fortran. Register __builtin_dynamic_object_size too
(we need both because __builtin_dynamic_object_size computation may
involve generating __builtin_object_size as a fallback) so that
gfortran.dg/ubsan/bind
LGTM, I think document what we really did in GCC 12 is never too late :P
On Fri, Apr 29, 2022 at 2:23 AM Palmer Dabbelt wrote:
>
> ---
> IMO this one is worth documenting too, not sure if it's too late for
> gcc-12's docs (due to those branch commits) so I haven't committed it
> yet to avoid an
LGTM, that's only added a new option for RISC-V and won't affect all
other targets, so I assume I can approve that.
On Wed, May 4, 2022 at 8:27 AM Palmer Dabbelt wrote:
>
> Similar to 37e65643d3e ("testsuite/101269: fix testcase when used with
> -m32"), RISC-V needs to be told not to put symbols
[Sorry for cross-posting to a bunch of lists, I figured it'd be best to
have all the discussions in one thread.]
We currently only support what is defined by official RISC-V
specifications in the various GNU toolchain projects. There's certainly
some grey areas there, but in general that mean
On Tue, May 10, 2022 at 02:58:49PM -0700, Palmer Dabbelt wrote:
> On Thu, 05 May 2022 11:45:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > On Thu, May 05, 2022 at 06:33:20PM +0800, jiawei wrote:
> > > Some compiler target like arm-linux\riscv\power\s390x\xtensa-gcc handle
> > > char as unsigned
Is there anything more required?
On 22-05-03 12:33:43, Piotr Kubaj wrote:
> Here are gmake check-gfortran results requested by FX.
>
> Before patching:
> === gfortran Summary ===
>
> # of expected passes65106
> # of unexpected failures6
> # of expected failure
On 5/10/22 5:46 PM, Peter Bergner 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 :-)
>
> I have not tried that,
On 5/10/22 5:35 PM, Segher Boessenkool wrote:
> If you want to use this same message as commit message, you shouldn't
> say "this patch". Also, try not to use lines more than 72 positions
> wide (which handily is also a good maximum length for email messages,
> that way it can be quoted a few time
Hi!
On Tue, May 10, 2022 at 03:47:40PM -0500, Peter Bergner wrote:
> This patch addresses an issue when compiling the MMA optimized DGEMM kernel
If you want to use this same message as commit message, you shouldn't
say "this patch". Also, try not to use lines more than 72 positions
wide (which h
On Thu, 05 May 2022 11:45:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On Thu, May 05, 2022 at 06:33:20PM +0800, jiawei wrote:
Some compiler target like arm-linux\riscv\power\s390x\xtensa-gcc handle
char as unsigned char, then there are no warnings occur and got FAIL cases.
Just change the typ
Dear all,
I intend to commit the attached patch as obvious within the next
24 hours unless there are objections. It fixes the logic which
is intended to prevent a NULL pointer dereference on invalid
code, which is related to PR104849. (Both PRs by Gerhard).
Co-authored by Steve. Regtested on x
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
handle_mode_attribute. So let's move the fixup into decl_attributes.
This patch addresses an issue when compiling the MMA optimized DGEMM kernel
in OpenBLAS. The MMA code uses all 8 accumulators, which overlap all vs0-vs31
vector registers. Current trunk assigns one of the normal vector inputs to
one of the MMA instructions, which forces us to spill one of the acc
On Tue, 10 May 2022, Christophe Lyon via Gcc-patches wrote:
> > Note that for conversion from DFP to HFmode, double rounding (going via
> > SFmode) probably produces incorrectly rounded results in some cases
> > (though we already have such incorrect results in the other direction for
> > DPD; see
On Tue, May 10, 2022 at 02:56:58PM -0400, Michael Meissner wrote:
> On Tue, May 10, 2022 at 07:27:30AM -0500, Segher Boessenkool wrote:
> > > IMHO, it's something we want to fix as well, based on the reasons:
> > > 1) bif names have the corresponding mnemonics, users would expect 1-1
> > > mappi
On Tue, May 10, 2022 at 07:27:30AM -0500, Segher Boessenkool wrote:
> > IMHO, it's something we want to fix as well, based on the reasons:
> > 1) bif names have the corresponding mnemonics, users would expect 1-1
> > mapping here.
> > 2) clang emits xs{min,max}dp all the time, with cpu type po
On 10/05/2022 16:16, Martin Liška wrote:
The revision caused:
$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ubsan/bind-c-intent-out-2.f90
-fsanitize=undefined -c -O
during GIMPLE pass: ubsan
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ubsan/bind-c-intent-out-2.
On Thu, Apr 28, 2022 at 11:52 PM Richard Biener
wrote:
>
> On Thu, Apr 28, 2022 at 7:54 PM H.J. Lu wrote:
> >
> > On Thu, Apr 28, 2022 at 9:59 AM Jeff Law wrote:
> > >
> > >
> > >
> > > On 4/28/2022 10:27 AM, H.J. Lu wrote:
> > > > On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches
> > > >
Le 09/05/2022 à 22:20, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
we were lacking checks for arguments of type TEAM_TYPE to some
coarray intrinsics (FORM TEAM, CHANGE TEAM, and SYNC TEAM).
The attached patch adds these, and as a bonus verifies that
TEAM NUMBER is a scalar integer.
Re
When compiling Linux kernel with -fcf-protection=branch to enable x86
Indiret Branch Tracking (IBT), ENDBR is added to all global functions.
This creates more "legal" forward edges than necessary. -mmanual-endbr
provides a way to insert ENDBR instruction at function entry only via
the 'cf_check' f
Mark a function with SYMBOL_FLAG_FUNCTION_ENDBR when inserting ENDBR at
function entry. Skip the 4-byte ENDBR when emitting a direct call/jmp
to a local function with ENDBR at function entry.
This has been tested on Linux kernel.
gcc/
PR target/102953
* config/i386/i386-features
When -fcf-protection=branch is used, the compiler will generate jump
tables where the indirect jump is prefixed with the NOTRACK prefix, so
it can jump to non-ENDBR targets. Yet, for NOTRACK prefixes to work, the
NOTRACK specific enable bit must be set, what renders the binary broken
on any environ
The example missed the mode condition in the replacement text.
Committed as obvious.
Segher
2022-05-10 Segher Boessenkool
* doc/md.texi (Defining Mode Iterators): Correct example replacement
text.
---
gcc/doc/md.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
Ping.
On 4/26/22 3:06 PM, Pat Haugen via Gcc-patches wrote:
Fix register count when not splitting Complex IEEE 128-bit args.
For ABI_V4, we do not split complex args. This created a problem because
even though an arg would be passed in two VSX regs, we were only
advancing the
function arg cou
On Mon, May 9, 2022 at 7:51 AM H.J. Lu wrote:
>
> Add .note.GNU-stack section only for Linux since it may not be supported
> on non-Linux OSes. __ELF__ isn't checked since these tests can only run
> on Linux/x86 ELF systems.
>
> PR target/105472
> * gcc.target/i386/iamcu/asm-suppo
Thanks Maciej!
On Tue, May 10, 2022 at 10:05 PM Maciej W. Rozycki wrote:
>
> As at r2.2 of the RISC-V ISA specification[1] (equivalent to version 2.0
> of the "F" and "D" standard architecture extensions for single-precision
> and double-precision floating-point respectively) the FMIN and FMAX
>
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/105284
* include/std/iosfwd: Add declarations for class
templates and typedefs.
* include/std/spanstream (basic_spanbuf, basic_ispanstream)
(basic_ospanstream, basic_
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/105284
* include/std/iosfwd: Add declarations for class
templates and typedefs.
* include/std/syncstream (basic_syncbuf, basic_osyncstream):
Remove default template a
Hi Jakub,
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0cb17a6..452ecfd 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -8534,11 +8534,14 @@ finish_omp_clauses (tree clauses, enum
c_omp_region_type ort)
{
if (handle_omp_array_sections (c, ort))
On 5/10/22 16:20, Alan Modra wrote:
> On Tue, May 10, 2022 at 10:56:22AM +0200, Martin Liška wrote:
>
>> diff --git a/libiberty/hashtab.c b/libiberty/hashtab.c
>
>> @@ -457,15 +457,15 @@ htab_empty (htab_t htab)
>>else if (htab->free_with_arg_f != NULL)
>> (*htab->free_with_arg_f) (h
Wilco Dijkstra writes:
> Hi Richard,
>
>>> There isn't really a better way of doing this within the existing costing
>>> code.
>>
>> Yeah, I was wondering whether we could change something there.
>> ADRP+LDR is logically more expensive than a single LDR, especially
>> when optimising for size, so
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. These tests are generated during 'make
check' and enabling DFP made generation different (not sure if new
non-DFP tests are generated,
Pushed as obvious.
Martin
libiberty/ChangeLog:
* random.c: Remove 'define PTR'.
---
libiberty/random.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libiberty/random.c b/libiberty/random.c
index be8819dd6b8..cd0b7399e73 100644
--- a/libiberty/random.c
+++ b/libiberty/random.c
@@
Hi Richard,
>> There isn't really a better way of doing this within the existing costing
>> code.
>
> Yeah, I was wondering whether we could change something there.
> ADRP+LDR is logically more expensive than a single LDR, especially
> when optimising for size, so I think it's reasonable for the
On Tue, May 10, 2022 at 10:56:22AM +0200, Martin Liška wrote:
> diff --git a/libiberty/hashtab.c b/libiberty/hashtab.c
> @@ -457,15 +457,15 @@ htab_empty (htab_t htab)
>else if (htab->free_with_arg_f != NULL)
> (*htab->free_with_arg_f) (htab->alloc_arg, htab->entries);
>if (
On 5/10/22 09:40, Patrick Palka wrote:
Unlike in C, in C++ the conditional operator yields an lvalue if both
branches are lvalues, so we can just assign to PACK_EXPANSION_PATTERN
and ARGUMENT_PACK_ARGS directly.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK
On 5/10/22 09:40, Patrick Palka wrote:
The accessor macros for TYPE_PACK_EXPANSION/EXPR_PACK_EXPANSION
and TYPE_ARGUMENT_PACK/NONTYPE_ARGUMENT_PACK should check the
tree code of the argument.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
gcc/cp/ChangeLog
On 5/10/22 16:09, Alan Modra wrote:
> On Tue, May 10, 2022 at 10:57:47AM +0200, Martin Liška wrote:
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> @Alan: Are you fine with the change from binutils/gdb perspective?
>
> I'm fine if this isn't going into the binutils-
On Tue, May 10, 2022 at 10:57:47AM +0200, Martin Liška wrote:
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> @Alan: Are you fine with the change from binutils/gdb perspective?
I'm fine if this isn't going into the binutils-gdb repo immediately.
There are occurrences
As at r2.2 of the RISC-V ISA specification[1] (equivalent to version 2.0
of the "F" and "D" standard architecture extensions for single-precision
and double-precision floating-point respectively) the FMIN and FMAX
machine instructions fully match our requirement for the `fminM3' and
`fmaxM3' st
On 5/10/22 15:50, Eric Gallager wrote:
> Hi, please preserve existing style when possible when making this
> replacement; ISTR there are some tools (like for generating
> libiberty's documentation) that depend on the return type being on a
> separate line... If all of the relevant Makefile targets
Hi!
On 2022-05-03T15:46:43+0200, Richard Biener wrote:
> On Tue, May 3, 2022 at 2:29 PM Thomas Schwinge
> wrote:
>> On 2022-05-03T12:53:50+0200, Richard Biener
>> wrote:
>> > On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge
>> > wrote:
>> >> On 2022-05-03T09:17:52+0200, Richard Biener
>> >
On Tue, May 10, 2022 at 08:58:46AM -0400, Jason Merrill wrote:
> On 5/7/22 18:26, Marek Polacek wrote:
> > Corrected version that avoids an uninitialized warning:
> >
> > This PR complains that we emit the "enumeration value not handled in
> > switch" warning even though the enumerator was marked
On Tue, May 10, 2022 at 5:37 AM Martin Liška wrote:
>
> Hi.
>
> As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR).
> Let's removed its usafe in libiberty.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Marti
The following cleans up if-conversions fold_build_cond_expr to
use gimple-match folding instead of GENERIC folding.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-05-10 Richard Biener
* tree-if-conv.cc (fold_build_cond_expr): Use
match-and-simplify to simpli
Unlike in C, in C++ the conditional operator yields an lvalue if both
branches are lvalues, so we can just assign to PACK_EXPANSION_PATTERN
and ARGUMENT_PACK_ARGS directly.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
* coroutines.cc (
The accessor macros for TYPE_PACK_EXPANSION/EXPR_PACK_EXPANSION
and TYPE_ARGUMENT_PACK/NONTYPE_ARGUMENT_PACK should check the
tree code of the argument.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
* cp-tree.h (PACK_EXPANSION_CHECK): D
> On May 10, 2022, at 1:12 AM, Richard Biener wrote:
>
> On Mon, 9 May 2022, Uros Bizjak wrote:
>
>> On Mon, May 9, 2022 at 5:44 PM Qing Zhao wrote:
>>>
>>> Another question:
>>>
>>> I think that this patch might need to be back ported to Gcc12 and GCC11.
>>>
>>> What?s your opinion on th
On 5/10/2022 4:51 AM, Martin Liška wrote:
On 5/10/22 11:55, Andreas Schwab wrote:
The header line should probably be changed since it's no longer about
ANSI or traditional C.
Sure, updated in v2.
OK
jeff
On 5/10/2022 2:56 AM, Martin Liška wrote:
Hi.
As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR).
Let's removed its usafe in libiberty.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
include/ChangeLog:
在 2022-05-10 20:00, Xi Ruoyao 写道:
On Tue, 2022-05-10 at 19:35 +0800, LIU Hao via Gcc-patches wrote:
Subject: [PATCH] Remove size limit of PCH
Make it "Remove size limit of PCH [PR14940]", so once it's committed a
message will show up in bugzilla.
Here is the revised patch.
--
Best reg
On 5/7/22 18:26, Marek Polacek wrote:
Corrected version that avoids an uninitialized warning:
This PR complains that we emit the "enumeration value not handled in
switch" warning even though the enumerator was marked with the
[[maybe_unused]] attribute.
The first snag was that I couldn't just c
Hi!
On 2022-04-20T15:19:38+0200, Tobias Burnus wrote:
> For
>omp parallel shared(array_desc_var)
> the shared-variable is passed to the generated function as
> argument - and replaced by a DECL_VALUE_EXPR inside the parallel region.
>
> If inside the parallel region, a
>
>omp target data
Hi guys,
On Mon, May 09, 2022 at 12:05:51PM +0800, Kewen.Lin wrote:
> on 2022/5/9 09:54, HAO CHEN GUI wrote:
> > This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
> > Tests show that outputs of xs[min/max]dp are consistent with the standard
> > of C99 fmin/max.
> > gcc/
>
On Tue, 2022-05-10 at 19:35 +0800, LIU Hao via Gcc-patches wrote:
> Subject: [PATCH] Remove size limit of PCH
Make it "Remove size limit of PCH [PR14940]", so once it's committed a
message will show up in bugzilla.
> Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
> Signed-off-by:
Le 09/05/2022 à 21:34, Harald Anlauf a écrit :
Hi Mikael,
Am 09.05.22 um 20:24 schrieb Mikael Morin:
The fix itself looks good. Regarding the test, I don’t understand the
problem. Can’t there be multiple subroutines, each having one (or more)
problematic statement(s)?
that's why I tried but
Remove the limit and solve https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940.
I have tested the patch on `x86_64-w64-mingw32` with MSVCRT, by pre-compiling a header of many
standard and boost headers to generate a 313-MiB-large .gch file and using it to compile a simple
'hello world' program,
On 2022/5/7 12:40 AM, Tobias Burnus wrote:
Can please also handle the new clause in Fortran's dump-parse-tree.cc?
I did see some split handling in C, but not in Fortran; do you also need
to up update gfc_split_omp_clauses in Fortran's trans-openmp.cc?
Done.
Actually, glancing at the testcas
On Tue, May 10, 2022 at 10:10 AM HAO CHEN GUI wrote:
>
> Hi,
>This patch skips constant folding for fmin/max when either argument
> is sNaN. According to C standard,
>fmin(sNaN, sNaN）= qNaN, fmin(sNaN, NaN) = qNaN
>So signaling NaN should be tested and skipped for fmin/max in match.pd.
In modules, 'attached to global module' nearly always means 'not in
module purview'. Also the implementation treats, 'in global module &&
in module purview' as meaning 'header unit'. The ModuleKind flags
reflected that. The 'nearly always' means there are cases that the
first condition is not i
The following makes sure to have a consistent state of
flag_var_tracking_assignments with the distributed handling
in process_options and finish_options by moving everything to
finish_options which also restores diagnostics for
-g0 -fvar-tracking which was lost with previous changes.
Bootstrapped
On 5/10/22 11:55, Andreas Schwab wrote:
> The header line should probably be changed since it's no longer about
> ANSI or traditional C.
>
Sure, updated in v2.
MartinFrom 9359921cd29f9ec4f7536f49160ad54b74e0214a Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 10 May 2022 09:47:08 +0200
S
On 5/9/22 09:37, Jakub Jelinek via Gcc-patches wrote:
> On Mon, May 09, 2022 at 01:02:07PM +0530, Siddhesh Poyarekar wrote:
>> On 07/02/2022 17:37, Jakub Jelinek wrote:
>>> On Mon, Feb 07, 2022 at 05:31:58PM +0530, Siddhesh Poyarekar wrote:
Use __builtin_dynamic_object_size to get object sizes
> > Similarly in GCC itself. I've built all FEs with the patch.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >
> > Ready to be installed?
>
> OK for the middle-end parts.
and OK for the Ada parts.
On 5/10/22 11:30, Richard Sandiford wrote:
Richard Sandiford writes:
The patch changes the scalar handling in aapcs_vfp_sub_candidate,
but not the complex handling. Is that deliberate?
TIL: we don't support complex decimal floats. So never mind that :-)
Indeed. Sorry, maybe I should ha
On Tue, May 10, 2022 at 11:38 AM Martin Liška wrote:
>
> Similarly in GCC itself. I've built all FEs with the patch.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK for the middle-end parts.
Richard.
> Thanks,
> Martin
>
> gcc/ada/ChangeL
On Tue, 10 May 2022, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs (and only without -g), because we don't replace
> one VEC_COND_EXPR with .VCOND* call.
> We don't do that because gimple_expand_vec_set_expr adds some stmts before
> *gsi and then uses gsi_remove to remove it. gsi_re
The header line should probably be changed since it's no longer about
ANSI or traditional C.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
When code was moved from process_options to finish_options it
was not properly adjusted to look at and alter the opts set
passed to the function but continued to modify the global options
set. The following rectifies this and makes sure the same
mistake isn't repeated by poisoning global_options{,
Christophe Lyon via Gcc-patches writes:
> This patch series enables support of DFP on AArch64, using the BID
> format (Binary Integer Decimal). There is no HW support for DFP on
> AArch64, and we made a choice similar to x86: BID format using
> libgcc's libbid for software emulation.
>
> This wor
Richard Sandiford writes:
> The patch changes the scalar handling in aapcs_vfp_sub_candidate,
> but not the complex handling. Is that deliberate?
TIL: we don't support complex decimal floats. So never mind that :-)
Richard
Hi,
To set a constant to a reg, one way is building the constant through
instructions, like lis/ori/sldi... Another way is loading it from
the constant pool through instruction 'ld'(or 'pld' for P10).
Loading a constant may need 2 instructions (or just 'pld' on P10),
and according to testing, if
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.
>
> dfp-saves-aarch6
Christophe Lyon via Gcc-patches writes:
> @@ -8464,10 +8464,18 @@ aarch64_gen_storewb_pair (machine_mode mode, rtx
> base, rtx reg, rtx reg2,
>return gen_storewb_pairdf_di (base, base, reg, reg2,
> GEN_INT (-adjustment),
>
gcov_info::n_functions type is initialized by generated
code in build_info_type:
/* n_functions */
field = build_decl (BUILTINS_LOCATION, FIELD_DECL, NULL_TREE,
get_gcov_unsigned_t ());
It uses gcov_unsigned_t, but the struct definition in libgcov.h uses
unsigned type. That br
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
@Alan: Are you fine with the change from binutils/gdb perspective?
Thanks,
Martin
include/ChangeLog:
* ansidecl.h (PTR): Remove.
(const): Likewise.
(volatile): Likewise.
(signed): Likewise.
--
Similarly in GCC itself. I've built all FEs with the patch.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ada/ChangeLog:
* gcc-interface/decl.cc (compare_field_bitpos): Use void *
instead PTR.
* gcc-inter
Hi.
As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR).
Let's removed its usafe in libiberty.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
include/ChangeLog:
* hashtab.h (HTAB_EMPTY_ENTRY): Use void
On 5/9/22 14:26, Richard Biener wrote:
> On Mon, May 9, 2022 at 2:16 PM Martin Liška wrote:
>>
>> On 5/9/22 13:58, Richard Biener wrote:
>>> The patch would have been a lot smaller if you kept it Joined only?
>>
>> Yes, but the langspec rules append a space for some reason:
>>
>> $ ./xgcc -B. /tmp
The RA_SIGN_STATE dwarf pseudo-register is normally only set using the
DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which
toggles the return address signedness state (the default state is 0).
(It may be set by remember/restore_state CFI too, those save/restore
the state of all r
Hi!
The following testcase ICEs (and only without -g), because we don't replace
one VEC_COND_EXPR with .VCOND* call.
We don't do that because gimple_expand_vec_set_expr adds some stmts before
*gsi and then uses gsi_remove to remove it. gsi_remove moves the iterator
to the next stmt and in the cal
We failed to call Adjust_Condition for the condition expression of an
if_expression, so non-standard booleans were expanded like standard
booleans, disregarding representation clauses. Fixed.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch4.adb (Expand_N_If_Expression
This patch fixes an issue in the compiler whereby a use_type_clause
incorrectly gets flagged as ineffective when the use of it comes after a
generic package instantiation where the installation of private use
clauses are required and one such clause references the same type.
Tested on x86_64-pc-li
Validity checking of enumerations with nonstandard representation
starts by checking the value range, then calling _rep_to_pos to verify
that the value itself is valid. The value range check is thus
redundant and inefficient: the _rep_to_pos call is normally inlined
when optimizing for speed and th
We have two variants of Earlier_In_Extended_Unit that take either
Node_Id or Source_Ptr values. The caller can simply use another variant
and not explicitly convert parameters.
Code cleanup; semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_warn.a
This patch improves the generated code for nonstandard boolean types.
One of the improvements extends the code that avoids converting back
to the nonstandard boolean type an expression computed as standard
boolean, when it will be converted to a(nother) nonstandard boolean
type.
The other improve
Both Source_Ptr and Int are integer types (and even happen to have equal
ranges). Their values can be calculated without converting
back-and-forth, e.g.:
Int (Loc1) - Int (Loc2)
can be written simply as:
Int (Loc1 - Loc2)
Code cleanup related to handling of references to unset objects.
Offe
Replace comparisons of Original_Node with semantically equivalent but
high-level calls to Is_Rewrite_Substitution. Offending occurrences found
with:
$ grep -n "Original_Node (\([A-Za-z_]\+\)) /\?= \1" *.adb
Code cleanup only; semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on
Replace equality and inequality operators with calls to No and Present.
Offending occurrences found with:
$ grep -n " /\?= No_Elist" *.adb
Code cleanup only; semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch11.adb, exp_ch5.adb, exp_prag.adb, g
Add a standard prevention against climbing the entire compilation unit.
Cleanup only; behaviour of the compiler is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_warn.adb (Within_Postcondition): Guard against search
going too far.diff --git a/gcc/ada
Code cleanup; behaviour is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_warn.adb (Check_Unset_Reference): The early test was only
saving time of calls to Original_Node, Comes_From_Source and
Nkind, which are all quick and cheap.diff --git a
Cleanup related to static detection of references to uninitialized
variables. Semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_ch5.adb (Check_Unreachable_Code): Remove inner declare
block; refill code and comments.diff --git a/gcc/ada/sem_
When matching formal parameters from spec and body it is cleaner and
more efficient to iterate with First_Formal/Next_Formal and not with
First_Entity/Next_Entity. The previous iteration could unintentionally
pick entities from within the subprogram body, e.g. objects declared
within the subprogram
Detection of references to unset (uninitialized) objects requires calls
to Check_Unset_Reference on every subexpression of a composite statement
and expression. For declare and qualified expressions this was done only
when they occurred within another composite statement/expression.
Tested on x86_
1 - 100 of 114 matches
Mail list logo
