On Wed, Mar 1, 2023 at 10:00 PM Michael Collison wrote:
>
> Okay there seems to be consensus on using constant_lower_bound (vf), but
> I don't understand how that is a replacement for "vf.is_constant ()"? In
> one case we are checking if "vf" is a constant, on the other we are
> asking for the
On Wed, 1 Mar 2023, Jason Merrill wrote:
> On 3/1/23 08:09, Jakub Jelinek wrote:
> > On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
> >> When combining -g1 with -flto we run into the DIE location annotation
> >> machinery for globals calling dwarf2out_late_global_decl but not
>
This came up in a conversation with Jan. (We already have a link a bit
earlier on that page.)
Pushed.
Gerald
---
htdocs/testing/index.html | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/htdocs/testing/index.html b/htdocs/testing/index.html
index bd6219ab..012ac287
On Wed, Mar 1, 2023 at 7:14 PM Costas Argyris via Gcc-patches
wrote:
>
> Hi
>
> It seems that the win32_spawn function in libiberty/pex-win32.c is leaking
> the cmdline buffer in 2/3 exit scenarios (it is only free'd in 1/3).The
> problem here is that the cleanup code is written 3 times, one
Thanks all for help.
I tried and validated the way Richard mentioned, it works well as expected.
Meanwhile, I updated the PR as below (I take the in-reply-to option for
send-email but looks failed).
Could you please help to review continuously?
Additionally, I would like to learn if we can land
From: Pan Li
Fix the bug of the rvv bool mode precision with the adjustment.
The bits size of vbool*_t will be adjusted to
[1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
adjusted mode precison of vbool*_t will help underlying pass to
make
Just forget about this patch, bad idea.
The key_type might have additional data not used for the comparison.
This data would not be preserved if we were inserting the already stored
equivalent key instead of the user provided.
On 22/02/23 07:08, François Dumont wrote:
This one is a
Bernhard Reutner-Fischer writes:
> libgo/runtime/go-setenv.c|6 ++
> libgo/runtime/go-unsetenv.c |3 +--
Files in the libgo directory are mirrored from upstream sources, as
described in libgo/README.gcc. Please don't change them in the gcc
repository. Thanks.
Ian
For case like belowi test.c:
1:int foo(char c)
2:{
3: return ((c >= 'A' && c <= 'Z')
4: || (c >= 'a' && c <= 'z')
5: || (c >= '0' && c <='0'));}
the generated line number is incorrect for condition c>='A' of block 2:
Thus correct the condition op0 location.
gcno diff before and
When spliting edge with self loop, the split edge should be placed just next to
the edge_in->src, otherwise it may generate different position latch bbs for
two consecutive self loops. For details, please refer to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93680#c4
Regression tested pass on
Hi Haochen,
on 2023/3/1 15:09, HAO CHEN GUI wrote:
> Hi,
> The patch escalates the failure when Hollerith constant to real conversion
> fails in native_interpret_expr. It finally reports an "Unclassifiable
> statement" error.
>
> The patch of pr95450 added a verification for
Committed as obvious. FWIW, I'm on the side that emitting
the warning when the reason is just that it's the default
layout, is bad. A discussion took place years ago when the
warning was added.
-- >8 --
For targets where the byte-wise structure element layout is
the same as for
On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran
wrote:
libgfortran/caf/single.c |6 ++
libgfortran/io/async.c |6 ++
libgfortran/io/format.c |3 +--
Trivia: I copied that ASMNAME construct from the
18-year-minus-a-month old commit of r0-66993-gc5221531453e02,
where it fixed a similar testsuite error. Committed as obvious.
-- >8 --
This fixes:
Running /x/gcc/testsuite/gcc.dg/dg.exp ...
...
FAIL: gcc.dg/attr-copy-6.c (test for excess
On Thu, Mar 02, 2023 at 01:07:32AM +0100, Bernhard Reutner-Fischer wrote:
> On Wed, 1 Mar 2023 07:39:40 -0800
> Steve Kargl via Gcc-patches wrote:
>
> > In fact, Hollerith should be hidden behind a -fallow-hollerith
> > option and added to -std=legacy.
>
> While i'd be all for that, in my mind
> Date: Thu, 2 Mar 2023 01:37:12 +0100
> From: Bernhard Reutner-Fischer
> On Thu, 2 Mar 2023 00:54:33 +0100
> Hans-Peter Nilsson wrote:
>
> > > Date: Thu, 2 Mar 2023 00:23:36 +0100
> > > From: Bernhard Reutner-Fischer
> >
> > > On Wed, 1 Mar 2023 17:02:31 +0100
> > > Hans-Peter Nilsson via
On Wed, Mar 1, 2023 at 3:52 PM Bernhard Reutner-Fischer
wrote:
>
> On Wed, 1 Mar 2023 14:59:44 -0800
> Andrew Pinski wrote:
>
> > On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran
> > wrote:
> > >
> > > Hi!
> > >
> > > Mere cosmetics.
> > >
> > > - if (foo != NULL)
> > >
On Thu, 2 Mar 2023 00:54:33 +0100
Hans-Peter Nilsson wrote:
> > Date: Thu, 2 Mar 2023 00:23:36 +0100
> > From: Bernhard Reutner-Fischer
>
> > On Wed, 1 Mar 2023 17:02:31 +0100
> > Hans-Peter Nilsson via Gcc-patches wrote:
> >
> > > > From: Hans-Peter Nilsson
> > > > Date: Wed, 1 Mar
On Wed, 1 Mar 2023 07:39:40 -0800
Steve Kargl via Gcc-patches wrote:
> In fact, Hollerith should be hidden behind a -fallow-hollerith
> option and added to -std=legacy.
While i'd be all for that, in my mind this will block off literally all
consultants and quite some scientists unless we error
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran
wrote:
> libgfortran/caf/single.c |6 ++
> libgfortran/io/async.c |6 ++
> libgfortran/io/format.c |3 +--
> libgfortran/io/transfer.c|6 ++
> libgfortran/io/unix.c
On Wed, 1 Mar 2023 10:40:15 +0100
Tobias Burnus wrote:
> Hi,
>
> Please CC fortran@gcc for Fortran patches.
> > --- a/gcc/fortran/target-memory.cc
> > +++ b/gcc/fortran/target-memory.cc
> > @@ -417,10 +417,13 @@ gfc_interpret_float (int kind, unsigned char *buffer,
> > size_t buffer_size,
> >
> Date: Thu, 2 Mar 2023 00:23:36 +0100
> From: Bernhard Reutner-Fischer
> On Wed, 1 Mar 2023 17:02:31 +0100
> Hans-Peter Nilsson via Gcc-patches wrote:
>
> > > From: Hans-Peter Nilsson
> > > Date: Wed, 1 Mar 2023 16:36:46 +0100
> >
> > > ... this is what I intend to commit later
> > >
On Wed, 1 Mar 2023 14:59:44 -0800
Andrew Pinski wrote:
> On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran
> wrote:
> >
> > Hi!
> >
> > Mere cosmetics.
> >
> > - if (foo != NULL)
> > free (foo);
> >
> > With the caveat that coccinelle ruins replacement whitespace or i'm
>
On Wed, Mar 01, 2023 at 03:25:00PM -0800, Andrew Pinski via Gcc-patches wrote:
> The problem here is after r13-4748-g2a27ae32fabf85, in some
> cases we were calling inform without a corresponding warning.
> This changes the logic such that we only cause that to happen
> if there was a warning
The problem here is after r13-4748-g2a27ae32fabf85, in some
cases we were calling inform without a corresponding warning.
This changes the logic such that we only cause that to happen
if there was a warning happened before hand.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
On Wed, 1 Mar 2023 17:02:31 +0100
Hans-Peter Nilsson via Gcc-patches wrote:
> > From: Hans-Peter Nilsson
> > Date: Wed, 1 Mar 2023 16:36:46 +0100
>
> > ... this is what I intend to commit later
> > today, just keeping the added comment as brief as
> > reasonable:
>
> Except I see the hook
On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran
wrote:
>
> Hi!
>
> Mere cosmetics.
>
> - if (foo != NULL)
> free (foo);
>
> With the caveat that coccinelle ruins replacement whitespace or i'm
> uneducated enough to be unable to _not_ run the diff through
> sed -e
On Wed, 1 Mar 2023 22:58:59 +0100
Bernhard Reutner-Fischer wrote:
> On Wed, 1 Mar 2023 22:28:56 +0100
> Bernhard Reutner-Fischer wrote:
>
> > Remarks:
> > 1) We should do this in if-conversion (?) on our own.
> >I suppose. Independently of -fdelete-null-pointer-checks
>
> and iff we can
>> Does the eventual value set by ADJUST_BYTESIZE equal the real number of
>> bytes loaded by vlm.v and stored by vstm.v (after the appropriate vsetvl)?
>> Or is the GCC size larger in some cases than the number of bytes
>> loaded and stored?
For VNx1BI,VNx2BI,VNx4BI,VNx8BI, we allocate the larger
On 2/27/23 18:51, Jakub Jelinek wrote:
On Mon, Feb 27, 2023 at 06:26:04PM -0500, Jason Merrill wrote:
The following patch instead adds a target hook which allows the backend
to temporarily tweak registered types such that emit_support_tinfos
emits whatever is needed.
Why handle these types
On Wed, Mar 01, 2023 at 04:44:12PM -0500, Jason Merrill wrote:
> On 3/1/23 16:40, Marek Polacek wrote:
> > On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:
> > > On 3/1/23 15:33, Marek Polacek wrote:
> > > > -Wmismatched-tags warns about the (harmless) struct/class mismatch.
> > > >
Previously, if the analyzer saw a call to a non-pure and non-const
built-in function that it didn't have explicit knowledge of the behavior
of, it would fall back to assuming that the builtin could have arbitrary
behavior, similar to a function defined outside of the current TU.
However, this
On Wed, 1 Mar 2023 22:28:56 +0100
Bernhard Reutner-Fischer wrote:
> Remarks:
> 1) We should do this in if-conversion (?) on our own.
>I suppose. Independently of -fdelete-null-pointer-checks
and iff we can prove that ptr was NULL when passed to free(ptr) then we
can elide the call, of
On 2/7/23 11:46, Marek Polacek wrote:
On Sun, Feb 05, 2023 at 05:25:25PM -0800, Jason Merrill wrote:
On 1/24/23 17:49, Marek Polacek wrote:
On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:
On 1/19/23 21:03, Marek Polacek wrote:
On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason
On 3/1/23 16:40, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:
On 3/1/23 15:33, Marek Polacek wrote:
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template struct A { };
class A a;
it works by adding A to the
On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:
> On 3/1/23 15:33, Marek Polacek wrote:
> > -Wmismatched-tags warns about the (harmless) struct/class mismatch.
> > For, e.g.,
> >
> >template struct A { };
> >class A a;
> >
> > it works by adding A to the class2loc hash
On 2/21/23 19:05, Patrick Palka wrote:
On Sun, 19 Feb 2023, Jason Merrill wrote:
On 2/15/23 12:11, Patrick Palka wrote:
On Wed, 15 Feb 2023, Jason Merrill wrote:
On 2/15/23 09:21, Patrick Palka wrote:
On Tue, 14 Feb 2023, Jason Merrill wrote:
On 2/13/23 09:23, Patrick Palka wrote:
[N.B.
On 3/1/23 15:33, Marek Polacek wrote:
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template struct A { };
class A a;
it works by adding A to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
Hi!
Mere cosmetics.
- if (foo != NULL)
free (foo);
With the caveat that coccinelle ruins replacement whitespace or i'm
uneducated enough to be unable to _not_ run the diff through
sed -e 's/^+\([[:space:]]*\)free(/+\1free (/'
at least. If anybody knows how to improve replacement
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/cow_string.h: Fix typo in comment.
---
libstdc++-v3/include/bits/cow_string.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/bits/cow_string.h
Tested x86_64-linux and powerpc-aix. Pushed to trunk.
-- >8 --
This is consistent with the behaviour of glibc, which assumes UTC when
/etc/localtime and TZ do not identify a valid time zone. The fallback
tzdb used when no valid tzdata exists always contains the UTC zone, so
this change means we
On 2/2/23 19:28, Marek Polacek wrote:
Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
been completed yet, but that doesn't work:
/* We can't lower this until the class is complete. */
if (!COMPLETE_TYPE_P (DECL_CONTEXT (member)))
return cst;
Okay there seems to be consensus on using constant_lower_bound (vf), but
I don't understand how that is a replacement for "vf.is_constant ()"? In
one case we are checking if "vf" is a constant, on the other we are
asking for the lower bound. For the crash in question
"constant_lower_bound (vf)
Ping.
On Thu, Feb 02, 2023 at 07:28:25PM -0500, Marek Polacek via Gcc-patches wrote:
> Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
> been completed yet, but that doesn't work:
>
> /* We can't lower this until the class is complete. */
> if
Ping.
On Tue, Feb 07, 2023 at 11:46:10AM -0500, Marek Polacek wrote:
> On Sun, Feb 05, 2023 at 05:25:25PM -0800, Jason Merrill wrote:
> > On 1/24/23 17:49, Marek Polacek wrote:
> > > On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:
> > > > On 1/19/23 21:03, Marek Polacek wrote:
> >
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template struct A { };
class A a;
it works by adding A to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add A. At the end of c_parse_file we go
On 3/1/23 08:09, Jakub Jelinek wrote:
On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_late_global_decl but not
having any early generated DIE for function scope statics.
On Wed, 1 Mar 2023 at 20:53, Vineet Gupta wrote:
>
> This showed up as dynamic icount regression in SPEC 531.deepsjeng with
> upstream
> gcc (vs. gcc 12.2). gcc was resorting to synthetic multiply using shift+add(s)
> even when multiply had clear cost benefit.
>
> |000133b8
This showed up as dynamic icount regression in SPEC 531.deepsjeng with upstream
gcc (vs. gcc 12.2). gcc was resorting to synthetic multiply using shift+add(s)
even when multiply had clear cost benefit.
|000133b8 :
| 133b8: srl a3,a1,s6
| 133bc: and a3,a3,s5
|
On Wed, 1 Mar 2023, Jason Merrill wrote:
> On 3/1/23 12:20, Patrick Palka wrote:
> > On Wed, 1 Mar 2023, Jason Merrill wrote:
> >
> > > On 3/1/23 10:32, Patrick Palka wrote:
> > > > On Mon, 27 Feb 2023, Jason Merrill wrote:
> > > >
> > > > > On 2/22/23 14:45, Patrick Palka wrote:
> > > > > >
On Sat, Jan 21, 2023 at 04:31:52PM +, i.nixman--- via Gcc-patches wrote:
> > Why?
>
> could you explain which of the nine lines are you talking about?
All the uselessly changed ones.
> > As for the rest, it would help if you could list the exact glibc commits
> > which you've ported to
> -Original Message-
> From: Andrew Carlotti
> Sent: Wednesday, March 1, 2023 4:58 PM
> To: Andrew MacLeod
> Cc: Tamar Christina ; Richard Biener
> ; Richard Sandiford ;
> Tamar Christina via Gcc-patches ; nd
> ; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong
Stack protector needs a guard value on the stack and change the stack
layout. So we need to disable it for those tests, to avoid test failure
with --enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/shrink_wrap_1.c (dg-options): Add
-fno-stack-protector.
Stack protector influence code generation and cause function body checks
fail.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr103147-10.c (dg-options): Add
-fno-stack-protector.
* g++.target/aarch64/pr103147-10.C: Likewise.
---
Hi
It seems that the win32_spawn function in libiberty/pex-win32.c is leaking
the cmdline buffer in 2/3 exit scenarios (it is only free'd in 1/3).The
problem here is that the cleanup code is written 3 times, one at each exit
scenario.
The proposed attached refactoring has the cleanup code
These tests set large code model with -mcmodel=large or target pragma for
AArch64. But if GCC is configured with --enable-default-pie, it triggers
"sorry: unimplemented: code model large with -fpic". Disable PIE to make
avoid the issue.
gcc/testsuite/ChangeLog:
PR testsuite/70150
Storing stack guarding variable need one stp instruction, breaking the
scan-assembler-not pattern in the test. Disable stack protector to
avoid a test failure with --enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr104005.c (dg-options): Add
In PIE, symbol "fixed_regs" is addressed via GOT. It will break the
scan-assembler pattern and cause test failure with --enable-default-pie.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/aarch64/fuse_adrp_add_1.c (dg-options): Add
-fno-pie.
---
The test scans for "const_int 0" in the RTL dump, but stack protector
can produce more "const_int 0". To avoid a failure with
--enable-default-ssp, disable stack protector for this.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/auto-init-7.c (dg-options): Add
If GCC is configured with --enable-default-ssp, the stack protector can
make many sve-pcs tests fail.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp (sve_flags):
Add -fno-stack-protector.
---
.../gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp |
If GCC is built with --enable-default-pie, a lot of aapcs64 tests fail
because relocation unsupported in PIE is used.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/aarch64/aapcs64/aapcs64.exp (additional_flags):
Add -fno-pie -no-pie.
---
Hi,
This patch series fixes a lot of test failures with --enable-default-pie
or --enable-default-ssp for AArch64 target. Only test files are changed
to disable PIE or SSP to satisify the expectation of the developer who
programmed the test.
Bootstrapped and regtested on aarch64-linux-gnu. Ok
On 3/1/23 12:20, Patrick Palka wrote:
On Wed, 1 Mar 2023, Jason Merrill wrote:
On 3/1/23 10:32, Patrick Palka wrote:
On Mon, 27 Feb 2023, Jason Merrill wrote:
On 2/22/23 14:45, Patrick Palka wrote:
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant
On Wed, 1 Mar 2023, Jason Merrill wrote:
> On 3/1/23 10:32, Patrick Palka wrote:
> > On Mon, 27 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/22/23 14:45, Patrick Palka wrote:
> > > > Here we're mishandling the unevaluated array new-expressions due to a
> > > > supposed non-constant array size
On Thu, Feb 23, 2023 at 11:39:51AM -0500, Andrew MacLeod via Gcc-patches wrote:
>
>
> Inheriting from operator_mult is also going to be hazardous because it also
> has an op1_range and op2_range...� you should at least define those and
> return VARYING to avoid other issues.� Same thing
This patch introduces instruction patterns for conditional min and max
operations (cond_{f|s|u}{max|min}) in the GCN machine description. It
also allows the exec register to be saved in SGPRs to avoid spilling to
memory.
Tested on GCN3 Fiji gfx803.
OK for trunk?
--
PA
From
On 3/1/23 10:32, Patrick Palka wrote:
On Mon, 27 Feb 2023, Jason Merrill wrote:
On 2/22/23 14:45, Patrick Palka wrote:
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform
> On Feb 28, 2023, at 4:59 PM, Jakub Jelinek wrote:
>
> On Tue, Feb 28, 2023 at 07:19:40PM +, Qing Zhao wrote:
>> Understood.
>> So, your patch fixed this bug, and then [0] arrays are instrumented by
>> default with this patch.
>>
>>> Well, it would complain about
>>> struct S { int a;
"Li, Pan2" writes:
> Thanks all for so much valuable and helpful materials.
>
> As I understand (Please help to correct me if any mistake.), for the VNx*BI
> (aka, 1, 2, 4, 8, 16, 32, 64),
> the precision and mode size need to be adjusted as below.
>
> Precision size [1, 2, 4, 8, 16, 32, 64]
>
> From: Hans-Peter Nilsson
> Date: Wed, 1 Mar 2023 16:36:46 +0100
> ... this is what I intend to commit later
> today, just keeping the added comment as brief as
> reasonable:
Except I see the hook for errno magic took care of
gcc.dg/analyzer/flex-without-call-summaries.c so I'll add
that to
Sorry for the typo and inconvenience.
The below
"The genmode will first get the precision, and then leverage the mode_size =
exact_div / 8 to generate"
should be:
"The genmode will first get the precision, and then leverage mode_size =
mode_precision / 8 to generate"
Pan
On Wed, Mar 01, 2023 at 10:40:15AM +0100, Tobias Burnus wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> > @@ -0,0 +1,14 @@
> > +! { dg-do compile { target powerpc*-*-* } }
> > +! { dg-options "-O2 -mabi=ibmlongdouble" }
> > +
> > +! Test to ensure that it reports an
Thanks all for so much valuable and helpful materials.
As I understand (Please help to correct me if any mistake.), for the VNx*BI
(aka, 1, 2, 4, 8, 16, 32, 64),
the precision and mode size need to be adjusted as below.
Precision size [1, 2, 4, 8, 16, 32, 64]
Mode size [1, 1, 1, 1, 2, 4, 8]
> From: David Malcolm
> Cc: gcc-patches@gcc.gnu.org
> Date: Wed, 01 Mar 2023 08:32:13 -0500
> Also, the analyzer uses region_model::set_errno in various
> known_function implementations, e.g. for functions that can succeed or
> fail, to set errno on the "failure" execution path to a new symbolic
On Mon, 27 Feb 2023, Jason Merrill wrote:
> On 2/22/23 14:45, Patrick Palka wrote:
> > Here we're mishandling the unevaluated array new-expressions due to a
> > supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
> > made us no longer perform constant evaluation of
>> So given the above I think that modeling the size as being the same
>> but with accurate precision would work. It's then only the size of the
>> padding in bytes we cannot represent with poly-int which should be fine.
>> Correct?
Yes.
>> Btw, is storing a VNx1BI and then loading a VNx2BI
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6393-g070523b9d4c6cf.
gcc/analyzer/ChangeLog:
PR analyzer/108935
* infinite-recursion.cc (contains_unknown_p): New.
(sufficiently_different_region_binding_p): New function, splitting
On Wed, 1 Mar 2023, Richard Biener wrote:
> On Wed, 1 Mar 2023, juzhe.zh...@rivai.ai wrote:
>
> > Let's me first introduce RVV load/store basics and stack allocation.
> > For scalable vector memory allocation, we allocate memory according to
> > machine vector-length.
> > To get this CPU
On Wed, 1 Mar 2023, juzhe.zh...@rivai.ai wrote:
> Let's me first introduce RVV load/store basics and stack allocation.
> For scalable vector memory allocation, we allocate memory according to
> machine vector-length.
> To get this CPU vector-length value (runtime invariant but compile time
>
Sorry for missleading typo.
>> VNx1BI: vsevl e8mf8 + vlm, loading 1/8 of poly (1,1) storage.
>> VNx2BI: vsevl e8mf8 + vlm, loading 1/4 of poly (1,1) storage.
>> VNx4BI: vsevl e8mf8 + vlm, loading 1/2 of poly (1,1) storage.
>> VNx8BI: vsevl e8mf8 + vlm, loading 1 of poly (1,1) storage.
It
Let's me first introduce RVV load/store basics and stack allocation.
For scalable vector memory allocation, we allocate memory according to machine
vector-length.
To get this CPU vector-length value (runtime invariant but compile time
unknown), we have an instruction call csrr vlenb.
For
On 01.03.23 14:03, Jakub Jelinek wrote:
On Tue, Feb 28, 2023 at 02:06:43PM +0100, Tobias Burnus wrote:
[...]
Do we use that hashing even say for ARRAY_REFs with array indexes?
Using OEP_MATCH_SIDE_EFFECTS will mean that
volatile int idx;
a.b[idx] and a.b[idx] will compare equal. On the other
On 3/1/23 09:21, Richard Biener wrote:
On Wed, Mar 1, 2023 at 9:52 AM NightStrike via Gcc-patches
wrote:
On Thu, Feb 16, 2023, 11:10 LIU Hao via Gcc-patches
wrote:
--
Best regards,
LIU Hao
Ping
OK.
Done, pushed to master branch.
On 2/28/23 18:15, Jakub Jelinek wrote:
On Wed, Feb 15, 2023 at 01:44:08PM +, Jonathan Yong via Gcc-patches wrote:
gcc/testsuite/ChangeLog:
* gcc.target/i386/harden-sls-6.c: fix warning on LLP64
targets.
Attached patch OK?
From c0572a1e95c6f569980d6b7454c8dc293f07389e
On 2/27/23 16:55, Richard Sandiford wrote:
Jonathan Yong via Gcc-patches writes:
Attached patch OK?
gcc.dg/memchr-3.c: fix for LLP64
gcc/testsuite/ChangeLog:
PR middle-end/97956
* gcc.dg/memchr-3.c (memchr): fix long to size_t in
On Wed, 2023-03-01 at 04:01 +0100, Hans-Peter Nilsson wrote:
> > From: David Malcolm
> > Date: Tue, 28 Feb 2023 21:25:34 -0500
>
> > On Wed, 2023-03-01 at 01:59 +0100, Hans-Peter Nilsson wrote:
> > > > From: David Malcolm
> > > > Date: Tue, 28 Feb 2023 14:12:47 -0500
> > >
> > > > On Tue,
On Wed, 1 Mar 2023, Richard Sandiford wrote:
> Pan Li via Gcc-patches writes:
> > I am not very familiar with the memory pattern, maybe juzhe can provide
> > more information or correct me if anything is misleading.
> >
> > The different precision try to resolve the below bugs, the second
Pan Li via Gcc-patches writes:
> I am not very familiar with the memory pattern, maybe juzhe can provide more
> information or correct me if anything is misleading.
>
> The different precision try to resolve the below bugs, the second vlm(with
> different size of load bytes compared to first
On Wed, 1 Mar 2023, Pan Li wrote:
> I am not very familiar with the memory pattern, maybe juzhe can provide more
> information or correct me if anything is misleading.
>
> The different precision try to resolve the below bugs, the second
> vlm(with different size of load bytes compared to
On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
> When combining -g1 with -flto we run into the DIE location annotation
> machinery for globals calling dwarf2out_late_global_decl but not
> having any early generated DIE for function scope statics. In
> this process we'd generate a
When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_late_global_decl but not
having any early generated DIE for function scope statics. In
this process we'd generate a limbo DIE since also the function scope
doesn't have any early
On Tue, Feb 28, 2023 at 02:06:43PM +0100, Tobias Burnus wrote:
> (This is marked as P1 regression)
>
> Since the structure handling updates, a hash is now used to find expressions
> which are identical;
> unfortunately, this mishandles 'volatile' vars as expressions involving them
> are not
I am not very familiar with the memory pattern, maybe juzhe can provide more
information or correct me if anything is misleading.
The different precision try to resolve the below bugs, the second vlm(with
different size of load bytes compared to first one)
is eliminated because vbool8 and
Hello
I don't have write access, could someone review and apply this please?
Kind regards
Jonny
Forwarded Message
Subject: [PATCHJ]: Bugzilla 88860 - Clarify online manual infelicities
Date: Mon, 26 Dec 2022 21:00:05 +
From: Jonny Grant
To: gcc-patches@gcc.gnu.org
Hello
I don't have write access, could someone review and apply this please?
Kind regards
Jonny
Forwarded Message
Subject: Bugzilla Bug 81649 [PATCH]: Clarify LeakSanitizer in documentation
Date: Mon, 26 Dec 2022 20:50:23 +
From: Jonny Grant
To: gcc-patches@gcc.gnu.org
Hello
I don't have write access, could someone review and apply this?
Kind regards
Jonny
Forwarded Message
Subject: [PATCH] update copyright year in libstdcc++ manual
Date: Fri, 30 Dec 2022 10:30:22 +
From: Jonny Grant
To: gcc-patches@gcc.gnu.org
CC: Jonny Grant
On Tue, Feb 28, 2023 at 05:18:25PM +0100, Tobias Burnus wrote:
> OpenMP/Fortran: Fix handling of optional is_device_ptr + bind(C) [PR108546]
>
> For is_device_ptr, optional checks should only be done before calling
> libgomp, afterwards they are NULL either because of absent or, by
> chance,
The following patch
libstdc++: Update Solaris baselines for GCC 13.0
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612379.html
has remained unreviewed for a week.
Thanks.
Rainer
--
-
On Wed, 1 Mar 2023, Richard Sandiford wrote:
> 盼 李 via Gcc-patches writes:
> > Just have a test with the below code, the [0x4, 0x4] test comes from
> > VNx4BI. You can notice that the mode size is unchanged.
> >
> > printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
> >
Hi!
On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Nov 16, 2022 at 10:06:17AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Thoughts on this? I guess my preference would be the BF -> SF -> TI
> > path because we won't need to waste
> > 32:
1 - 100 of 133 matches
Mail list logo
