On Fri, 25 Mar 2022 at 05:58, Jason Merrill wrote:
> >
> >>> + if (current_function_decl
> >>> + && (DECL_CONSTRUCTOR_P (current_function_decl)
> >>> + || DECL_DESTRUCTOR_P (current_function_decl))
> >>> + && TREE_CODE (expr) == NOP_EXPR
> >>> + && is_t
Thanks for the review. I've tested and uploaded a new patch v2 with
the requested changes.
On Thu, 17 Mar 2022 at 09:20, Jason Merrill wrote:
>
> On 3/14/22 02:36, Zhao Wei Liew via Gcc-patches wrote:
>
> > This patch adds a warning when casting "this" to
Thanks for the detailed review. I have uploaded patch v2 based on the review.
v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590604.html
Changes since v1:
1. Add patterns for the cases CST / (T)x and (T)x / CST as well. Fix
test regressions caused by those patterns.
2. Support signed
Hi!
This patch adds a warning when casting "this" to Derived* in the Base
class constructor and destructor. I've added the warning under the
-Wextra flag as I can't find a more appropriate flag for it.
The patch has been bootstrapped and regression tested on x86_64-pc-linux-gnu.
Appreciate revie
On Sat, 12 Mar 2022 at 06:15, Jason Merrill wrote:
> It looks good, but unfortunately regresses some other warning tests,
> such as Wnonnull5.C. Please remember to run the regression tests before
> sending a patch (https://gcc.gnu.org/contribute.html#testing).
>
> This seems to be a complicated p
Hi!
This patch aims to add a warning when casting "this" in a base class
constructor to a derived class type. It works on the test cases
provided, but I'm still running regression tests.
However, I have a few doubts:
1. Am I missing out any cases? Right now, I'm identifying the casts by
checking
On Tue, 22 Feb 2022 at 11:57, Zhao Wei Liew wrote:
>
> Hi,
>
> This is a partial optimization for PR103855.
>
> Initially, I looked into optimizing RTL generation or a more complex
> GIMPLE transformation so that we could optimize other cases as well,
> such as ((unsigned long long) short / int).
Hi,
This is a partial optimization for PR103855.
Initially, I looked into optimizing RTL generation or a more complex
GIMPLE transformation so that we could optimize other cases as well,
such as ((unsigned long long) short / int).
However, that is a bit too complex for now. While I continue to l
> On 19 Feb 2022, at 5:36 PM, Zhao Wei Liew wrote:
>
> This pattern converts (trunc_div (convert a) (convert b)) to
> (convert (trunc_div a b)) when:
>
> 1. type, a, and b all have unsigned integeral types
> 2. a and b have the same type precision
> 3. type has type precision at least as large
This pattern converts (trunc_div (convert a) (convert b)) to
(convert (trunc_div a b)) when:
1. type, a, and b all have unsigned integeral types
2. a and b have the same type precision
3. type has type precision at least as larger as a and b
This is useful as wider divisions are typically more ex
On Fri, 18 Feb 2022 at 08:32, Zhao Wei Liew wrote:
>
> > >>> +/* Test non-empty class */
> > >>> +void f2(B b1, B b2)
> > >>> +{
> > >>> + if (b1 = 0); /* { dg-warning "suggest parentheses" } */
> > >>> + if (b1 = 0.); /* { dg-warning "suggest parentheses" } */
> > >>> + if (b1 = b2); /* { dg-warn
On Thu, 17 Feb 2022 at 00:59, Jason Merrill wrote:
>
> On 2/16/22 02:16, Zhao Wei Liew wrote:
> > On Wed Feb 16, 2022 at 4:06 AM +08, Jason Merrill wrote:
> >>> Ah, I see. I found it a bit odd that gcc-commit-mklog auto-generated a
> >>> subject with "c:",
> >>> but I just went with it as I didn't
Before I start, sincere apologies for the email mishaps! I was setting up
an email client and somehow the emails I sent did not initially seem to
go through, but they actually did. You might have received several
duplicate emails as a result.
On Wed Feb 16, 2022 at 4:06 AM +08, Jason Merrill wrote
On Wed Feb 16, 2022 at 4:06 AM +08, Jason Merrill wrote:
> > Ah, I see. I found it a bit odd that gcc-commit-mklog auto-generated a
> > subject with "c:",
> > but I just went with it as I didn't know any better. Unfortunately, I
> > can't change it now on the current thread.
>
> That came from th
On Wed, 16 Feb 2022 at 00:30, Zhao Wei Liew wrote:
> On Tue, 15 Feb 2022 at 21:05, Jason Merrill wrote:
> > >>
> > >> I agree. However, I can't seem to call extract_call_expr directly
> > >> because it calls gcc_assert
> > >> to assert that the resulting expression is a CALL_EXPR or
> AGGR_INIT_
On Tue, 15 Feb 2022 at 21:05, Jason Merrill wrote:
> >>
> >> I agree. However, I can't seem to call extract_call_expr directly
> >> because it calls gcc_assert
> >> to assert that the resulting expression is a CALL_EXPR or
AGGR_INIT_EXPR.
> >> Instead, I've extracted the non-assert-related code in
On Tue, 15 Feb 2022 at 13:13, Jason Merrill wrote:
>
> On 2/14/22 21:30, Zhao Wei Liew wrote:
> > On 14/02/2022, Jason Merrill wrote:
> >>>
> >>> +/* Returns true if EXPR is a reference to an implicit
> >>> + call to operator=(). */
> >>> +static bool
> >>> +is_assignment_overload_ref_p (tree e
On 14/02/2022, Jason Merrill wrote:
>>
>> +/* Returns true if EXPR is a reference to an implicit
>> + call to operator=(). */
>> +static bool
>> +is_assignment_overload_ref_p (tree expr)
>> +{
>> + if (expr == NULL_TREE || !REFERENCE_REF_P (expr))
>> +return false;
>
> This will only warn a
On Fri, 11 Feb 2022 at 20:47, Jason Merrill wrote:
> >
> > On the other hand, for empty classes, it seems that a COMPOUND_EXPR
> > is built in build_over_call under the is_really_empty_class guard (line
> > 9791).
> > I don't understand the tree structure that I should identify though.
> > Could
On Fri, 11 Feb 2022 at 00:14, Jason Merrill wrote:
>
> On 2/9/22 21:18, Zhao Wei Liew via Gcc-patches wrote:
> > Hi!
> >
> > I wrote a patch for PR 25689, but I feel like it may not be the ideal
> > fix. Furthermore, there are some standing issues with the patch for
Hi!
I wrote a patch for PR 25689, but I feel like it may not be the ideal
fix. Furthermore, there are some standing issues with the patch for
which I would like tips on how to fix them.
Specifically, there are 2 issues:
1. GCC warns about if (a.operator=(0)). That said, this may not be a
major is
Sincere apologies for the issues. I wasn't aware of the need for a cast but
after reading the PRs, I understand that now. On the other hand, the
incorrect test case was simply a major oversight on my part.
I'll be sure to be more careful next time.
Thanks for the fixes!
This patch implements an optimization for the following C++ code:
int f(int x) {
return 1 / x;
}
int f(unsigned int x) {
return 1 / x;
}
Before this patch, x86-64 gcc -std=c++20 -O3 produces the following assembly:
f(int):
xor edx, edx
mov eax, 1
idiv edi
ret
f(unsigned
This patch implements an optimization for the following C++ code:
int f(int x) {
return 1 / x;
}
int f(unsigned int x) {
return 1 / x;
}
Before this patch, x86-64 gcc -std=c++20 -O3 produces the following
assembly:
f(int):
xor edx, edx
mov eax, 1
idiv edi
ret
f(unsigned
On Wed, 5 Jan 2022 at 17:55, Richard Biener
wrote:
> On Wed, Jan 5, 2022 at 10:42 AM Jakub Jelinek wrote:
> >
> > On Wed, Jan 05, 2022 at 10:38:53AM +0100, Richard Biener via Gcc-patches
> wrote:
> > > On Wed, Jan 5, 2022 at 10:18 AM Zhao Wei Liew
> wrote:
> > > >
> > > > > X >= -1 && X <= 1 is
simplifying it here as well, but
I'm not sure how to do the unsigned cast.
Besides that, thanks for the rest of your suggestions! I'm testing the
changes and will post a v2 soon.
On Wed, 5 Jan 2022 at 16:18, Richard Biener
wrote:
>
> On Wed, Jan 5, 2022 at 7:15 AM Zhao Wei L
match.pd/95424: Simplify 1 / X for integer X
This patch implements an optimization for the following C++ code:
int f(int x) {
return 1 / x;
}
int f(unsigned int x) {
return 1 / x;
}
Before this patch, x86-64 gcc -std=c++20 -O3 produces the following
assembly:
f(int):
xor edx, edx
27 matches
Mail list logo
