The stmt comparison function for GIMPLE_ASSIGNs for tail merging
still looks like it deals with pre-tuples IL. The following
attempts to fix this, not only comparing the first operand (sic!)
of stmts but all of them plus also compare the operation code.
Bootstrapped and tested on
Hi,
original scale_loop_profile was implemented to only handle very simple loops
produced by vectorizer at that time (basically loops with only one exit and no
subloops). It also has not been updated to new profile-count API very carefully.
Since I want to use it from loop peeling and unlooping, I
On Wed, 5 Jul 2023 at 19:07, Kyrylo Tkachov wrote:
> Hi Christophe,
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Monday, June 26, 2023 4:03 PM
> > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> > Richard Sandiford
> > Cc: Christophe Lyon
> > Subject: [PATCH] arm: Fix
+; False dependency happens on destination register which is not really
+; used when moving all ones to vector register
+(define_split
+ [(set (match_operand:VMOVE 0 "register_operand")
+ (match_operand:VMOVE 1 "int_float_vector_all_ones_operand"))]
+ "TARGET_AVX512F && reload_completed
+
On 7/6/23 06:44, Richard Biener via Gcc-patches wrote:
On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
wrote:
Hi,
If a loop is unrolled by n times during vectoriation, two steps are used to
calculate the induction variable:
- The small step for the unrolled ith-copy: vec_1 =
gcc/ChangeLog:
* doc/extend.texi (ARC Built-in Functions): Update documentation
with missing builtins.
---
gcc/doc/extend.texi | 55 +
1 file changed, 55 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index
Hi Jason,
On 11/05/2023 16:25, Jason Merrill wrote:
> On 5/9/23 08:07, Alex Coplan wrote:
> > This patch implements clang's __has_feature and __has_extension in GCC.
>
> Thanks!
Thanks a lot for the review, I posted a v2 patch incorporating your
feedback here:
On Thu, Jul 6, 2023 at 3:48 PM Roger Sayle wrote:
>
> > On Thu, Jul 6, 2023 at 2:04 PM Roger Sayle
> > wrote:
> > >
> > >
> > > Passing 128-bit integer (TImode) parameters on x86_64 can sometimes
> > > result in surprising code. Consider the example below (from PR 43644):
> > >
> > > __uint128
Hi Pan,
thanks, I think that works for me as I'm expecting these
parts to change a bit anyway in the near future.
There is no functional change to the last revision that
Kito already OK'ed so I think you can go ahead.
Regards
Robin
GCC maintainers:
Ver 4. Fixed a few typos. Redid the tests to create separate run and
compile tests.
Ver 3. Added __attribute__ ((noipa)) to the test files. Changed some
of the scan-assembler-times checks to cover multiple similar
instructions. Change the function check macro to a macro to
Pushed to trunk. Backports to 11, 12 and 13 will follow.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/110574
* doc/xml/manual/configure.xml: Describe stdio_pure argument to
--enable-cstdio.
* doc/html/manual/configure.html: Regenerate.
---
This patch allows 'declare mapper' mappers to be used on 'omp target
data', 'omp target enter data' and 'omp target exit data' directives.
For each of these, only explicit mappings are supported, unlike for
'omp target' directives where implicit uses of variables inside an
offload region might
On Thu, Jul 6, 2023 at 2:04 PM Roger Sayle wrote:
>
>
> Passing 128-bit integer (TImode) parameters on x86_64 can sometimes
> result in surprising code. Consider the example below (from PR 43644):
>
> __uint128 foo(__uint128 x, unsigned long long y) {
> return x+y;
> }
>
> which currently
On Wed, Jul 5, 2023 at 3:42 PM Drew Ross via Gcc-patches
wrote:
>
> Adds a simplification for (~X | Y) ^ X to be folded into ~(X & Y).
> Tested successfully on x86_64 and x86 targets.
>
> PR middle-end/109986
>
> gcc/ChangeLog:
>
> * match.pd ((~X | Y) ^ X ->
> On Thu, Jul 6, 2023 at 2:04 PM Roger Sayle
> wrote:
> >
> >
> > Passing 128-bit integer (TImode) parameters on x86_64 can sometimes
> > result in surprising code. Consider the example below (from PR 43644):
> >
> > __uint128 foo(__uint128 x, unsigned long long y) {
> > return x+y;
> > }
> >
As per David's suggestion.
- Improved leading comment of "is_placement_new_p"
- "kf_operator_new::matches_call_types_p" now checks that arg 0 is of
integral type and that arg 1, if any, is of pointer type.
- Changed ambiguous "int" to "int8_t" and "int64_t" in placement-new-size.C
to trigger a
Hi!
On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> while generating vector pairs of load & store instruction, the src address
> was treated as an altivec type and that type of address is invalid for
If a bit-field is signed and it's wider than the output type, we must
ensure the extracted result sign-extended. But this was not handled
correctly.
For example:
int x : 8;
long y : 55;
bool z : 1;
The vectorized extraction of y was:
vect__ifc__49.29_110 =
MEM [(struct
Hi,
this patch applies some TLC to update_bb_profile_for_threading. The function
resales
probabilities by:
FOR_EACH_EDGE (c, ei, bb->succs)
c->probability /= prob;
which is correct but in case prob is 0 (took all execution counts to the newly
constructed path), this leads to
On 7/6/23 00:48, Christoph Müllner wrote:
Thanks for this!
Of course I was "lucky" and ran into the issue that the patterns did not match,
because of unexpected MULT insns where ASHIFTs were expected.
But after reading enough of combiner.cc I understood that this is on purpose
(for
Hi Iain,
On 20/06/2023 15:08, Iain Sandoe wrote:
> Hi Alex
>
> again, thanks for working on this and for fixing the SDK blocker.
>
> > On 20 Jun 2023, at 13:30, Alex Coplan wrote:
> >
>
> > The patch can now survive bootstrap on Darwin (it looks like we'll need
> > to adjust some
No, vld/vst can't guaranteed to be atomic in this condition. Seems we
can't implement this on LoongArch for now.
On 2023/7/5 20:57, Xi Ruoyao wrote:
A question: is vld/vst guaranteed to be atomic if the accessed address
is aligned? If true we can use them to implement lock-free 128-bit
atomic
Hi Alex,
> On 6 Jul 2023, at 15:01, Alex Coplan wrote:
>
> On 20/06/2023 15:08, Iain Sandoe wrote:
>> again, thanks for working on this and for fixing the SDK blocker.
>>
>>> On 20 Jun 2023, at 13:30, Alex Coplan wrote:
>>>
>>
>>> The patch can now survive bootstrap on Darwin (it looks
Kewen:
On Tue, 2023-07-04 at 10:49 +0800, Kewen.Lin wrote:
>
> >
> > The tests are broken up into a seriers of files for related
> > tests. The
>
> s/seriers/series/
Fixed
>
> > new tests are runnable tests to verify the builtin argument types
> > and the
> > functional correctness of
On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
wrote:
>
> Hi,
>
> If a loop is unrolled by n times during vectoriation, two steps are used to
> calculate the induction variable:
> - The small step for the unrolled ith-copy: vec_1 = vec_iv + (VF/n * Step)
> - The large step for the
Hi,
this patch makes loop-ch and loop unrolling to fix profile in case the loop is
known to not iterate at all (or iterate few times) while profile claims it
iterates more. While this is kind of symptomatic fix, it is best we can do
incase profile was originally esitmated incorrectly.
In the
Hi Christophe,
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, July 6, 2023 4:21 PM
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
>
> Subject: Re: [PATCH] arm: Fix MVE intrinsics support with LTO (PR
> target/110268)
>
>
>
> On Wed, 5 Jul 2023
On Thu, Jul 06, 2023 at 02:48:19PM -0500, Peter Bergner wrote:
> On 7/6/23 12:33 PM, Segher Boessenkool wrote:
> > On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
> >> --- a/gcc/config/rs6000/rs6000.cc
> >> +++ b/gcc/config/rs6000/rs6000.cc
> >> @@ -9894,6 +9894,8 @@
Stepping down as maintainer for ARC and Epiphany
* MAINTAINERS (CPU Port Maintainers): Remove myself as ARC end
epiphany maintainer.
(Write After Approval): Add myself.commit b3f20dd75e9255fc9d56d4f020972469dd671a3a
Author: Joern Rennecke
Date: Fri Jul 7 01:02:28 2023
Hi Jeff,
Thanks for your help.
Actually I have write access as I was added to the "contributor list". Anyway,
that's very kind of you to help committing the patch.
Thanks,
-Hao
From: Jeff Law
Sent: Friday, July 7, 2023 0:06
To: Richard Biener; Hao Liu
On 7/6/23 5:54 PM, Peter Bergner wrote:
> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
>> +++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_2.c
>> @@ -0,0 +1,153 @@
>> +/* { dg-do run { target { powerpc*-*-* } } } */
>
> powerpc*-*-* is the default for this test directory, so
Hi, Kees,
I have updated my V1 patch with the following changes:
A. changed the name to "counted_by"
B. changed the argument from a string to an identifier
C. updated the documentation and testing cases accordingly.
And then used this new gcc to test
Am Donnerstag, dem 06.07.2023 um 18:56 + schrieb Qing Zhao:
> Hi, Kees,
>
> I have updated my V1 patch with the following changes:
> A. changed the name to "counted_by"
> B. changed the argument from a string to an identifier
> C. updated the documentation and testing cases accordingly.
>
>
On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
> rs6000, __builtin_set_fpscr_rn add retrun value
s/retrun/return/
Maybe better written as:
rs6000: Add return value to __builtin_set_fpscr_rn
> Change the return value from void to double. The return value consists of
> the FPSCR fields
Hi!
On Mon, 2023-06-19 16:29:53 +0800, Jie Mei wrote:
> There are shortened bitwise instructions in the mips16e2 ASE,
> for instance, ANDI, ORI/XORI, EXT, INS etc. .
>
> This patch adds these instrutions with corresponding tests.
[...]
Starting with this patch, I see some new warning:
[all
Hi!
On 2014-09-01T21:56:28-0400, tsaund...@mozilla.com wrote:
> [...] this part [...]
... became commit b086d5308de0d25444243f482f2f3d1dfd3a9a62
(Subversion r214834), which added GGC support to 'hash_map', 'hash_set',
and converted to those a number of 'htab' instances.
It doesn't really
On 7/6/23 12:33 PM, Segher Boessenkool wrote:
> On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -9894,6 +9894,8 @@ rs6000_legitimate_address_p (machine_mode mode, rtx x,
>> bool reg_ok_strict)
>>
>>
Similarly to checks for vectors of 32 bits and 64 bits being supported
add one for vectors of 128 bits.
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_vect128): New
procedure.
---
gcc/testsuite/lib/target-supports.exp |6 ++
1 file changed, 6
Hi,
In the course of verifying an out-of-tree RISC-V target that has a vendor
extension providing hardware support for vector operations on pairs of
single floating-point values (similar to MIPS paired-single or Power SPE
vector types) I have come across a couple of tests that fail just
I get the following warning which prevents gcc from bootstrapping due to
-Werror:
/home/meissner/fsf-src/work124-sfsplat/gcc/config/rs6000/rs6000-p10sfopt.cc: In
function ‘void {anonymous}::process_chain_from_load(gimple*)’:
The pr97428.c test assumes support for vectors of doubles, but some
targets only support vectors of floats, causing this test to fail with
such targets. Limit this test to targets that support vectors of
doubles then.
gcc/testsuite/
* gcc.dg/vect/pr97428.c: Limit to
The bb-slp-pr95839.c test assumes quad-single float vector support, but
some targets only support pairs of floats, causing this test to fail
with such targets. Limit this test to targets that support at least
128-bit vectors then, and add a complementing test that can be run with
targets that
Committed, thanks Robin and Kito.
Pan
-Original Message-
From: Robin Dapp
Sent: Thursday, July 6, 2023 11:30 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; juzhe.zh...@rivai.ai; jeffreya...@gmail.com; Wang,
Yanzhang ; kito.ch...@gmail.com; Robin Dapp
Subject: Re:
Richard Biener via Gcc-patches writes:
> On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> If a loop is unrolled by n times during vectoriation, two steps are used to
>> calculate the induction variable:
>> - The small step for the unrolled ith-copy: vec_1 =
On 6/28/23 3:07 AM, Kewen.Lin wrote:
> I think the reason why we need to check common_deferred_options is at this
> time
> we can't distinguish the fixed_regs[2] is from the initialization or command
> line
> user explicit specification. But could we just update the FIXED_REGISTERS
> without
>
Hi Carl,
on 2023/7/6 23:33, Carl Love wrote:
> GCC maintainers:
>
> Ver 4. Fixed a few typos. Redid the tests to create separate run and
> compile tests.
Thanks! This new version looks good, excepting that we need vsx_hw
for run and two nits, see below.
>
> Ver 3. Added __attribute__
On Thu, Jul 06, 2023 at 03:00:28PM +0200, Richard Biener via Gcc-patches wrote:
> > + (if (types_match (type, @1))
> > + (bit_not (bit_and @1 (convert @0)))
> > + (if (types_match (type, @0))
> > +(bit_not (bit_and (convert @1) @0))
> > +(convert (bit_not (bit_and @0 (convert
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch is adding cond_len_* operations pattern for target support loop
control with length.
These patterns will be used in these following case:
1. Integer division:
void
f (int32_t *restrict a, int32_t *restrict b, int32_t *restrict c, int
On Thu, 6 Jul 2023, Jan Hubicka wrote:
> Hi,
> original scale_loop_profile was implemented to only handle very simple loops
> produced by vectorizer at that time (basically loops with only one exit and no
> subloops). It also has not been updated to new profile-count API very
> carefully.
>
Hi Carl,
Some more minor comments are inline below on top of Peter's insightful
review comments.
on 2023/7/1 08:58, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 2, Went back thru the requirements and emails. Not sure where I
> came up with the requirement for an overloaded version with
> Please split the above pattern into two, one emitting UNSPEC_IEEE_MAX
> and the other emitting UNSPEC_IEEE_MIN.
Splitted.
> The test involves blendv instruction, which is SSE4.1, so it is
> pointless to test it without -msse4.1. Please add -msse4.1 instead of
> -march=x86_64 and use
> Am 06.07.2023 um 19:50 schrieb Richard Sandiford :
>
> Richard Biener via Gcc-patches writes:
>>> On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
>>> wrote:
>>>
>>> Hi,
>>>
>>> If a loop is unrolled by n times during vectoriation, two steps are used to
>>> calculate the
on 2023/7/7 07:00, Peter Bergner wrote:
> On 7/6/23 5:54 PM, Peter Bergner wrote:
>> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
>>> +++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_2.c
>>> @@ -0,0 +1,153 @@
>>> +/* { dg-do run { target { powerpc*-*-* } } } */
>>
>>
On Wed, Jul 5, 2023 at 12:21 PM Thomas Schwinge wrote:
>
> Hi!
>
> On 2012-08-10T11:06:46-0400, Diego Novillo wrote:
> > * gengtype-lex.l (USER_GTY): Add pattern for "user".
> > * gengtype-parse.c (option): Handle USER_GTY.
> > (opts_have): New.
> > (type):
On Wed, Jul 5, 2023 at 6:25 PM Thomas Schwinge wrote:
>
> Hi!
>
> My original motivation for the following exercise what that, for example,
> for: 'const unsigned char * GTY((atomic)) mode_table', we currently run
> into 'const' mismatches, 'error: invalid conversion':
>
> [...]
>
Hi,
This is a follow-up patch for
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623525.html
that updates document about x86 inlining rules.
Ok for trunk?
gcc/ChangeLog:
* doc/extend.texi: Move x86 inlining rule to a new subsubsection
and add description for inling of
On Thu, Jul 6, 2023 at 3:20 AM liuhongt wrote:
>
> We have ix86_expand_sse_fp_minmax to detect min/max sematics, but
> it requires rtx_equal_p for cmp_op0/cmp_op1 and if_true/if_false, for
> the testcase in the PR, there's an extra move from cmp_op0 to if_true,
> and it failed
On Wed, Jul 5, 2023 at 11:15 PM Eugene Rozenfeld
wrote:
>
> There is no warning and perf /uk succeeds when kptr_restrict is set to 1 and
> perf_event_paranoid set to 2. However, create_gcov may fail since it won't be
> able to understand kernel addresses and it requires at least 95% of events
On Wed, Jul 5, 2023 at 6:13 PM Thomas Schwinge wrote:
>
> Hi!
>
> On 2023-07-05T10:16:09+0200, I wrote:
> > On 2014-11-23T23:11:36-0500, tsaund...@mozilla.com wrote:
> >> gcc/
> >>
> >> * plugin.c, plugin.def, ggc.h, ggc-common.c, gengtype.h, gengtype.c,
> >> gengtype-state.c,
On Wed, Jul 5, 2023 at 6:16 PM Thomas Schwinge wrote:
>
> Hi!
>
> OK to push the attached
> "GGC, GTY: Tighten up a few things re 'reorder' option and strings"?
OK.
>
> Grüße
> Thomas
>
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
>
On Wed, Jul 5, 2023 at 7:02 PM Andrew Pinski via Gcc-patches
wrote:
>
> So the problem is vector generic decided to do comparisons in
> signed-boolean:32
> types but the rest of the middle-end was not ready for that. Since we are
> building
> the comparison which will feed into a cond_expr
From: Ju-Zhe Zhong
Hi, Richi.
Sorry for making mistake on LEN_MASK_GATHER_LOAD/LEN_MASK_SCATTER_STORE
with SELECT_VL loop control.
Consider this following case:
#define TEST_LOOP(DATA_TYPE, BITS) \
void __attribute__ ((noinline, noclone))
On Thu, Jul 6, 2023 at 1:28 AM H.J. Lu via Gcc-patches
wrote:
>
> Don't assume that stack slots can only be accessed by stack or frame
> registers. Also check memory accesses from registers defined by
> stack or frame registers.
>
> gcc/
>
> PR target/109780
> *
Committed to trunk, and plan to back port to GCC 13 branch 1 week later :)
On Wed, Jul 5, 2023 at 10:15 PM Jeff Law wrote:
>
>
>
> On 7/5/23 02:11, Kito Cheng wrote:
> > Zfinx has provide fcsr like F, so rouding mode should use fcsr instead
> > of `soft` fenv.
> >
> > libgcc/ChangeLog:
> >
> >
Hi all,
This patch is to add initial support for Granite Rapids D for GCC.
The link of related information is listed below:
https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
Also, the patch of removing AMX-COMPLEX
From: Ju-Zhe Zhong
Hi, Richi.
Sorry for making mistake on LEN_MASK_GATHER_LOAD/LEN_MASK_SCATTER_STORE
with SELECT_VL loop control.
Consider this following case:
#define TEST_LOOP(DATA_TYPE, BITS) \
void __attribute__ ((noinline, noclone))
With the recent change to more reliably not vectorize code already
using vector types we run into FAILs of gcc.dg/vect/pr71264.c
The testcase was added for fixing an ICE and possible (re-)vectorization
of the code isn't really supported and I suspect might even go
wrong for non-bitops.
The
In this PR we face the issue that LIM speculates a load when
hoisting it out of the loop (since it knows it cannot trap).
Unfortunately this exposes undefined behavior when the load
accesses memory with the wrong dynamic type. This later
makes PRE use that representation instead of the original
On Thu, 6 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, Richi.
>
> Sorry for making mistake on LEN_MASK_GATHER_LOAD/LEN_MASK_SCATTER_STORE
> with SELECT_VL loop control.
OK.
> Consider this following case:
> #define TEST_LOOP(DATA_TYPE, BITS)
Committed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Biener via Gcc-patches
Sent: Thursday, July 6, 2023 3:09 PM
To: Ju-Zhe Zhong
Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com
Subject: Re: [PATCH V2] VECT: Fix ICE of variable stride on
> -Original Message-
> From: Mo, Zewei
> Sent: Thursday, July 6, 2023 2:37 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH] Initial Granite Rapids D Support
>
> Hi all,
>
> This patch is to add initial support for Granite Rapids D for GCC.
>
Many thanks to Hans-Peter Nilsson for reminding me that new RTX codes
need to be added to dwarf2out.cc's mem_loc_descriptor, and for doing
this for BITREVERSE. This patch does the same for the recently added
COPYSIGN. I'd been testing these on a target that doesn't use DWARF
(nvptx-none) and so
On Thu, 6 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, Richi.
>
> Sorry for making mistake on LEN_MASK_GATHER_LOAD/LEN_MASK_SCATTER_STORE
> with SELECT_VL loop control.
>
> Consider this following case:
> #define TEST_LOOP(DATA_TYPE, BITS)
On Thu, Jun 29, 2023 at 4:09 PM Jeff Law wrote:
>
>
>
> On 6/29/23 01:39, Christoph Müllner wrote:
> > On Wed, Jun 28, 2023 at 8:23 PM Jeff Law wrote:
> >>
> >>
> >>
> >> On 6/28/23 06:39, Christoph Müllner wrote:
> >>
> > +;; XTheadMemIdx overview:
> > +;; All peephole passes attempt to
Thank you so much.
I have sent V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623734.html
which is working fine for both stride = constant and variable.
Could you take a look at it?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-06 14:43
To: Ju-Zhe Zhong
CC:
On Thu, Jul 6, 2023 at 8:39 AM Hongyu Wang wrote:
>
> Hi,
>
> This is a follow-up patch for
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623525.html
> that updates document about x86 inlining rules.
>
> Ok for trunk?
>
> gcc/ChangeLog:
>
> * doc/extend.texi: Move x86 inlining
From: Viljar Indus
The limitation of resetting the FPU mode for non 80-bit
precision was not referenced from "Creating a Stand-alone
Library to be used in a non-Ada context". Reference it the same
way it is already referenced from "Interfacing to C".
gcc/ada/
*
From: Yannick Moy
SPARK_Mode On can only be used on library-level entities.
Improve the error message here.
gcc/ada/
* errout.ads: Add explain code.
* sem_prag.adb (Check_Library_Level_Entity): Refine error message
and add explain code.
Tested on x86_64-pc-linux-gnu,
From: Steve Baird
In some cases involving a discriminated protected type with an array
component that is subject to a discriminant-dependent index constraint,
where the element type of the array requires finalization and the array
type has not yet been frozen at the point of the declaration of
From: Viljar Indus
Find_Optional_Prim_Op can crash when the Underlying_Type is Empty.
This can happen when you are dealing with a structure type with a
private part that does not have its Full_View set yet.
gcc/ada/
* exp_util.adb (Find_Optional_Prim_Op): Stop deriving primitive
From: Viljar Indus
gcc/ada/
* sem_util.adb (Is_Fully_Initialized_Type): Avoid recalculating
the underlying type twice.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/sem_util.adb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Claire Dross
The aim of this refactoring is to avoid unnecessary dependencies
between Image and Value units even though they share the same
specification functions. These functions are grouped inside ghost
packages which are then withed by Image and Value units.
gcc/ada/
*
From: Viljar Indus
Gigi assumes that the value of range expressions is an integer literal.
Force evaluation of such expressions since static non-literal expressions
are not always evaluated to a literal form by gnat.
gcc/ada/
* sem_attr.adb (analyze_attribute.check_array_type): Replace
From: Claire Dross
gcc/ada/
* gcc-interface/Make-lang.in: Add object files of specification
files.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/gcc-interface/Make-lang.in | 3 +++
1 file changed, 3 insertions(+)
diff --git
On Linux/x86_64,
2d11c99dfca3cc603dbbfafb3afc41689a68e40f is the first bad commit
commit 2d11c99dfca3cc603dbbfafb3afc41689a68e40f
Author: Jan Beulich
Date: Wed Jul 5 09:41:09 2023 +0200
x86: use VPTERNLOG also for certain andnot forms
caused
FAIL: gcc.target/i386/pr53652-1.c
On Linux/x86_64,
e007369c8b67bcabd57c4fed8cff2a6db82e78e6 is the first bad commit
commit e007369c8b67bcabd57c4fed8cff2a6db82e78e6
Author: Jan Beulich
Date: Wed Jul 5 09:49:16 2023 +0200
x86: yet more PR target/100711-like splitting
caused
FAIL: gcc.target/i386/pr100711-1.c
Passing 128-bit integer (TImode) parameters on x86_64 can sometimes
result in surprising code. Consider the example below (from PR 43644):
__uint128 foo(__uint128 x, unsigned long long y) {
return x+y;
}
which currently results in 6 consecutive movq instructions:
foo:movq%rsi, %rax
> On Wed, 28 Jun 2023, Tamar Christina wrote:
>
> > Hi All,
> >
> > expand_vector_piecewise does not support VLA expansion as it has a
> > hard assert on the type not being VLA.
> >
> > Instead of just failing to expand and so the call marked unsupported we ICE.
> > This adjust it so we don't and
The following consolidates an assert that now hits for ppc64le
with an earlier check we already do, simplifying
vect_determine_partial_vectors_and_peeling and getting rid of
its now redundant argument.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR
On Thu, 6 Jul 2023, Tamar Christina wrote:
> > On Wed, 28 Jun 2023, Tamar Christina wrote:
> >
> > > Hi All,
> > >
> > > expand_vector_piecewise does not support VLA expansion as it has a
> > > hard assert on the type not being VLA.
> > >
> > > Instead of just failing to expand and so the call
90 matches
Mail list logo
