On Wed, May 21, 2025 at 11:31:01PM +0200, Alejandro Colomar wrote:
> The preexisting ones are not just the outermost ones. The preexisting
> code was
>
> (in_sizeof
>? "sizeof"
>: (in_typeof ? "typeof" : "alignof")));
>
> The only pattern I can find
Hi Jakub,
On Wed, May 21, 2025 at 11:31:05PM +0200, Alejandro Colomar wrote:
> > > +#define c_parser_sizeof_expression(parser)
> > > \
> > > +(
> > > \
> > > + c_parser_sizeof_or_count
Hi Jakub,
On Wed, May 21, 2025 at 11:47:30PM +0200, Jakub Jelinek wrote:
> > @@ -1747,6 +1737,8 @@ static struct c_expr c_parser_binary_expression
> > (c_parser *, struct c_expr *,
> > tree);
> > static struct c_expr c_parser_cast_expr
On 5/20/25 1:56 PM, Robin Dapp wrote:
Maybe I'm missing something there. Particularly whether or not you
can know anything about frm's value after a call has returned.
Normally the answer to this kind of question is a hard no.
AFAICT the main difference to standard mode switching is that
On Wed, May 21, 2025 at 11:44:42PM +0200, Alejandro Colomar wrote:
> Does this sound good?
>
> diff --git i/gcc/c/c-parser.cc w/gcc/c/c-parser.cc
> index faa03c4903a2..733cb312341e 100644
> --- i/gcc/c/c-parser.cc
> +++ w/gcc/c/c-parser.cc
> @@ -78,16 +78,6 @@ along w
So the first special case of clearing bits from Shreya's work. We can
clear an arbitrary number of high bits by shifting left by the number of
bits to clear, then logically shifting right to put everything in place.
Similarly we can clear an arbitrary number of low bits with a right
logica
On Wed, May 21, 2025 at 3:21 PM Jeff Law wrote:
>
>
>
> On 5/5/25 3:27 PM, Andrew Pinski wrote:
> > The problem here is simplify-rtx.cc expects gen_lowpart_no_emit
> > to return NULL on failure but combine's hook was returning CLOBBER.
> > After r16-160-ge6f89d78c1a7528e93458278,
> > gcc.target/i
On 5/5/25 3:27 PM, Andrew Pinski wrote:
The problem here is simplify-rtx.cc expects gen_lowpart_no_emit
to return NULL on failure but combine's hook was returning CLOBBER.
After r16-160-ge6f89d78c1a7528e93458278, gcc.target/i386/avx512bw-pr103750-2.c
started to fail at -m32 due to this as new
On 5/21/25 4:29 PM, Andrew Pinski wrote:
On Wed, May 21, 2025 at 3:21 PM Jeff Law wrote:
On 5/5/25 3:27 PM, Andrew Pinski wrote:
The problem here is simplify-rtx.cc expects gen_lowpart_no_emit
to return NULL on failure but combine's hook was returning CLOBBER.
After r16-160-ge6f89d78c1a7
This operator is similar to sizeof but can only be applied to an array,
and returns its number of elements.
FUTURE DIRECTIONS:
- We should make it work with array parameters to functions,
and somehow magically return the number of elements of the array,
regardless of it being really a poin
It has been standardized in C2y.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_sizeof_or_countof_expression):
Add -Wpedantic diagnostic for _Countof in <= C23 mode.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-compat.c:
Test _Countof diagnostics with -Wc23-c2y-compat on
Hi!
Here's v24. Changes compared to v23 (see range-diff below):
- Use a GNU dialect in tests that use GNU extensions.
- Add comment about the syntax of _Countof.
Tests still pass:
$ grep countof ./gcc/testsuite/gcc/gcc.sum
PASS: gcc.dg/countof-compat.c (test for warnings, li
gcc/ChangeLog:
* Makefile.in (USER_H): Add .
* ginclude/stdcountof.h: Add countof macro.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-stdcountof.c: Add tests for .
Signed-off-by: Alejandro Colomar
---
gcc/Makefile.in | 1 +
gcc/ginclude/stdcount
Autoreconf -Wall complains about obsolete macros, so replace them according to
the autoconf documentation[0].
This patch doesn't fully fix all warnings because I focused on doing simple
fixes and keeping the changes to the generated files to a minimum.
Bootstrapped and retested on x86_64-linux-gn
So the next step in Shreya's work. In the prior patch we used two
shifts to clear bits at the high or low end of an object. In this patch
we use 3 shifts to clear bits on both ends.
Nothing really special here. With mvconst_internal still in the tree
it's of marginal value, though Shreya an
On 5/18/25 10:38 AM, Andrew Pinski wrote:
While working on improving forwprop and removal of
forward_propagate_into_gimple_cond/forward_propagate_into_comparison,
I came cross a case where we end up with SSA_NAME in the resulting
gimple_match_op and one statement in the sequence. This was the
On Wed, May 21, 2025 at 11:48:34AM +0200, Uros Bizjak wrote:
> Please introduce "x86_64_neg_const_int_operand" predicate that will
> allow only const_int operands, and will reject negative endbr (and
> wide DImode) const_ints. You don't need a constraint if the predicate
> allows only const_ints (t
On 21/05/2025 12:26, Christopher Bazley wrote:
Hi Joseph,
Thanks for reviewing my patch.
On 20/05/2025 18:02, Joseph Myers wrote:
On Tue, 20 May 2025, Christopher Bazley wrote:
+ if (!cleared)
+ {
+ if (complete_p.padded_non_union
+ && warn_zero_init_padding_bits >= ZER
On Wed, 21 May 2025, Alejandro Colomar wrote:
> @@ -10572,6 +10583,8 @@ c_parser_unary_expression (c_parser *parser)
> case CPP_KEYWORD:
>switch (c_parser_peek_token (parser)->keyword)
> {
> + case RID_COUNTOF:
> + return c_parser_countof_expression (parser);
> c
Hi,
this patch initializes saved_vxrm_mode to VXRM_MODE_NONE. This is a
warning (but no error) when building the compiler so better fix it.
Regtested on rv64gcv_zvl512b. Going to commit as obvious if the CI
is happy.
Regards
Robin
gcc/ChangeLog:
* config/riscv/riscv.cc (singleton_vx
Hi,
This patch adds a --param=autovec-mode=. When the param is
specified we make autovectorize_vector_modes return exactly this mode if
it is available. This helps when testing different vectorizer settings.
Regtested on rv64gcv_zvl512b.
Regards
Robin
gcc/ChangeLog:
* config/riscv/r
Commit 0547dbb725b reduced the number of cases in which
union padding bits are zeroed when the relevant language
standard does not strictly require it, unless gcc was
invoked with -fzero-init-padding-bits=unions or
-fzero-init-padding-bits=all in order to explicitly
request zeroing of padding bits.
Hi Joseph,
On Wed, May 21, 2025 at 04:26:46PM +, Joseph Myers wrote:
> On Wed, 21 May 2025, Alejandro Colomar wrote:
>
> > @@ -10572,6 +10583,8 @@ c_parser_unary_expression (c_parser *parser)
> > case CPP_KEYWORD:
> >switch (c_parser_peek_token (parser)->keyword)
> > {
> > +
Sending again because my previous reply got a weird 'Got' word as its
header that might be making it looks like a mistake.
On 14/05/2025 18:46, Jonathan Wakely wrote:
On Wed, 14 May 2025 at 17:31, François Dumont wrote:
On 12/05/2025 23:03, Jonathan Wakely wrote:
On 31/03/25 22:20 +0200, Fra
On Wed, 21 May 2025, Jonathan Wakely wrote:
> Because this constructor delegates to vector(a) the object has been
> fully constructed and the destructor will run if an exception happens.
> That means we need to set _M_finish == _M_start so that the destructor
> doesn't try to destroy any elements.
On 5/20/25 11:28 AM, Patrick Palka wrote:
On Mon, 19 May 2025, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/15/14?
Whoops, CI reports I missed a testsuite adjustment expecting an
additional error in other/default13.C, which seems reasonab
Commit 0547dbb725b reduced the number of cases in which
union padding bits are zeroed when the relevant language
standard does not strictly require it, unless gcc was
invoked with -fzero-init-padding-bits=unions or
-fzero-init-padding-bits=all in order to explicitly
request
Commit 0547dbb725b reduced the number of cases in which
union padding bits are zeroed when the relevant language
standard does not strictly require it, unless gcc was
invoked with -fzero-init-padding-bits=unions or
-fzero-init-padding-bits=all in order to explicitly
request zeroing of padding bits.
On Wed, May 21, 2025 at 10:19 PM Robin Dapp wrote:
>
> > I could imagine that is a simpler way to set the march since the march
> > string becomes terribly long - we have an arch string more than 300
> > char...so I support this, although I think this should be discuss with
> > LLVM community, but
So a followup to last week's bugfix. In last week's change we we
stopped using define_insn_and_split to rewrite instructions. That
change was done to avoid dropping a masking instruction out of the RTL.
As a result the pattern(s) were changed into simple define_insns, which
is good. One of
libstdc++-v3/ChangeLog:
* testsuite/std/format/parse_ctx.cc: Fix typo for bfloat16 guard.
---
Ok for mainline?
libstdc++-v3/testsuite/std/format/parse_ctx.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/std/format/parse_ctx.cc
b/libstdc++-v
On Wed, 21 May 2025, Alejandro Colomar wrote:
> Makes sense. I'm unsure where exactly I should put it. Is this okay?
>
> diff --git i/gcc/c/c-parser.cc w/gcc/c/c-parser.cc
> index 87700339394b..08350a216dd8 100644
> --- i/gcc/c/c-parser.cc
> +++ w/gcc/c/c-parser.cc
>
Hi Joseph,
Thanks for reviewing my patch.
On 20/05/2025 18:02, Joseph Myers wrote:
On Tue, 20 May 2025, Christopher Bazley wrote:
+ if (!cleared)
+ {
+ if (complete_p.padded_non_union
+ && warn_zero_init_padding_bits >= ZERO_INIT_PADDING_BITS_ALL)
+
On Wed, May 21, 2025 at 01:42:01PM +0100, Christopher Bazley wrote:
> On 21/05/2025 12:26, Christopher Bazley wrote:
> > Hi Joseph,
> >
> > Thanks for reviewing my patch.
> >
> > On 20/05/2025 18:02, Joseph Myers wrote:
> > > On Tue, 20 May 2025, Christopher Bazley wrote:
> > >
> > > > + if (
It's missing the "registration" of the three new classes in
std.cc.in.
On 5/21/25 11:40, Luc Grosheintz wrote:
Follows up on:
https://gcc.gnu.org/pipermail/libstdc++/2025-May/061535.html
To improve naming conventions, this series includes three new commits:
* Two commits to rename _ExtentsS
On 5/21/25 5:06 AM, Richard Sandiford wrote:
Jeff Law writes:
Given you know the RTL gen* related thingies better than anyone, I'd say
go forward and if there's any fallout, we can certainly cope with it.
Thanks. I've now pushed the series and the earlier genemit tweaks,
with the discusse
Could you make a simple testcase that could vectorize two loops in
different modes (e.g one SI and one SF) and with this param will only
auto vec on loop?
On Wed, May 21, 2025 at 9:47 PM Robin Dapp wrote:
>
> Hi,
>
> This patch adds a --param=autovec-mode=. When the param is
> specified we make
I could imagine that is a simpler way to set the march since the march
string becomes terribly long - we have an arch string more than 300
char...so I support this, although I think this should be discuss with
LLVM community, but I think it's fine to accept as a GCC extension.
So LGTM, go ahead t
On Wed, 21 May 2025, Christopher Bazley wrote:
> Would you agree this is adequate? If anyone wants different source code
> locations to be highlighted then a future commit could change that.
In this case the locations seem reasonable.
--
Joseph S. Myers
josmy...@redhat.com
Dear Richard,
Thank you so much for your reply. I submitted the patch for the third case to
LLVM before I've received your reply, and they said the same thing,
that it would probably be used outside of loops as well and it would inflict
a branch misprediction, so it should be implemented at the le
On Wed, May 21, 2025 at 1:20 PM Jakub Jelinek wrote:
>
> On Wed, May 21, 2025 at 11:48:34AM +0200, Uros Bizjak wrote:
> > Please introduce "x86_64_neg_const_int_operand" predicate that will
> > allow only const_int operands, and will reject negative endbr (and
> > wide DImode) const_ints. You don'
Hi Jakub,
Thanks for your review.
On 21/05/2025 13:51, Jakub Jelinek wrote:
On Wed, May 21, 2025 at 01:42:01PM +0100, Christopher Bazley wrote:
On 21/05/2025 12:26, Christopher Bazley wrote:
Hi Joseph,
Thanks for reviewing my patch.
On 20/05/2025 18:02, Joseph Myers wrote:
On Tue, 20 May 2
Hi,
This patch allows an -march string like
-march=sifive-p670
in order to allow overriding a previous -march in a simple way.
Suppose we have a Makefile that specifies -march=rv64gc by default.
A user-specified -mcpu=sifive-p670 would be after the -march in the
options string and thus only s
Could you make a simple testcase that could vectorize two loops in
different modes (e.g one SI and one SF) and with this param will only
auto vec on loop?
I added a test now in the attached v2 that checks that we vectorize with the
requested mode. Right now the patch only takes away "additiona
Patch is originally from Siarhei Volkau .
RISC-V has a zero register (x0) which we can use to store zero into memory
without loading the constant into a distinct register. Adjust the
constraints
of the 32-bit movdi_32bit pattern to recognize that we can store 0.0 into
memory using x0 as the source
101 - 145 of 145 matches
Mail list logo
