On Jun 2, 2022, Richard Biener wrote:
>> + if (is_a (USE_STMT (use_p)))
> I think you also want to skip debug stmts here?
Indeed, thanks!
(live by the sword, die by the sword ;-)
>> + if (dump_file)
> && (dump_flags & TDF_DETAILS) please
ack
>> + if (dump_file)
> li
Two non-portable shell constructs have been long present in libcody's
build rule for revision.stamp: $() instead of ``, and += to append to
a shell variable. The former seems to work even when bash is
operating as /bin/sh, but += doesn't, and it ends up trying to run
revision+=M as a command nam
On Jun 1, 2022, Hans-Peter Nilsson wrote:
> On Fri, 20 May 2022, Alexandre Oliva via Gcc-patches wrote:
>>
>> This patch introduces -multiflags, short for multilib TFLAGS, as an
>> option that does nothing by default, but that can be added to TFLAGS
>> and mapped to useful options by driver sel
[I have conservatively assumed that both the loop-ch and loop-unswitch
passes, which also use the ranger, only support integers and pointers.
If the goal is to handle other types as well, irange::supports_p()
should be Value_Range::supports_type_p(), and any uses of
int_range_max should be converte
The traits struct is no longer needed.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-range.h (struct vrange_traits): Remove.
(is_a): Rewrite without vrange_traits.
(as_a): Same.
---
gcc/value-range.h | 28 +++-
1 file changed, 7 insertions(+), 21
It's cleaner to have the unsupported_range fully fleshed out, instead
of trapping on every operation. It can also serve as the basis for
the default vrange methods that frange and prange will inherit.
This patch implements most methods, including union and intersect, to
handle an UNDEFINED and a
This fixes a couples places that were using int_range_max, but needed
a generic temporary. Found while merging the frange work.
Also, copying between range temporaries is actually useful :).
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-cache.cc (ranger_cache::range_from_dom):
Technically, PR target/91681 has already been resolved; we now recognize the
highpart multiplication at the tree-level, we no longer use the stack, and
we currently generate the same number of instructions as LLVM. However, it
is still possible to do better, the current x86_64 code to generate a
On Thu, Jun 02, 2022 at 01:46:25PM +, Richard Biener wrote:
> > Starting x86_64-linux and i686-linux bootstrap/regtest, ok for trunk if
> > it passes them?
>
> OK.
Testing found one special case that wasn't handled correctly in the patch,
when @1 is -1, INT_MIN / -1 during the lo computation
On Fri, Jun 3, 2022 at 11:49 AM Roger Sayle wrote:
>
>
> Technically, PR target/91681 has already been resolved; we now recognize the
> highpart multiplication at the tree-level, we no longer use the stack, and
> we currently generate the same number of instructions as LLVM. However, it
> is stil
On Fri, Jun 3, 2022 at 12:08 PM Uros Bizjak wrote:
>
> On Fri, Jun 3, 2022 at 11:49 AM Roger Sayle
> wrote:
> >
> >
> > Technically, PR target/91681 has already been resolved; we now recognize the
> > highpart multiplication at the tree-level, we no longer use the stack, and
> > we currently gen
Hi!
My PR105778 patch apparently broke the following testcase.
If the mask has the top relevant bit clear (i.e. we know we are shifting
by 0 to wordsize bits - 1) but doesn't have all the bits below it set,
we emit andsi3 before the shift sequence. When the pattern had :SI
for that operand, that
On Thu, Jun 2, 2022 at 5:11 PM Jan Beulich wrote:
>
> The length attribute ought to be "the (bounding maximum) length of an
> instruction" according to the comment next to its definition. A register
> operand encoded using the ModR/M.rm field will additionally use VEX.B
> for encoding the highest
On Fri, Jun 3, 2022 at 12:17 PM Jakub Jelinek wrote:
>
> Hi!
>
> My PR105778 patch apparently broke the following testcase.
> If the mask has the top relevant bit clear (i.e. we know we are shifting
> by 0 to wordsize bits - 1) but doesn't have all the bits below it set,
> we emit andsi3 before th
On Fri, Jun 03, 2022 at 12:23:36PM +0200, Uros Bizjak wrote:
> I think it is better to leave the operation in its natural mode and
> leave the peephole pass to do its magic, depending on the target.
So like this?
2022-06-03 Jakub Jelinek
PR target/105825
* config/i386/i386.md
On Fri, Jun 3, 2022 at 12:38 PM Jakub Jelinek wrote:
>
> On Fri, Jun 03, 2022 at 12:23:36PM +0200, Uros Bizjak wrote:
> > I think it is better to leave the operation in its natural mode and
> > leave the peephole pass to do its magic, depending on the target.
>
> So like this?
You can use ix86_ex
Simple patch. Testcases based on the C/C++ commit.
For allocate, I found an unrelated bug which prevented me from adding
the associated testcase: https://gcc.gnu.org/PR105836
Tested on x86-64 (w/o offloading).
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; A
On Fri, Jun 03, 2022 at 03:37:56PM +0200, Tobias Burnus wrote:
> Simple patch. Testcases based on the C/C++ commit.
> For allocate, I found an unrelated bug which prevented me from adding
> the associated testcase: https://gcc.gnu.org/PR105836
>
> Tested on x86-64 (w/o offloading).
> OK for mainli
On Thu, 2 Jun 2022, Jason Merrill wrote:
> On 6/2/22 15:57, Patrick Palka wrote:
> > On Thu, 2 Jun 2022, Jason Merrill wrote:
> >
> > > On 5/27/22 09:57, Patrick Palka wrote:
> > > > On Thu, 26 May 2022, Patrick Palka wrote:
> > > >
> > > > > On Thu, 26 May 2022, Jason Merrill wrote:
> > > > >
On 6/3/22 10:46, Patrick Palka wrote:
On Thu, 2 Jun 2022, Jason Merrill wrote:
On 6/2/22 15:57, Patrick Palka wrote:
On Thu, 2 Jun 2022, Jason Merrill wrote:
On 5/27/22 09:57, Patrick Palka wrote:
On Thu, 26 May 2022, Patrick Palka wrote:
On Thu, 26 May 2022, Jason Merrill wrote:
On 5/2
On Fri, May 13, 2022 at 1:17 PM Philipp Tomsich
wrote:
>
> The Zbb support has introduced ctz and clz to the backend, but some
> transformations in GCC need to know what the value of c[lt]z at zero
> is. This affects how the optab is generated and may suppress use of
> CLZ/CTZ in tree passes.
>
>
Thank you for catching this one. I'll provide a fix.
On Fri, 3 Jun 2022 at 16:56, H.J. Lu wrote:
>
> On Fri, May 13, 2022 at 1:17 PM Philipp Tomsich
> wrote:
> >
> > The Zbb support has introduced ctz and clz to the backend, but some
> > transformations in GCC need to know what the value of c[l
On Fri, 3 Jun 2022, Jason Merrill wrote:
> On 6/3/22 10:46, Patrick Palka wrote:
> > On Thu, 2 Jun 2022, Jason Merrill wrote:
> >
> > > On 6/2/22 15:57, Patrick Palka wrote:
> > > > On Thu, 2 Jun 2022, Jason Merrill wrote:
> > > >
> > > > > On 5/27/22 09:57, Patrick Palka wrote:
> > > > > > On T
On 6/3/22 11:04, Patrick Palka wrote:
On Fri, 3 Jun 2022, Jason Merrill wrote:
On 6/3/22 10:46, Patrick Palka wrote:
On Thu, 2 Jun 2022, Jason Merrill wrote:
On 6/2/22 15:57, Patrick Palka wrote:
On Thu, 2 Jun 2022, Jason Merrill wrote:
On 5/27/22 09:57, Patrick Palka wrote:
On Thu, 26 M
On Fri, Jun 03, 2022 at 11:16:26AM -0400, Jason Merrill via Gcc-patches wrote:
> On 6/3/22 11:04, Patrick Palka wrote:
> > > > @@ -4319,15 +4319,32 @@ maybe_dummy_object (tree type, tree* binfop)
> > > > if (binfop)
> > > >*binfop = binfo;
> > > >- if (current_class_ref
> > > > -
On Fri, 3 Jun 2022, Marek Polacek wrote:
> On Fri, Jun 03, 2022 at 11:16:26AM -0400, Jason Merrill via Gcc-patches wrote:
> > On 6/3/22 11:04, Patrick Palka wrote:
> > > > > @@ -4319,15 +4319,32 @@ maybe_dummy_object (tree type, tree* binfop)
> > > > > if (binfop)
> > > > >*binfop = b
Hi Richard,
Here's a revised version of my patch incorporating both your suggestions.
The algorithm now uses two worklist vectors, and pointers to them,
alternating between them on each iteration, which allows the code to
handle an arbitrary number of passes without the previous code duplication.
On Thu, Jun 02, 2022 at 04:30:19PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 02, 2022 at 03:06:52PM -0400, Michael Meissner wrote:
> > Ping patch posted on May 13th:
>
> Are you not going to apply any of Will's suggestions? They looked solid
> to me.
Sure, I will clean up the comments. How
Here, when we see the second declaration of f we match it with the first
one, copy over DECL_TEMPLATE_INFO, and then try to use it when parsing the
definition, leading to confusion.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/105761
gcc/cp/ChangeLog:
* decl.cc (duplica
On Thu, 2 Jun 2022, Patrick Palka wrote:
> On Thu, 2 Jun 2022, Jason Merrill wrote:
>
> > On 6/1/22 14:20, Patrick Palka wrote:
> > > r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent
> > > decltype operands by relaxing instantiate_non_dependent_expr to check
> > > instantia
On 6/3/22 14:13, Patrick Palka wrote:
On Thu, 2 Jun 2022, Patrick Palka wrote:
On Thu, 2 Jun 2022, Jason Merrill wrote:
On 6/1/22 14:20, Patrick Palka wrote:
r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent
decltype operands by relaxing instantiate_non_dependent_expr t
On Fri, Jun 03, 2022 at 01:44:30PM -0400, Michael Meissner wrote:
> On Thu, Jun 02, 2022 at 04:30:19PM -0500, Segher Boessenkool wrote:
> > On Thu, Jun 02, 2022 at 03:06:52PM -0400, Michael Meissner wrote:
> > > Ping patch posted on May 13th:
> >
> > Are you not going to apply any of Will's sugges
cp_parser_attributes_opt doesn't accept GNU attributes followed by
[[]] attributes and vice versa; only a sequence of attributes of the
same kind. That causes grief for code like:
struct __attribute__ ((may_alias)) alignas (2) struct S { };
or
#define EXPORT __attribute__((visibility("defau
On 6/3/22 20:05, Marek Polacek wrote:
cp_parser_attributes_opt doesn't accept GNU attributes followed by
[[]] attributes and vice versa; only a sequence of attributes of the
same kind. That causes grief for code like:
struct __attribute__ ((may_alias)) alignas (2) struct S { };
or
#defi
gccpatches https://www.google.com/search?q=gcc-patches@gcc.gnu.org
GregoryJohnCasamento
35 matches
Mail list logo
