On 10/13/22 17:56, Segher Boessenkool wrote:
h8300 fails during GCC build:
/home/segher/src/gcc/libgcc/unwind.inc: In function
'_Unwind_SjLj_RaiseException':
/home/segher/src/gcc/libgcc/unwind.inc:141:1: error: could not split insn
141 | }
| ^
(insn 69 256 327 (set (mem/f:SI
Hi,
There is a functionality as const_anchor in cse.cc. This const_anchor
supports to generate new constants through adding small gap/offsets to
existing constant. For example:
void __attribute__ ((noinline)) foo (long long *a)
{
*a++ = 0x2351847027482577LL;
*a++ = 0x2351847027482578LL;
}
The old stack stack was performed before the stack was dropped,
which would cause the detection tool to report a memory leak.
The current stack check scheme is as follows:
'-fstack-clash-protection':
1. When the frame->total_size is smaller than the guard page size,
the stack is dropped
Implement the C2x feature of storage class specifiers in compound
literals. Such storage class specifiers (static, register or
thread_local; also constexpr, but we don't yet have C2x constexpr
support implemented) can be used before the type name (not mixed with
type specifiers, unlike in
在 2022/10/13 下午7:10, Richard Biener 写道:
On Thu, Oct 13, 2022 at 10:16 AM Lulu Cheng wrote:
在 2022/10/13 下午2:44, Xi Ruoyao 写道:
On Thu, 2022-10-13 at 14:15 +0800, Levy wrote:
Hi RuoYao
It’s probably because loongarch64 doesn’t support
can_vec_perm_const_p(result_mode, op_mode, sel2, false)
Hi Richard
Thank your for your detailed explanation, I’ll patch the test case with
suggestions form LuLu.
Best
Levy
> On 13 Oct 2022, at 7:12 pm, Richard Biener wrote:
>
> On Thu, Oct 13, 2022 at 10:16 AM Lulu Cheng wrote:
>>
>>
>>> 在 2022/10/13 下午2:44, Xi Ruoyao 写道:
>>> On Thu,
On 10/13/22 17:56, Segher Boessenkool wrote:
h8300 fails during GCC build:
/home/segher/src/gcc/libgcc/unwind.inc: In function
'_Unwind_SjLj_RaiseException':
/home/segher/src/gcc/libgcc/unwind.inc:141:1: error: could not split insn
141 | }
| ^
(insn 69 256 327 (set (mem/f:SI
> On Oct 13, 2022, at 7:56 PM, Segher Boessenkool
> wrote:
>
> This small patch changes everything that checks targetm.lra_p behave as
> if it returned true.
>
> It has no effect on any primary or secondary target. It also is fine
> for nds32 and for nios2, and it works fine for microblaze
On 10/13/22 15:39, Jeff Law via Gcc-patches wrote:
On 10/11/22 17:31, Vineet Gupta wrote:
I expect that the pressure for a proper fix upstream (instead of a
backward compatible compromise) will increase over time (once people
start building big iron based on RISC-V and start hunting
This small patch changes everything that checks targetm.lra_p behave as
if it returned true.
It has no effect on any primary or secondary target. It also is fine
for nds32 and for nios2, and it works fine for microblaze (which used
old reload before), resulting in smaller code.
I have patches
On Thu, 13 Oct 2022 15:39:39 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 10/11/22 17:31, Vineet Gupta wrote:
I expect that the pressure for a proper fix upstream (instead of a
backward compatible compromise) will increase over time (once people
start building big iron based on RISC-V and
On 10/12/22 02:03, Christoph Müllner wrote:
So we have the following atomics ABIs:
I) GCC implementation
II) LLVM implementation
III) Specified ABI in the "Code Porting and Mapping Guidelines"
appendix of the RISC-V specification
And presumably we don't have any way to distinguish
On 10/11/22 18:15, Palmer Dabbelt wrote:
Sorry, I thought we'd talked about it somewhere but it must have just
been in meetings and such. Patrick was writing a similar patch set
around the same time so it probably just got tied up in that, we ended
up reducing it to just the strong CAS
> Not a fan as it could potentially hide a real issue, but I don't really
> have a better solution.
Thanks.
> I pondered suggesting "access" affect type identity, but the cases where
> that's really important are probably better handled by the "fn spec"
> attribute, leaving "access" strictly
On 10/11/22 17:31, Vineet Gupta wrote:
I expect that the pressure for a proper fix upstream (instead of a
backward compatible compromise) will increase over time (once people
start building big iron based on RISC-V and start hunting performance
bottlenecks in multithreaded workloads to
On 10/13/22 06:06, Eric Botcazou via Gcc-patches wrote:
Hi,
if you compile the attached testcase with -O2 -fno-inline -Wall, you get:
In function 'process_array3':
cc1: warning: 'process_array4' accessing 4 bytes in a region of size 3 [-
Wstringop-overflow=]
cc1: note: referencing argument 1
On Thu, Oct 13, 2022 at 03:41:16PM -0400, Jason Merrill wrote:
> On 10/13/22 12:02, Paul Iannetta wrote:
> > On Thu, Oct 13, 2022 at 11:47:42AM -0400, Jason Merrill wrote:
> > > On 10/13/22 11:23, Paul Iannetta wrote:
> > > > On Thu, Oct 13, 2022 at 11:02:24AM -0400, Jason Merrill wrote:
> > > > >
On Thu, Oct 13, 2022 at 11:35 PM Jakub Jelinek wrote:
>
> On Thu, Oct 13, 2022 at 11:11:53PM +0200, Uros Bizjak wrote:
> > > > + do_compare_rtx_and_jump (op1, op2, GET_CODE (operands[0]), 0,
> > > > +SFmode, NULL_RTX, NULL,
> > > > +as_a
On Thu, Oct 13, 2022 at 11:11:53PM +0200, Uros Bizjak wrote:
> > > + do_compare_rtx_and_jump (op1, op2, GET_CODE (operands[0]), 0,
> > > +SFmode, NULL_RTX, NULL,
> > > +as_a (operands[3]),
> > > +/* Unfortunately this isn't
On 10/13/22 16:14, Arsen Arsenović wrote:
On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
I was arguing that we don't need the new flag; there shouldn't be any
need to turn it off.
At the time, I opted to go with a more conservative route; I haven't
been around enough to have
On Thu, Oct 13, 2022 at 9:38 PM Jason Merrill wrote:
>
> On 10/13/22 12:50, Jakub Jelinek wrote:
> > Hi!
> >
> > On Wed, Oct 05, 2022 at 04:02:25PM -0400, Jason Merrill wrote:
> >>> As I wrote earlier, I think we need at least one, __builtin_nans variant
> >>> which would be used in libstdc++
>
David Malcolm writes:
> On Thu, 2022-10-13 at 11:44 +0200, Gerald Pfeifer wrote:
>> Hi Martin,
>>
>> On Thu, 13 Oct 2022, Martin Liška wrote:
>> > I think we should add how Python scripts should be formatted. I
>> > noticed
>> > that while reading the Modula-2 patchset where it follows the
On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
> I was arguing that we don't need the new flag; there shouldn't be any
> need to turn it off.
At the time, I opted to go with a more conservative route; I haven't
been around enough to have very strong opinions ;) I certainly can't
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3285-g99da523359e933.
gcc/analyzer/ChangeLog:
PR analyzer/107210
* svalue.cc (constant_svalue::maybe_fold_bits_within): Only
attempt to extract individual bits when tree_fits_uhwi_p.
On 10/13/22 12:02, Paul Iannetta wrote:
On Thu, Oct 13, 2022 at 11:47:42AM -0400, Jason Merrill wrote:
On 10/13/22 11:23, Paul Iannetta wrote:
On Thu, Oct 13, 2022 at 11:02:24AM -0400, Jason Merrill wrote:
On 10/12/22 20:52, Paul Iannetta wrote:
On Tue, Oct 11, 2022 at 09:49:43PM -0400,
On 10/13/22 12:50, Jakub Jelinek wrote:
Hi!
On Wed, Oct 05, 2022 at 04:02:25PM -0400, Jason Merrill wrote:
As I wrote earlier, I think we need at least one, __builtin_nans variant
which would be used in libstdc++
std::numeric_limits::signaling_NaN() implementation.
I think
On 10/13/22 12:40, Jakub Jelinek wrote:
On Wed, Oct 12, 2022 at 02:08:20PM -0400, Jason Merrill wrote:
In general I've tried to follow the C99 handling, C11+ relies on the
C standard saying that in case of integral conversions excess precision
can be used (see PR87390 for more details), but I
The FUNCTION_DECL we build for __dynamic_cast has an empty DECL_CONTEXT,
but trees_out::tree_node expects all FUNCTION_DECLs to have non-empty
DECL_CONTEXT thus we crash when streaming out the dynamic_cast in the
below testcase.
This patch naively fixes this by setting DECL_CONTEXT for
On Thu, Oct 13, 2022 at 08:10:47PM +0200, Tobias Burnus wrote:
> Rather obvious patch as it is a straight conversion from C.
>
> OK for mainline?
>
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
> München; Gesellschaft mit
Rather obvious patch as it is a straight conversion from C.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der
On Thu, Oct 13, 2022 at 02:36:49PM +0200, Aldy Hernandez wrote:
> +// Like real_arithmetic, but round the result to INF if the operation
> +// produced inexact results.
> +//
> +// ?? There is still one problematic case, i387. With
> +// -fexcess-precision=standard we perform most SF/DFmode
On Thursday, 13 October 2022 19:10:10 CEST Jakub Jelinek wrote:
> Don't we have such a test already elsewhere? If not, then certain
> "warn for main" part should be removed or replaced...
Whoops, missed that comment. There is actually an equivalent test that
I overlooked (noreturn-1.c), so
On 10/13/22 13:02, Arsen Arsenović wrote:
Hi,
On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
* gcc.dg/noreturn-4.c: Likewise.
I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function
for the test case? (there's nothing
On Thu, 2022-10-13 at 11:44 +0200, Gerald Pfeifer wrote:
> Hi Martin,
>
> On Thu, 13 Oct 2022, Martin Liška wrote:
> > I think we should add how Python scripts should be formatted. I
> > noticed
> > that while reading the Modula-2 patchset where it follows the C/C++
> > style
> > when it comes to
On Thu, Oct 13, 2022 at 07:03:24PM +0200, Arsen Arsenović wrote:
> @@ -1,10 +1,10 @@
> /* Check for "noreturn" warning in main. */
> /* { dg-do compile } */
> -/* { dg-options "-O2 -Wmissing-noreturn -ffreestanding" } */
> +/* { dg-options "-O2 -Wmissing-noreturn" } */
> extern void exit (int)
On Mon, 2022-10-10 at 16:21 -0400, Jason Merrill wrote:
> On 10/4/22 11:11, Ben Boeckel wrote:
> > This patch adds initial support for ISO C++'s [P1689R5][], a format
> > for
> > describing C++ module requirements and provisions based on the
> > source
> > code. This is required because compiling
Hi,
On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
> > * gcc.dg/noreturn-4.c: Likewise.
>
> I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function
for the test case? (there's nothing specific to main in this test, and
it
testsuite: Fix failure in test pr105586.c [PR107171]
The test pr105586.c fails on a big endian system when run in 32bit
mode. The failure occurs as the test case does not guard against
unsupported __int128.
2022-10-13 Surya Kumari Jangala
gcc/testsuite/
PR testsuite/107171
*
Hi!
On Wed, Oct 05, 2022 at 04:02:25PM -0400, Jason Merrill wrote:
> > As I wrote earlier, I think we need at least one, __builtin_nans variant
> > which would be used in libstdc++
> > std::numeric_limits::signaling_NaN() implementation.
> > I think
> > std::numeric_limits::infinity() can be
Hi!
The following incremental patch implements the C11 behavior (for all C++
versions) for
cond ? int : float
cond ? float : int
int cmp float
float cmp int
where int is any integral type, float any floating point type with
excess precision and cmp ==, !=, >, <, >=, <= and <=>.
On Wed, Oct 12, 2022 at 02:08:20PM -0400, Jason Merrill wrote:
> > In general I've tried to follow the C99 handling, C11+ relies on the
> > C standard saying that in case of integral conversions excess precision
> > can be used (see PR87390 for more details), but I don't see anything similar
> >
Ping.
On Mon, 2022-09-19 at 11:13 -0500, will schmidt wrote:
> [PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865]
>
> Hi,
> The _ARCH_PWR8 define is conditional on TARGET_DIRECT_MOVE,
> and can be disabled by dependent options when it should not be.
> This manifests in
On Thu, Oct 13, 2022 at 11:47:42AM -0400, Jason Merrill wrote:
> On 10/13/22 11:23, Paul Iannetta wrote:
> > On Thu, Oct 13, 2022 at 11:02:24AM -0400, Jason Merrill wrote:
> > > On 10/12/22 20:52, Paul Iannetta wrote:
> > > > On Tue, Oct 11, 2022 at 09:49:43PM -0400, Jason Merrill wrote:
> > > > >
On 10/13/22 11:23, Paul Iannetta wrote:
On Thu, Oct 13, 2022 at 11:02:24AM -0400, Jason Merrill wrote:
On 10/12/22 20:52, Paul Iannetta wrote:
On Tue, Oct 11, 2022 at 09:49:43PM -0400, Jason Merrill wrote:
It surprises that this is the only place we complain about an object with an
Here during stream in we end up having created a type variant for the enum
before we read the enum's definition, and thus the variant inherited stale
TYPE_VALUES and TYPE_MIN/MAX_VALUES, which leads to an ICE (with -g). The
stale variant got created from set_underlying_type during earlier stream
[Public]
Hi all,
PFA, the patch that enables support for the next generation AMD Zen4 CPU via
-march=znver4.
This is a basic enablement patch and as of now the costings, tunings are kept
same as znver3.
Good for trunk?
Regards,
Tejas
This provides the hooks that will register basic partial equivalencies
for casts and bitwise AND operations with the appropriate bit pattern.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed
Andrew
From d75be7e4343f049176546aa9517d570e5eb67954 Mon Sep 17 00:00:00 2001
From:
Rangers on entry cache propagation already evaluates equivalences when
calculating values. This patch also allows it to work with partial
equivalences, and if the bit sizes are compatible, make use of those
ranges as well.
It attempts to be conservative, so should be safe.
This resolves
Instead of looping over an exposed equivalence bitmap, provide iterators
to loop over equivalences, partial equivalences, or both.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed
Andrew
From aa05838b0536422256e0c477c57f1ea1d2915e92 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
This patch provide the new relation kinds as well as management of the
partial equivalency slice table.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed
Andrew
From b5563410ea613ff2b2d7c6fa1847cfcb1ff91efb Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 6 Oct 2022
This patch implements partial equivalences in the relation oracle.
They are tracked much like normal equivalences, in that they all belong
to a set. I refer to them as "slices" of an ssa-name. A little extra
info is maintained for a partial set in class pe_slice.
A slice contains the
On 10/11/22 13:40, Nathan Sidwell wrote:
On 10/11/22 11:35, Patrick Palka wrote:
IIUC the function depset::hash::add_binding_entity has an assert
verifying that if a namespace contains an exported entity, then
the namespace must have been opened in the module purview:
if
On Thu, Oct 13, 2022 at 11:02:24AM -0400, Jason Merrill wrote:
> On 10/12/22 20:52, Paul Iannetta wrote:
> > On Tue, Oct 11, 2022 at 09:49:43PM -0400, Jason Merrill wrote:
> > >
> > > It surprises that this is the only place we complain about an object with
> > > an
> > > address-space
On Thu, Oct 13, 2022 at 07:46:46AM +0200, Jakub Jelinek wrote:
> On Thu, Oct 13, 2022 at 02:52:59AM +0200, Paul Iannetta via Gcc-patches wrote:
> > + if (type != error_mark_node
> > + && !ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (type))
> > + &&
On 10/12/22 20:52, Paul Iannetta wrote:
On Tue, Oct 11, 2022 at 09:49:43PM -0400, Jason Merrill wrote:
It surprises that this is the only place we complain about an object with an
address-space qualifier. Shouldn't we also complain about e.g. automatic
variables/parameters or non-static data
On 10/13/22 10:25, Martin Liška wrote:
Hi.
I am working on the early debug info emission that would benefit from a late
use of asm_put_file. This is last blocker where C++ emits early a section
directive
in assemble_vtv_preinit_initializer. We can use a proper DECL_INITIAL for that.
Patch can
On 10/13/22 09:58, Marek Polacek wrote:
On Wed, Oct 12, 2022 at 02:23:40PM -0400, Marek Polacek wrote:
On Wed, Oct 12, 2022 at 01:12:57PM -0400, Marek Polacek wrote:
On Wed, Oct 12, 2022 at 12:47:21PM -0400, Jason Merrill wrote:
On 10/12/22 12:27, Marek Polacek wrote:
On Tue, Oct 11, 2022 at
On 10/12/22 14:23, Marek Polacek wrote:
On Wed, Oct 12, 2022 at 01:12:57PM -0400, Marek Polacek wrote:
On Wed, Oct 12, 2022 at 12:47:21PM -0400, Jason Merrill wrote:
On 10/12/22 12:27, Marek Polacek wrote:
On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote:
On 10/11/22 16:00,
On 13/10/2022 15:15, Richard Biener wrote:
On Thu, 13 Oct 2022, Andre Vieira (lists) wrote:
Hi Rainer,
Thanks for reporting, I was actually expecting these! I thought about
pre-empting them by using a positive filter on the tests for aarch64 and
x86_64 as I knew those would pass, but I
Hi.
I am working on the early debug info emission that would benefit from a late
use of asm_put_file. This is last blocker where C++ emits early a section
directive
in assemble_vtv_preinit_initializer. We can use a proper DECL_INITIAL for that.
Patch can bootstrap on x86_64-linux-gnu and
On Thu, 13 Oct 2022, Andre Vieira (lists) wrote:
> Hi Rainer,
>
> Thanks for reporting, I was actually expecting these! I thought about
> pre-empting them by using a positive filter on the tests for aarch64 and
> x86_64 as I knew those would pass, but I thought it would be better to let
> other
Martin Liška writes:
> On 10/13/22 12:03, Richard Sandiford wrote:
>> Martin Liška writes:
>>> I think we should add how Python scripts should be formatted. I noticed
>>> that while reading the Modula-2 patchset where it follows the C/C++ style
>>> when it comes to Python files.
>>>
>>> Ready to
From: yulong
This patch fix a redefinition bug.
There are have a definition about mode_t in the fd-4.c, but it duplicates the
definition in stdio.h.There are have a definition about mode_t in the fd-4.c,
but it duplicates the definition in stdio.h.
gcc/testsuite/ChangeLog:
*
On Wed, Oct 12, 2022 at 02:23:40PM -0400, Marek Polacek wrote:
> On Wed, Oct 12, 2022 at 01:12:57PM -0400, Marek Polacek wrote:
> > On Wed, Oct 12, 2022 at 12:47:21PM -0400, Jason Merrill wrote:
> > > On 10/12/22 12:27, Marek Polacek wrote:
> > > > On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason
Hi Rainer,
Thanks for reporting, I was actually expecting these! I thought about
pre-empting them by using a positive filter on the tests for aarch64 and
x86_64 as I knew those would pass, but I thought it would be better to
let other targets report failures since then you get a testsuite
It was just a comment on the code of the PR ...
Toon.
On 10/13/22 15:44, Aldy Hernandez wrote:
I'm not following. My patch doesn't affect this behavior.
What am I missing?
Aldy
On Thu, Oct 13, 2022 at 3:04 PM Toon Moene wrote:
On 10/13/22 14:36, Aldy Hernandez via Gcc-patches wrote:
I'm not following. My patch doesn't affect this behavior.
What am I missing?
Aldy
On Thu, Oct 13, 2022 at 3:04 PM Toon Moene wrote:
>
> On 10/13/22 14:36, Aldy Hernandez via Gcc-patches wrote:
>
> > PR tree-optimization/24021
>
> Ah - Verboten in Fortran:
>
> $ cat d.f
>DOUBLE
Hi Richard,
> Maybe pre-existing, but are ordered comparisons safe for the
> ZERO_EXTRACT case? If we extract the top 8 bits (say), zero extend,
> and compare with zero, the result should be >= 0, whereas TST would
> set N to the top bit.
Yes in principle zero extract should always be positive
The following makes sure to reduce a multi-vector SLP reduction
accumulator to a single vector using vector operations if
easily possible (if the number of lanes in the vector type is
a multiple of the number of scalar accumulators).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
On 10/13/22 05:53, Jakub Jelinek wrote:
On Thu, Oct 13, 2022 at 08:11:53AM +, Richard Biener wrote:
On Wed, 12 Oct 2022, Andrew MacLeod wrote:
On 10/12/22 10:39, Jakub Jelinek wrote:
On Wed, Oct 12, 2022 at 10:31:00AM -0400, Andrew MacLeod wrote:
I presume you are looking to get this
Epilogue vectorization is not set up to re-use a vectorized
accumulator consisting of more than one vector. For non-SLP
we always reduce to a single but for SLP that isn't happening.
In such case we currenlty miscompile the epilog so avoid this.
Bootstrapped and tested on
On Oct 13, 2022, Richard Biener wrote:
> On Tue, Oct 11, 2022 at 3:33 PM Alexandre Oliva wrote:
>>
>> On Oct 11, 2022, Richard Biener wrote:
>>
>> > On Tue, Oct 11, 2022 at 1:57 PM Alexandre Oliva wrote:
>> >>
>> >> On Oct 10, 2022, Richard Biener wrote:
>> >>
>> >> > As noted in the
On 10/13/22 14:36, Aldy Hernandez via Gcc-patches wrote:
PR tree-optimization/24021
Ah - Verboten in Fortran:
$ cat d.f
DOUBLE PRECISION A, X
A = 0.0
DO X = 0.1, 1.0
A = A + X
ENDDO
END
$ gfortran d.f
d.f:3:9:
3 | DO X = 0.1, 1.0
[Jakub, this is a cleaned up version of what we iterated on earlier
this summer. It contains additional smarts to propagate NAN signs on
entry. I'd like a nod before committing.]
This is the range-op entry for floating point PLUS_EXPR. It's the
most intricate range entry we have so far,
op1_op2_relation can be called for relops (bool = a < b) as well as
regular binary operators (z = a + b). This patch adds the overloaded
method for floating point results.
gcc/ChangeLog:
* range-op-float.cc (range_operator_float::op1_op2_relation): New.
(class foperator_equal):
Hi,
if you compile the attached testcase with -O2 -fno-inline -Wall, you get:
In function 'process_array3':
cc1: warning: 'process_array4' accessing 4 bytes in a region of size 3 [-
Wstringop-overflow=]
cc1: note: referencing argument 1 of type 'char[4]'
t.c:6:6: note: in a call to function
On Tue, Oct 11, 2022 at 2:43 PM Jørgen Kvalsvik
wrote:
>
> Add a test to catch regression in line counts for labels on top of
> then/else blocks. Only the 'goto ' should contribute to the line
> counter for the label, not the if.
OK.
> gcc/testsuite/ChangeLog:
>
> *
On Tue, Oct 11, 2022 at 2:43 PM Jørgen Kvalsvik
wrote:
>
> The coverage support will under some conditions decide to split edges to
> accurately report coverage. By running the test suite with/without this
> edge splitting a small diff shows up, addressed by this patch, which
> should catch
Hi Andre,
> The bitposition calculation for the bitfield lowering in loop if conversion
> was not
> taking DECL_FIELD_OFFSET into account, which meant that it would result in
> wrong bitpositions for bitfields that did not end up having representations
> starting at the beginning of the struct.
>
On Tue, Oct 11, 2022 at 3:33 PM Alexandre Oliva wrote:
>
> On Oct 11, 2022, Richard Biener wrote:
>
> > On Tue, Oct 11, 2022 at 1:57 PM Alexandre Oliva wrote:
> >>
> >> On Oct 10, 2022, Richard Biener wrote:
> >>
> >> > As noted in the Cauldron Discussion I think you should do all
> >> >
On Wed, Oct 12, 2022 at 1:01 AM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> the recent optimization implemented for complex modes in:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595865.html
> contains an oversight for big-endian platforms in the "interesting corner
> case"
On Thu, Oct 13, 2022 at 10:16 AM Lulu Cheng wrote:
>
>
> 在 2022/10/13 下午2:44, Xi Ruoyao 写道:
> > On Thu, 2022-10-13 at 14:15 +0800, Levy wrote:
> >> Hi RuoYao
> >>
> >> It’s probably because loongarch64 doesn’t support
> >> can_vec_perm_const_p(result_mode, op_mode, sel2, false)
> >>
> >> I’m not
The expression in (with { ... } is used like a statement expression
which means control flow that leaves it is not allowed. The following
explicitely diagnoses 'return' and fixes up the few cases that crept
into match.pd (oops). Any such return will prematurely end matching
the current
On Thu, Oct 13, 2022 at 5:15 AM Liwei Xu wrote:
>
> Add extra index check when merging VEC_CST, this handles the case when
> exactly op1 needs to be return.
>
> This fixes:
> FAIL: gcc.dg/tree-ssa/forwprop-19.c scan-tree-dump-not forwprop1
> "VEC_PERM_EXPR"
>
> gcc/ChangeLog:
>
>
On Thu, 13 Oct 2022, Andre Vieira (lists) wrote:
> Added some extra comments to describe what is going on there.
Just to note I was confused and DECL_FIELD_OFFSET can indeed be
different (but then are guaranteed to be constant), so the patch
looks correct.
> On 13/10/2022 09:14, Richard Biener
On 10/13/22 12:03, Richard Sandiford wrote:
> Martin Liška writes:
>> I think we should add how Python scripts should be formatted. I noticed
>> that while reading the Modula-2 patchset where it follows the C/C++ style
>> when it comes to Python files.
>>
>> Ready to be installed?
>> Thanks,
>>
Added some extra comments to describe what is going on there.
On 13/10/2022 09:14, Richard Biener wrote:
On Wed, 12 Oct 2022, Andre Vieira (lists) wrote:
Hi,
The bitposition calculation for the bitfield lowering in loop if conversion
was not
taking DECL_FIELD_OFFSET into account, which meant
> On 12 Oct 2022, at 09:57, Iain Sandoe wrote:
>> On 12 Oct 2022, at 09:12, Kewen.Lin wrote:
>
>> PR106680 shows that -m32 -mpowerpc64 is different from
>> -mpowerpc64 -m32, this is determined by the way how we
>> handle option powerpc64 in rs6000_handle_option.
>>
>> Segher pointed out
On Thu, 2022-10-13 at 16:43 +0800, Lulu Cheng wrote:
> Looks good to me!
>
> Thanks!
Pushed r13-3269.
>
> 在 2022/10/12 下午10:23, Xi Ruoyao 写道:
> > LoongArch always support clz and ctz instructions, so we can always
> > use
> > __builtin_{clz,ctz} for count_{leading,trailing}_zeros. This
> >
Martin Liška writes:
> I think we should add how Python scripts should be formatted. I noticed
> that while reading the Modula-2 patchset where it follows the C/C++ style
> when it comes to Python files.
>
> Ready to be installed?
> Thanks,
> Martin
Did you consider requiring black formatting
Hi Jeff,
on 2022/10/12 14:48, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is tried
> to store into constant pool and ICE occur. But actually, this rtx represents
> partial incomplete address and can not be put into a .rodata
On Wed, Oct 12, 2022 at 12:12:38PM -0400, Andrew MacLeod wrote:
> No, I just meant that once we finally process the complicated function, and
> decide the final range we are storing is for x_1 is say [20,30], we could
> replace the assume call site with something like
>
> int assume03_x (x) {
On Thu, Oct 13, 2022 at 08:11:53AM +, Richard Biener wrote:
> On Wed, 12 Oct 2022, Andrew MacLeod wrote:
>
> >
> > On 10/12/22 10:39, Jakub Jelinek wrote:
> > > On Wed, Oct 12, 2022 at 10:31:00AM -0400, Andrew MacLeod wrote:
> > >> I presume you are looking to get this working for this
Hi Martin,
On Thu, 13 Oct 2022, Martin Liška wrote:
> I think we should add how Python scripts should be formatted. I noticed
> that while reading the Modula-2 patchset where it follows the C/C++ style
> when it comes to Python files.
good initiative, thank you! This makes sense to me, alas I'm
I think we should add how Python scripts should be formatted. I noticed
that while reading the Modula-2 patchset where it follows the C/C++ style
when it comes to Python files.
Ready to be installed?
Thanks,
Martin
---
htdocs/codingconventions.html | 14 ++
1 file changed, 14
On 10/10/22 17:31, Gaius Mulley via Gcc-patches wrote:
>
>
Hi!
> This patch set contains the bootstrap linking tool as well as python3
> scripts to automatically generate texi libraries section of the gm2
> documentation. In the fullness of time this will be changed to emit
> sphinx.
Yep,
Looks good to me!
Thanks!
在 2022/10/12 下午10:23, Xi Ruoyao 写道:
LoongArch always support clz and ctz instructions, so we can always use
__builtin_{clz,ctz} for count_{leading,trailing}_zeros. This improves
the code of libgcc, and also benefits Glibc once we merge longlong.h
there.
Bootstrapped
在 2022/10/13 下午2:44, Xi Ruoyao 写道:
On Thu, 2022-10-13 at 14:15 +0800, Levy wrote:
Hi RuoYao
It’s probably because loongarch64 doesn’t support
can_vec_perm_const_p(result_mode, op_mode, sel2, false)
I’m not sure whether if loongarch will support it or should I just
limit the test target for
On Wed, 12 Oct 2022, Andre Vieira (lists) wrote:
> Hi,
>
> The original patch supported matching the vect_recog_bitfield_ref_pattern for
> BITFIELD_REF's where the first operand didn't have a INTEGRAL_TYPE_P type.
> That means it would also match vectors, leading to regressions in targets that
>
On Wed, 12 Oct 2022, Andre Vieira (lists) wrote:
> Hi,
>
> The bitposition calculation for the bitfield lowering in loop if conversion
> was not
> taking DECL_FIELD_OFFSET into account, which meant that it would result in
> wrong bitpositions for bitfields that did not end up having
1 - 100 of 104 matches
Mail list logo
