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
> >>> + &&
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 Deriv
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
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
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
> 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
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
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); /* {
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
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
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
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
>
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
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
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
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 f
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
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
g 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 Liew via Gcc-patches
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
