On 3/31/23 15:06, Patrick Palka wrote:
On Fri, 31 Mar 2023, Jason Merrill wrote:
On 3/31/23 11:55, Patrick Palka wrote:
On Fri, 31 Mar 2023, Patrick Palka wrote:
On Thu, 30 Mar 2023, Jason Merrill wrote:
On 3/30/23 14:53, Patrick Palka wrote:
On Wed, 29 Mar 2023, Jason Merrill wrote:
On
On 3/31/23 19:31, Hans-Peter Nilsson wrote:
Date: Fri, 31 Mar 2023 15:48:22 -0400
From: Andrew MacLeod via Gcc-patches
Reply-To: Andrew MacLeod
commit 55bf4f0d443e5adbacfcdbbebf4b2e0c74d1dcc8
Author: Andrew MacLeod
Date: Fri Mar 31 15:42:43 2023 -0400
Adjust testcases to not produce
> Date: Fri, 31 Mar 2023 15:48:22 -0400
> From: Andrew MacLeod via Gcc-patches
> Reply-To: Andrew MacLeod
> commit 55bf4f0d443e5adbacfcdbbebf4b2e0c74d1dcc8
> Author: Andrew MacLeod
> Date: Fri Mar 31 15:42:43 2023 -0400
>
> Adjust testcases to not produce errors..
>
> tr
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
The compiler doesn't know about the invariant that the _S_empty_rep()
object is immutable and so _M_length and _M_refcount are always zero.
This means that we get warnings about writing possibly-non-zero length
strings into buffers that can't ho
On Tue, 15 Oct 2019 at 21:20, François Dumont wrote:
>
> Here is an update to set _M_sbuf to null if the user advance too much.
>
> Note that in this case the streambuf remains un-modified which is
> different from the current implementation. I think it is another
> enhancement.
>
> I also change t
On Thu, 2023-03-30 at 10:05 +0200, Jakub Jelinek wrote:
> Hi!
>
> The gcc.dg/analyzer/pipe-glibc.c test FAILs when using recent glibc
> headers
> and succeeds with older headers.
> The important change is that
> https://sourceware.org/git/?p=glibc.git;a=commit;h=c1760eaf3b575ad174fd88b252fd16bd525
On 3/31/23 14:16, Andrew MacLeod wrote:
On 3/31/23 15:59, Jeff Law wrote:
On 3/31/23 13:48, Andrew MacLeod wrote:
should we do something like this to tweak the testcases? or does
someone have something else in mind?
Go ahead and tweak the testcase. Unless you want to revamp it per
Jak
On 3/31/23 15:59, Jeff Law wrote:
On 3/31/23 13:48, Andrew MacLeod wrote:
should we do something like this to tweak the testcases? or does
someone have something else in mind?
Go ahead and tweak the testcase. Unless you want to revamp it per
Jakub's suggestions.
not particularly :-)
On 3/31/23 13:48, Andrew MacLeod wrote:
should we do something like this to tweak the testcases? or does
someone have something else in mind?
Go ahead and tweak the testcase. Unless you want to revamp it per
Jakub's suggestions.
jeff
should we do something like this to tweak the testcases? or does
someone have something else in mind?
Richi opened a PR for the STL failure (109350)
Andrew
On 3/31/23 13:37, Jakub Jelinek wrote:
On Fri, Mar 31, 2023 at 01:02:18PM -0400, Andrew MacLeod wrote:
I guess it figures the reci
On Fri, 31 Mar 2023, Jason Merrill wrote:
> On 3/31/23 11:55, Patrick Palka wrote:
> > On Fri, 31 Mar 2023, Patrick Palka wrote:
> >
> > > On Thu, 30 Mar 2023, Jason Merrill wrote:
> > >
> > > > On 3/30/23 14:53, Patrick Palka wrote:
> > > > > On Wed, 29 Mar 2023, Jason Merrill wrote:
> > > > >
On 3/30/23 09:51, Alexandre Oliva wrote:
On Mar 30, 2023, Alexandre Oliva wrote:
If we're dropping the renaming, I suppose we could also revert Jakub's
change. I suppose this patch will take care of it, pending testing...
Regstrapped on x86_64-linux-gnu and also tested on arm-vx7r2 (with
gc
With this we have a sole 404 on all of gcc.gnu.org (at least with
documentation from trunk included). :-)
Gerald
---
longjmp is not specific to Glibc, and GCC supports lots of systems
that do not use Glibc. Plus this link has been broken in the web
version for ages without a good way to fix.
l
Kito Cheng writes:
> It's not the RISC-V part, so this requires a global maintainer there I think?
>
Someone able to look at the system.h bit? It should be trivial, there's
no uses left and it was added purely for a bug like this in the past
(see commit message).
> On Tue, Mar 14, 2023 at 8:28
On Fri, Mar 31, 2023 at 01:02:18PM -0400, Andrew MacLeod wrote:
> I guess it figures the recip is safe to put in, there will not be a divide
> by zero.
I think the problem was that 1/d was hoisted before the loop; as long as
it is guarded with the d > 0.01 or e > 0.005 condition, it is fine.
The t
On 3/31/23 11:55, Patrick Palka wrote:
On Fri, 31 Mar 2023, Patrick Palka wrote:
On Thu, 30 Mar 2023, Jason Merrill wrote:
On 3/30/23 14:53, Patrick Palka wrote:
On Wed, 29 Mar 2023, Jason Merrill wrote:
On 3/27/23 09:30, Patrick Palka wrote:
On Thu, 23 Mar 2023, Patrick Palka wrote:
r1
On 3/31/23 12:20, Jeff Law wrote:
On 3/31/23 10:12, Hans-Peter Nilsson via Gcc-patches wrote:
Attached. I also removed the bogus warning in Walloc-13.c that no
longer
happens
Add recursive GORI recompuations with a depth limit.
PR tree-optimization/109154
> On Mar 24, 2023, at 3:42 PM, Andrew Pinski wrote:
>
> On Fri, Mar 24, 2023 at 1:14 AM Fangrui Song via Gcc-patches
> wrote:
>>
>> On Wed, Mar 22, 2023 at 8:52 AM Qing Zhao via Gcc-patches
>> wrote:
>>>
>>>
>>>
On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches
wrote
On 3/22/23 04:01, Richard Biener via Gcc-patches wrote:
The following addresses quadraticness in processing debug insns
in delete_trivially_dead_insns and insn_live_p by using TREE_VISITED
on the INSN_VAR_LOCATION_DECL to indicate a later debug bind
with the same decl and no intervening real i
On 3/31/23 10:12, Hans-Peter Nilsson via Gcc-patches wrote:
Attached. I also removed the bogus warning in Walloc-13.c that no longer
happens
Add recursive GORI recompuations with a depth limit.
PR tree-optimization/109154
gcc/
* gimple-rang
> Attached. I also removed the bogus warning in Walloc-13.c that no longer
> happens
> Add recursive GORI recompuations with a depth limit.
>
> PR tree-optimization/109154
> gcc/
> * gimple-range-gori.cc (gori_compute::may_recompute_p): Add depth
> li
On Fri, 31 Mar 2023, Patrick Palka wrote:
> On Thu, 30 Mar 2023, Jason Merrill wrote:
>
> > On 3/30/23 14:53, Patrick Palka wrote:
> > > On Wed, 29 Mar 2023, Jason Merrill wrote:
> > >
> > > > On 3/27/23 09:30, Patrick Palka wrote:
> > > > > On Thu, 23 Mar 2023, Patrick Palka wrote:
> > > > >
>
Thanks for the patch and sorry for the slow reply.
Jakub Jelinek writes:
> Hi!
>
> The testcase in the PR (which unfortunately because of my lack of experience
> with SVE I'm not able to turn into a runtime testcase that verifies it)
> is miscompiled on aarch64-linux in the regname pass, because
On Thu, 30 Mar 2023, Jason Merrill wrote:
> On 3/30/23 14:53, Patrick Palka wrote:
> > On Wed, 29 Mar 2023, Jason Merrill wrote:
> >
> > > On 3/27/23 09:30, Patrick Palka wrote:
> > > > On Thu, 23 Mar 2023, Patrick Palka wrote:
> > > >
> > > > > r13-995-g733a792a2b2e16 worked around the problem
This is one more patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
The patch adds trying commutative operands exchange for recently
implemented combining secondary memory reload and original insn:
The patch was successfully bootstrapped and tested on x86_64.
commit 378d19cfebfa2b
Segher Boessenkool writes:
> On Fri, Mar 31, 2023 at 03:06:41PM +0100, Richard Sandiford wrote:
>> This is an alternative presentation of the change that we discussed
>> a few weeks ago, and that you already tested:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613486.html
>>
>> T
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
We pass a const-reference to *this before it's constructed, and GCC
assumes that all const-references are accessed. Add the access attribute
to say it's not accessed.
libstdc++-v3/ChangeLog:
PR libstdc++/109339
* include/std/st
On Fri, 31 Mar 2023 at 12:06, Jonathan Wakely wrote:
>
> On Thu, 30 Mar 2023 at 17:01, Daniel Krügler wrote:
> >
> > Am Do., 30. März 2023 um 18:00 Uhr schrieb Jonathan Wakely via
> > Libstdc++ :
> > >
> > [..]
> > >
> > > In fact, thinking about P2641 some more, I might revert this change.
> > > I
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
As pointed out in P2641R1, we can use GCC's __builtin_constant_p to
emulate the proposed std::is_active_member. This allows us to detect
which of the union members is active during constant evaluation, so we
don't need the extra bool data member
On Fri, Mar 31, 2023 at 03:06:41PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Thu, Mar 09, 2023 at 12:10:51PM +, Richard Sandiford wrote:
> >> (and:DI (subreg:DI (reg:SI r115) 0)
> >> (const_int 63))
> >
> > This is more expensive already?! An "and" usuall
On 3/24/23 15:59, Jakub Jelinek via Gcc-patches wrote:
Hi!
The testcase in the PR (which unfortunately because of my lack of experience
with SVE I'm not able to turn into a runtime testcase that verifies it)
is miscompiled on aarch64-linux in the regname pass, because while the
function takes
Hi!
On Fri, Mar 24, 2023 at 10:59:36PM +0100, Jakub Jelinek via Gcc-patches wrote:
> 2023-03-24 Jakub Jelinek
>
> PR target/109254
> * builtins.cc (apply_args_size): If targetm.calls.get_raw_arg_mode
> returns VOIDmode, handle it like if the register isn't used for
> pa
On 3/29/23 06:11, Richard Biener via Gcc-patches wrote:
The following tells pointer-query to prefer a zero size when we
are querying for the size range for a write into an object we've
determined is of zero size. That avoids diagnostics about really
varying size arguments that just get a mean
Segher Boessenkool writes:
> On Thu, Mar 09, 2023 at 12:10:51PM +, Richard Sandiford wrote:
>> g:c23a9c87cc62bd177fd0d4db6ad34b34e1b9a31f uses nonzero_bits
>> information to convert sign_extends into zero_extends.
>> That change is semantically correct in itself, but for the
>> testcase in the
On 3/30/23 18:01, Hans-Peter Nilsson wrote:
On Fri, 24 Mar 2023, Peter Bergner via Gcc-patches wrote:
On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
Is there a reason why REE cannot see that our (reg:QI 4) is a param register
and thus due to our ABI, already correctly sign/zero extende
On Thu, Mar 09, 2023 at 12:10:51PM +, Richard Sandiford wrote:
> g:c23a9c87cc62bd177fd0d4db6ad34b34e1b9a31f uses nonzero_bits
> information to convert sign_extends into zero_extends.
> That change is semantically correct in itself, but for the
> testcase in the PR, it leads to a series of unfor
Segher Boessenkool writes:
> Hi!
>
> On Thu, Mar 09, 2023 at 12:09:59PM +, Richard Sandiford wrote:
>> This patch just splits some code out of make_compound_operation_int
>> into a new function called make_compound_operation_and. It is a
>> prerequisite for the fix for PR106594.
>>
>> It mig
On 3/31/23 10:16, Jakub Jelinek wrote:
Hi!
The cdce pass among other things replaces calls like sqrt with code
like
if (condition(s))
ret = .IFN_SQRT (x);
else
ret = sqrt (x);
so that in the common case when we know the argument doesn't trigger
any range/domain errors we use t
On 3/31/23 12:57, Jakub Jelinek wrote:
On Fri, Mar 31, 2023 at 12:45:10PM +0200, Jakub Jelinek via Gcc-patches wrote:
- there is a missing case (not handled in this patch) where both operands
are known to be zeros, but not singleton zeros
This patch adds those cases.
Ok for trunk
On 3/31/23 12:45, Jakub Jelinek wrote:
On Fri, Mar 31, 2023 at 09:57:54AM +0200, Jakub Jelinek via Gcc-patches wrote:
and so if maybe_isnan, they always return [0, 1]. Now, thinking about it,
this is unnecessary pessimization, for the case where the ... block
returns range_false (type) we ac
On 3/31/23 09:57, Jakub Jelinek wrote:
Hi!
When looking into PR91645, I've noticed we handle UN{LT,LE,GT,GE,EQ}_EXPR
comparisons incorrectly.
All those are unordered or ..., we correctly return [1, 1] if one or
both operands are known NANs, and correctly ask the non-UN prefixed
op to fold_ran
Hi!
On Thu, Mar 09, 2023 at 12:09:59PM +, Richard Sandiford wrote:
> This patch just splits some code out of make_compound_operation_int
> into a new function called make_compound_operation_and. It is a
> prerequisite for the fix for PR106594.
>
> It might (or might not) make sense to put mo
On Thu, 30 Mar 2023 at 17:01, Daniel Krügler wrote:
>
> Am Do., 30. März 2023 um 18:00 Uhr schrieb Jonathan Wakely via
> Libstdc++ :
> >
> [..]
> >
> > In fact, thinking about P2641 some more, I might revert this change.
> > Instead of adding an extra bool member to support constexpr, I think
> > I
On Fri, Mar 31, 2023 at 12:45:10PM +0200, Jakub Jelinek via Gcc-patches wrote:
>- there is a missing case (not handled in this patch) where both operands
> are known to be zeros, but not singleton zeros
This patch adds those cases.
Ok for trunk if it passes bootstrap/regtest?
2023-03-31
On Fri, Mar 31, 2023 at 09:57:54AM +0200, Jakub Jelinek via Gcc-patches wrote:
> and so if maybe_isnan, they always return [0, 1]. Now, thinking about it,
> this is unnecessary pessimization, for the case where the ... block
> returns range_false (type) we actually could do it also if maybe_isnan
Hi!
The cdce pass among other things replaces calls like sqrt with code
like
if (condition(s))
ret = .IFN_SQRT (x);
else
ret = sqrt (x);
so that in the common case when we know the argument doesn't trigger
any range/domain errors we use the hardware instruction and defer to
a library c
Hi!
When looking into PR91645, I've noticed we handle UN{LT,LE,GT,GE,EQ}_EXPR
comparisons incorrectly.
All those are unordered or ..., we correctly return [1, 1] if one or
both operands are known NANs, and correctly ask the non-UN prefixed
op to fold_range if neither operand may be NAN.
But for th
Michael Collison writes:
> While working on autovectorizing for the RISCV port I encountered an issue
> where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
> evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
> where GET_MODE_NUNITS is equal to one.
>
../../gcc/common/config/riscv/riscv-common.cc: In static member function
'static riscv_subset_list* riscv_subset_list::parse(const char*, location_t)':
../../gcc/common/config/riscv/riscv-common.cc:1158:48: error: unquoted keyword
'float' in format [-Werror=format-diag]
1158 | "%<-march=
On Fri, Mar 31, 2023 at 11:18 AM Martin Jambor wrote:
>
> Hi,
>
> On Fri, Mar 31 2023, Richard Biener wrote:
> > On Fri, Mar 31, 2023 at 10:46 AM Martin Jambor wrote:
> >>
> >> Hi,
> >>
> >> we are in the process of changing data structures holding information
> >> about constants passed by refer
Hi,
On Fri, Mar 31 2023, Richard Biener wrote:
> On Fri, Mar 31, 2023 at 10:46 AM Martin Jambor wrote:
>>
>> Hi,
>>
>> we are in the process of changing data structures holding information
>> about constants passed by reference and in aggregates to use unsigned
>> int offsets rather than HOST_WID
On Fri, Mar 31, 2023 at 10:46 AM Martin Jambor wrote:
>
> Hi,
>
> we are in the process of changing data structures holding information
> about constants passed by reference and in aggregates to use unsigned
> int offsets rather than HOST_WIDE_INT (which was selected simply
> because that is what
On Fri, Mar 31, 2023 at 8:59 AM liuhongt via Gcc-patches
wrote:
>
> Look through all backends which defined signbitm2.
> 1. When m is a scalar mode, the dest is SImode.
> 2. When m is a vector mode, the dest mode is the vector integer
> mode has the same size and elements number as m.
>
> Ok for t
Hi,
we are in the process of changing data structures holding information
about constants passed by reference and in aggregates to use unsigned
int offsets rather than HOST_WIDE_INT (which was selected simply
because that is what fell out of get_ref_base_and_extent at that time)
in order to conser
gcc/ChangeLog:
PR target/109328
* config/riscv/t-riscv: Add missing dependencies.
Co-authored-by: Andrew Pinski
---
gcc/config/riscv/t-riscv | 43
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/gcc/config/riscv/t-riscv b/
On Tue, 28 Mar 2023, Richard Biener wrote:
> When adjusting calls to reflect instrumentation we failed to handle
> calls to aliases since they appear to have no body. Instead resort
> to symtab node availability. The patch also avoids touching
> internal function calls in a more obvious way (bui
56 matches
Mail list logo
