[PATCH v2] c: ICE in build_counted_by_ref [PR116735]

2024-10-02 Thread Qing Zhao
From: qing zhao Hi, this is the 2nd version of the patch. compared to the 1st version, the major changes are to address Marek and Jacub's comments. bootstrapped and regression tested on both x86 and aarch64. Okay for committing? thanks. Qing == When handlin

[PATCH] C/116735 - ICE in build_counted_by_ref

2024-10-02 Thread Qing Zhao
From: qing zhao When handling the counted_by attribute, if the corresponding field doesn't exit, in additiion to issue error, we should also remove the already added non-existing "counted_by" attribute from the field_decl. bootstrapped and regression tested on both x86 and aa

Re: [PATCH] C/116735 - ICE in build_counted_by_ref

2024-10-02 Thread Qing Zhao
> On Oct 2, 2024, at 11:48, Marek Polacek wrote: > > On Wed, Oct 02, 2024 at 03:26:26PM +0000, Qing Zhao wrote: >> From: qing zhao >> >> When handling the counted_by attribute, if the corresponding field >> doesn't exit, in additiion to issue error

Re: [PATCH] C/116735 - ICE in build_counted_by_ref

2024-10-02 Thread Qing Zhao
> On Oct 2, 2024, at 12:05, Jakub Jelinek wrote: > > On Wed, Oct 02, 2024 at 11:48:16AM -0400, Marek Polacek wrote: >>> + error_at (DECL_SOURCE_LOCATION (field_decl), >>> + "argument %qE to the %qE attribute is not a field declaration" >>> + " in the same structure as %qD", fieldname, >>>

Re: [PATCH v8] Provide new GCC builtin __builtin_counted_by_ref [PR116016]

2024-10-15 Thread Qing Zhao
Thanks. Pushed as: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=e7380688fa5917011c3fb85b5e06fb00f776a95d Qing > On Oct 15, 2024, at 12:23, Joseph Myers wrote: > > On Fri, 11 Oct 2024, Qing Zhao wrote: > >> Hi, This is the 8th version of the patch. >> >> Co

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

2024-11-25 Thread Qing Zhao
Hi, Martin, I didn’t go through all the details of your patch. But I have one question: Did you consider the effect of the option -fstrict-flex-array (https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/C-Dialect-Options.html#index-fstrict-flex-arrays) on how gcc treats the zero size trailing array,

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-11-18 Thread Qing Zhao
> On Nov 18, 2024, at 13:10, Martin Uecker wrote: > > Am Montag, dem 18.11.2024 um 17:55 + schrieb Qing Zhao: >> Hi, >> >> I am working on extending “counted_by” attribute to pointers inside a >> structure per our previous discussion. >> >

Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-11-18 Thread Qing Zhao
Hi, I am working on extending “counted_by” attribute to pointers inside a structure per our previous discussion. I need advice on the following question: Should -fsantize=bounds support array reference that was referenced through a pointer that has counted_by attribute? For the following sm

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-11-20 Thread Qing Zhao
> On Nov 20, 2024, at 14:23, Martin Uecker wrote: > > Am Mittwoch, dem 20.11.2024 um 17:37 + schrieb Qing Zhao: >> Hi, Martin, >> >> Thanks a lot for pointing this out. >> >> This does look like a problem we need avoid for the pointer arrays. >

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-11-20 Thread Qing Zhao
> On Nov 19, 2024, at 16:36, Martin Uecker wrote: > > Am Montag, dem 18.11.2024 um 21:31 + schrieb Qing Zhao: >> >>> On Nov 18, 2024, at 13:10, Martin Uecker wrote: >> > ... >> So, I guess that the more accurate question is, for the followi

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-11-20 Thread Qing Zhao
> On Nov 19, 2024, at 10:47, Marek Polacek wrote: > > On Mon, Nov 18, 2024 at 07:10:35PM +0100, Martin Uecker wrote: >> Am Montag, dem 18.11.2024 um 17:55 +0000 schrieb Qing Zhao: >>> Hi, >>> >>> I am working on extending “counted_by” attribute t

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-11-20 Thread Qing Zhao
; On Mon, Nov 18, 2024 at 07:10:35PM +0100, Martin Uecker wrote: >>>>> Am Montag, dem 18.11.2024 um 17:55 + schrieb Qing Zhao: >>>>>> Hi, >>>>>> >>>>>> I am working on extending “counted_by” attribute to pointers inside

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-11-20 Thread Qing Zhao
proposed solution to this problem? Qing > On Nov 20, 2024, at 10:52, Martin Uecker wrote: > > Am Mittwoch, dem 20.11.2024 um 15:27 + schrieb Qing Zhao: >> >>> On Nov 19, 2024, at 10:47, Marek Polacek wrote: >>> >>> On Mon, Nov 18, 2024 at 07:10:35PM

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-11-20 Thread Qing Zhao
ontag, dem 18.11.2024 um 17:55 + schrieb Qing Zhao: >>>>> Hi, >>>>> >>>>> I am working on extending “counted_by” attribute to pointers inside a >>>>> structure per our previous discussion. >>>>> >>>>

Re: [PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

2024-11-18 Thread Qing Zhao
4:31:29PM +0000, Qing Zhao wrote: >> This is the 4th version of the patch for fixing PR109071. > > Thanks for all the work on this! I've been doing Linux kernel builds > with it and am finding many places where the new diagnostics make the > warning understandable. There was an e

Ping: [PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

2024-11-15 Thread Qing Zhao
024, at 11:31, Qing Zhao wrote: > > Hi, > > This is the 4th version of the patch for fixing PR109071. > > Compared to the 3nd version: > https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666870.html > https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666872

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

2024-11-26 Thread Qing Zhao
> On Nov 25, 2024, at 16:46, Martin Uecker wrote: > > > Hi Qing, > > Am Montag, dem 25.11.2024 um 17:40 + schrieb Qing Zhao: >> Hi, Martin, >> >> I didn’t go through all the details of your patch. >> >> But I have one question: >>

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-11-26 Thread Qing Zhao
'p->array', and 'ref2' uses 'val2' as the number of elements in 'p->array’. " Has this feature been used by Linux kernel already? Is this feature really needed by Linux kernel? Thanks a lot for suggestions and comments. Qing > On Nov 20,

2nd Ping: [PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

2024-11-26 Thread Qing Zhao
:34, Qing Zhao wrote: > > Gentle ping on the middle-end review for this patch. > > There are two parts of this patch: > > 1. Diagnostic part (Part 2), which has been reviewed by David; > 2. Middle end part (Part 1 and 3), mainly on the copy_history information > colle

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-12-02 Thread Qing Zhao
> On Nov 30, 2024, at 07:22, Martin Uecker wrote: > > Am Dienstag, dem 26.11.2024 um 20:59 + schrieb Qing Zhao: >> Think this over these days, I have another thought that need some feedback: >> >> The major issue right now is: >> >> 1. For the follo

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

2024-12-02 Thread Qing Zhao
> On Nov 30, 2024, at 07:10, Martin Uecker wrote: > > Am Dienstag, dem 26.11.2024 um 15:15 + schrieb Qing Zhao: >> >>> On Nov 25, 2024, at 16:46, Martin Uecker wrote: >>> >>> >>> Hi Qing, >>> >>> Am Montag, dem 25.11

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-12-02 Thread Qing Zhao
> On Dec 2, 2024, at 16:13, Martin Uecker wrote: > > Am Montag, dem 02.12.2024 um 20:15 + schrieb Qing Zhao: >> >>> On Nov 30, 2024, at 07:22, Martin Uecker wrote: >>> >>> Am Dienstag, dem 26.11.2024 um 20:59 + schrieb Qing Zhao: >&

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

2024-12-02 Thread Qing Zhao
> On Dec 2, 2024, at 16:00, Martin Uecker wrote: > > Am Montag, dem 02.12.2024 um 16:31 + schrieb Qing Zhao: >> >>> On Nov 30, 2024, at 07:10, Martin Uecker wrote: >>> >>> Am Dienstag, dem 26.11.2024 um 15:15 + schrieb Qing Zhao: >>&g

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-12-03 Thread Qing Zhao
> On Dec 3, 2024, at 10:07, Martin Uecker wrote: > > Am Dienstag, dem 03.12.2024 um 14:31 + schrieb Qing Zhao: >> >>> On Dec 3, 2024, at 01:33, Martin Uecker wrote: >>> >>> Am Montag, dem 02.12.2024 um 22:58 + schrieb Qing Zhao: >>&

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-12-03 Thread Qing Zhao
> On Dec 3, 2024, at 01:33, Martin Uecker wrote: > > Am Montag, dem 02.12.2024 um 22:58 + schrieb Qing Zhao: >> >>> On Dec 2, 2024, at 16:13, Martin Uecker wrote: >>> >>> Am Montag, dem 02.12.2024 um 20:15 + schrieb Qing Zhao: >>&g

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

2024-12-03 Thread Qing Zhao
> On Dec 3, 2024, at 01:25, Martin Uecker wrote: > > Am Montag, dem 02.12.2024 um 22:33 + schrieb Qing Zhao: > > > >>>> >>>> diff --git a/gcc/testsuite/gcc.dg/pr114014.c >>>> b/gcc/testsuite/gcc.dg/pr114014.c >>

3rd Ping: [Middle-end][PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

2024-12-05 Thread Qing Zhao
This is the 3rd ping of the Middle-end review for this patch. Thanks a lot! Qing > On Nov 26, 2024, at 10:30, Qing Zhao wrote: > > Another ping on the Middle-end review of this patch. > > This patch has been waiting for the middle-end review for a long time. > >

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-12-06 Thread Qing Zhao
> On Dec 5, 2024, at 17:31, Martin Uecker wrote: > > Am Donnerstag, dem 05.12.2024 um 21:09 + schrieb Qing Zhao: >> >>> On Dec 3, 2024, at 10:29, Qing Zhao wrote: > > > >>>> >>>>>> >>>>>>>>

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-12-09 Thread Qing Zhao
> On Dec 7, 2024, at 03:57, Martin Uecker wrote: > > Am Freitag, dem 06.12.2024 um 16:13 + schrieb Qing Zhao: >> >>> On Dec 6, 2024, at 10:56, Martin Uecker wrote: >>> >>> Am Freitag, dem 06.12.2024 um 14:16 + schrieb Qing Zhao: >>&

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-06 Thread Qing Zhao
> On Jan 4, 2025, at 12:58, Jeff Law wrote: > > > > On 1/3/25 10:30 AM, Qing Zhao wrote: >>> On Jan 3, 2025, at 11:41, Richard Biener wrote: >>> >>> >>> >>>> Am 03.01.2025 um 16:22 schrieb Jeff Law : >>>>

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-06 Thread Qing Zhao
> On Jan 6, 2025, at 11:01, Richard Biener wrote: > > On Mon, Jan 6, 2025 at 3:43 PM Qing Zhao wrote: >> >> >> >>> On Jan 6, 2025, at 09:21, Jeff Law wrote: >>> >>> >>> >>> On 1/6/25 7:11 AM, Qing Zhao wrote: >&

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-06 Thread Qing Zhao
> On Jan 6, 2025, at 09:21, Jeff Law wrote: > > > > On 1/6/25 7:11 AM, Qing Zhao wrote: >>> >>> Given it doesn't cause user visible UB, we could insert the trap *before* >>> the UB inducing statement. That would then make the statement unr

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

2025-01-30 Thread Qing Zhao
Hi, Bill, Sorry for the late reply (just be back from a short vacation). > On Jan 23, 2025, at 17:44, Bill Wendling wrote: > > On Fri, Jan 17, 2025 at 8:20 AM Qing Zhao wrote: >> >> Hi, Bill, >> >> Thanks a lot for your testing case. >> >> I s

[RFC][libgcc][PATCH] Fix two issues in libgcc/unwind-dw2-fde.c.

2025-02-04 Thread Qing Zhao
Hi, One of our big application segv in libgcc code while unwinding the stack. This is a random crash while the application throws a c++ exception and unwinds the stack. Incidents are random and never can be reproduced by any test case. The libgcc that is used is based on GCC 8. Fortunately, we

Re: [RFC][libgcc][PATCH] Fix two issues in libgcc/unwind-dw2-fde.c.

2025-02-05 Thread Qing Zhao
> On Feb 5, 2025, at 07:46, Richard Biener wrote: > > On Tue, Feb 4, 2025 at 10:12 PM Qing Zhao wrote: >> >> Hi, >> >> One of our big application segv in libgcc code while unwinding the stack. >> >> This is a random crash while the applicat

Re: [RFC][libgcc][PATCH] Fix two issues in libgcc/unwind-dw2-fde.c.

2025-02-05 Thread Qing Zhao
> On Feb 5, 2025, at 07:49, Jakub Jelinek wrote: > > On Wed, Feb 05, 2025 at 01:46:02PM +0100, Richard Biener wrote: >>> Please let me know any comments on this? >> >> I think I've seen this elsewhere -- the issue is the unwind register API does >> not allow for failures but I also think calli

Re: [RFC][libgcc][PATCH] Fix two issues in libgcc/unwind-dw2-fde.c.

2025-02-06 Thread Qing Zhao
> On Feb 6, 2025, at 04:36, Richard Biener wrote: > > On Wed, Feb 5, 2025 at 4:40 PM Qing Zhao wrote: >> >> >> >>> On Feb 5, 2025, at 07:46, Richard Biener wrote: >>> >>> On Tue, Feb 4, 2025 at 10:12 PM Qing Zhao wrote: >>>&

Re: [RFC][libgcc][PATCH] Fix two issues in libgcc/unwind-dw2-fde.c.

2025-02-06 Thread Qing Zhao
> On Feb 6, 2025, at 09:25, Richard Biener wrote: > > On Thu, Feb 6, 2025 at 2:57 PM Qing Zhao wrote: >> >> >> >>> On Feb 6, 2025, at 04:36, Richard Biener wrote: >>> >>> On Wed, Feb 5, 2025 at 4:40 PM Qing Zhao wrote: >>&g

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-12-13 Thread Qing Zhao
> On Dec 12, 2024, at 17:36, Martin Uecker wrote: > > Am Donnerstag, dem 12.12.2024 um 13:59 -0800 schrieb Bill Wendling: >> >> >> So, it’s the correct behavior for the counted_by attribute for FAM based >> on our previous discussion and agreement. > > If it is indee

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-12-05 Thread Qing Zhao
> On Dec 3, 2024, at 10:29, Qing Zhao wrote: > > > >> On Dec 3, 2024, at 10:07, Martin Uecker wrote: >> >> Am Dienstag, dem 03.12.2024 um 14:31 + schrieb Qing Zhao: >>> >>>> On Dec 3, 2024, at 01:33, Martin Uecker wrote: >>

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

2024-12-06 Thread Qing Zhao
> On Dec 6, 2024, at 10:56, Martin Uecker wrote: > > Am Freitag, dem 06.12.2024 um 14:16 + schrieb Qing Zhao: >> >>> On Dec 5, 2024, at 17:31, Martin Uecker wrote: >>> >>> Am Donnerstag, dem 05.12.2024 um 21:09 + schrieb Qing Zhao: >&

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-08 Thread Qing Zhao
> On Jan 7, 2025, at 07:29, Richard Biener wrote: > > On Mon, Jan 6, 2025 at 5:40 PM Qing Zhao wrote: >> >> >> >>> On Jan 6, 2025, at 11:01, Richard Biener wrote: >>> >>> On Mon, Jan 6, 2025 at 3:43 PM Qing Zhao wrote: >>>

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-10 Thread Qing Zhao
> On Jan 10, 2025, at 15:34, Jeff Law wrote: > > > > On 1/9/25 1:39 PM, Qing Zhao wrote: >>> On Jan 9, 2025, at 14:10, Jeff Law wrote: >>> >>> >>> >>> On 1/9/25 10:48 AM, Qing Zhao wrote: >>> >>>>&g

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

2025-01-21 Thread Qing Zhao
> On Jan 20, 2025, at 16:19, Joseph Myers wrote: > > On Sat, 18 Jan 2025, Kees Cook wrote: > >> Gaining access to global variables is another gap Linux has -- e.g. we >> have arrays that are sized by the global number-of-cpus variable. :) > > Note that it's already defined that counted_by ta

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

2025-01-21 Thread Qing Zhao
> On Jan 17, 2025, at 18:13, Joseph Myers wrote: > > On Fri, 17 Jan 2025, Qing Zhao wrote: > >> struct fc_bulk { >> ... >> struct fs_bulk fs_bulk; >> struct fc fcs[] __counted_by(fs_bulk.len); >> }; >> >> i.e, the “counted_by” field

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

2025-01-22 Thread Qing Zhao
> On Jan 22, 2025, at 11:22, Martin Uecker wrote: > > > Hello Michael, > > Am Mittwoch, dem 22.01.2025 um 16:54 +0100 schrieb Michael Matz: >> On Wed, 22 Jan 2025, Martin Uecker wrote: >> > So you do not need to look further. But maybe I am missing something > else. Lik

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

2025-01-23 Thread Qing Zhao
> On Jan 22, 2025, at 12:20, Martin Uecker wrote: > > Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker: >> Am Mittwoch, dem 22.01.2025 um 16:37 +0000 schrieb Qing Zhao: >>> >>>> On Jan 22, 2025, at 11:22, Martin Uecker wrote: >>&

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

2025-01-23 Thread Qing Zhao
> On Jan 23, 2025, at 13:27, Martin Uecker wrote: > > Am Donnerstag, dem 23.01.2025 um 17:39 + schrieb Qing Zhao: >> >>> On Jan 22, 2025, at 12:20, Martin Uecker wrote: >>> >>> Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker:

5th Ping: [Middle-end][PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

2025-01-13 Thread Qing Zhao
loop unrolling)? B. If not, how to improve the current design to make it more extendable? C. If yes, whether it’s okay to add this patches into GCC15, and then improve it in GCC16? Thanks. Qing > On Dec 23, 2024, at 12:29, Qing Zhao wrote: > > Hi, > > This is the 4th pin

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-03 Thread Qing Zhao
> On Jan 3, 2025, at 11:41, Richard Biener wrote: > > > >> Am 03.01.2025 um 16:22 schrieb Jeff Law : >> >> So this is an implementation of an idea I had a few years back and >> prototyped last spring to fix pr92539. >> >> pr92539 is a false positive Warray-bounds warning triggered by loop

Re: [PATCH] c: do not warn about truncating NUL char when initializing nonstring arrays [PR117178]

2024-12-23 Thread Qing Zhao
Hi, Kees, (Sorry for the late reply, I was on vacation last week). I read all the comments of PR117178 and also your patch. Yes, I think the behavior of this patch is reasonable. The updated diagnostic messages are more accurate and helpful. And the testing cases look good. I am wondering wh

4th Ping: [Middle-end][PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

2024-12-23 Thread Qing Zhao
messages Date: December 6, 2024 at 13:32:55 EST To: Qing Zhao , Jeff Law Cc: richard Biener , GCC Patches , kees Cook , Andrew Pinski , David Malcolm Qing Zhao writes: This is the 3rd ping of the Middle-end review for this patch. Jeff, would you be able to take a look? (In part because I know

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-10 Thread Qing Zhao
> On Jan 10, 2025, at 03:00, Richard Biener wrote: > > On Thu, Jan 9, 2025 at 9:39 PM Qing Zhao wrote: >> >> >> >>> On Jan 9, 2025, at 14:10, Jeff Law wrote: >>> >>> >>> >>> On 1/9/25 10:48 AM, Qing Zhao wrote:

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-09 Thread Qing Zhao
> On Jan 9, 2025, at 03:17, Sam James wrote: > > Richard Biener writes: > >> On Wed, Jan 8, 2025 at 5:34 PM Qing Zhao wrote: >>> >>> >>> >>>> On Jan 7, 2025, at 07:29, Richard Biener >>>> wrote: >>>> >

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-09 Thread Qing Zhao
> On Jan 9, 2025, at 03:08, Richard Biener wrote: > > On Wed, Jan 8, 2025 at 5:34 PM Qing Zhao wrote: >> >> >> >>> On Jan 7, 2025, at 07:29, Richard Biener wrote: >>> >>> On Mon, Jan 6, 2025 at 5:40 PM Qing Zhao wrote: >>&g

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-10 Thread Qing Zhao
> On Jan 10, 2025, at 10:05, Richard Biener wrote: > > On Fri, Jan 10, 2025 at 3:27 PM Qing Zhao wrote: >> >> >> >>> On Jan 10, 2025, at 03:00, Richard Biener >>> wrote: >>> >>> On Thu, Jan 9, 2025 at 9:39 PM Qing Zhao wr

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

2025-01-17 Thread Qing Zhao
src/gcc/builtins.cc:10838 > 0xb6a5be fold_builtin_n > ../../gcc.src/gcc/builtins.cc:10950 > 0x1203910 dynamic_object_sizes_execute_one > ../../gcc.src/gcc/tree-object-size.cc:2187 > 0x1203910 object_sizes_execute > ../../gcc.src/gcc/tree-object-size.cc:2250 > Please submit

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

2025-01-17 Thread Qing Zhao
Joseph, Kees and Bill, I need your input on this. > On Jan 17, 2025, at 10:12, Martin Uecker wrote: > > Am Donnerstag, dem 16.01.2025 um 21:18 + schrieb Qing Zhao: >> > .. >> >> Although in the previous discussion, I agreed with Martin that we should us

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-09 Thread Qing Zhao
> On Jan 9, 2025, at 14:10, Jeff Law wrote: > > > > On 1/9/25 10:48 AM, Qing Zhao wrote: > >>> >>> I think Jeff's patch is not reasonable since it boils down to not diagnose >>> -Warray-bounds but instead remove those stmts. >> If

[GCC16 stage 1][RFC][C][PATCH 1/3] Extend "counted_by" attribute to pointer fields of structures.

2025-01-16 Thread Qing Zhao
For example: struct PP { size_t count2; char other1; char *array2 __attribute__ ((counted_by (count2))); int other2; } *pp; specifies that the "array2" is an array that is pointed by the pointer field, and its number of elements is given by the field "count2" in the same structure. gcc/c

[GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

2025-01-16 Thread Qing Zhao
ound checker to pointer references with counted_by attributes, the hardest part is to get the INDEX of the corresponding array ref from the offset computation expression of the pointer ref. The whole patch set has been bootstrapped and regression tested on both aarch64 and x86. Let

[GCC16 stage 1][RFC][PATCH 2/3] Convert a pointer reference with counted_by attribute to .ACCESS_WITH_SIZE and use it in builtinin-object-size.

2025-01-16 Thread Qing Zhao
gcc/c/ChangeLog: * c-typeck.cc (build_counted_by_ref): Handle pointers with counted_by. (build_access_with_size_for_counted_by): Likewise. gcc/ChangeLog: * tree-object-size.cc (access_with_size_object_size): Handle pointers with counted_by. (collect_object

[GCC16 stage 1][RFC][C][PATCH 3/3] Use the counted_by attribute of pointers in array bound checker.

2025-01-16 Thread Qing Zhao
Current array bound checker only instruments ARRAY_REF, and the INDEX information is the 2nd operand of the ARRAY_REF. When extending the array bound checker to pointer references with counted_by attributes, the hardest part is to get the INDEX of the corresponding array ref from the offset comput

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

2025-01-16 Thread Qing Zhao
> On Jan 16, 2025, at 17:29, Bill Wendling wrote: > > On Thu, Jan 16, 2025 at 1:19 PM Qing Zhao wrote: >> >> Hi, >> >> This is the patch set to extend "counted_by" attribute to pointer fields of >> structures. >> >> For e

[RFC][C]New syntax for the argument of counted_by attribute for C language

2025-03-06 Thread Qing Zhao
Hi, Since I sent the patch series for “extend counted_by attribute to pointer fields of structure” two months ago, a lot of discussion were invoked both in GCC community and CLANG community: https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673837.html https://discourse.llvm.org/t/rfc-enfor

Re: [RFC][C]New syntax for the argument of counted_by attribute for C language

2025-03-11 Thread Qing Zhao
new syntax to the C standard. We’ll discuss how we address problems raised > here. Please see my inlined comments. > > Best, > Yeoul > > >> On Mar 6, 2025, at 2:03 PM, Yeoul Na wrote: >> >> + John & Félix & Patryk & Henrik >> >>&

Re: [PATCH] c: Assorted fixes for flexible array members in unions [PR119001]

2025-02-27 Thread Qing Zhao
Hi, Jakub, Thanks a lot for fixing this issues. Qing > On Feb 26, 2025, at 03:53, Jakub Jelinek wrote: > > Hi! > > r15-209 allowed flexible array members inside of unions, but as the > following testcase shows, not everything has been adjusted for that. > Unlike structures, in unions flexible

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-03-13 Thread Qing Zhao
> On Mar 12, 2025, at 12:40, Martin Uecker wrote: > > Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao: >> >>> On Mar 10, 2025, at 15:34, Martin Uecker wrote: >>> >>> Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall:

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-03-11 Thread Qing Zhao
Hi, Henrik, John, Sorry for my late reply to the thread. Before I wrote this proposal, I spent quite some time try to understand why people from C community and C++ community have so different views on the current syntax of counted_by. Then I spent some time to study and compare the variable

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-03-12 Thread Qing Zhao
> On Mar 10, 2025, at 15:34, Martin Uecker wrote: > > Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall: >> > > ... > >> That said, my preference is still to just give preference to the field name, >> which sidesteps any need for disambiguation syntax and avoids this whole >> pro

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-03-13 Thread Qing Zhao
> On Mar 12, 2025, at 18:46, Yeoul Na wrote: > > > >> On Mar 12, 2025, at 3:40 PM, Bill Wendling wrote: >> >> On Wed, Mar 12, 2025 at 3:28 PM Yeoul Na wrote: On Mar 12, 2025, at 2:51 PM, John McCall wrote: On 12 Mar 2025, at 16:02, Bill Wendling wrote: > Qing pointed o

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-03-13 Thread Qing Zhao
> On Mar 13, 2025, at 12:29, Martin Uecker wrote: > > Am Donnerstag, dem 13.03.2025 um 15:41 + schrieb Qing Zhao: >> >>> On Mar 12, 2025, at 12:40, Martin Uecker wrote: >>> >>> Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao: >

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-03-13 Thread Qing Zhao
> On Mar 12, 2025, at 12:58, Joseph Myers wrote: > > On Wed, 12 Mar 2025, Martin Uecker wrote: > >> For a designator >> >> struct foo { int n; } a = { .n = 1 }; >> >> we also refer to a member 'n' of an instance 'a' of a structure type. >> The instance is simply implied by the context. >> >

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-04-04 Thread Qing Zhao
> On Apr 4, 2025, at 12:40, Jakub Jelinek wrote: > > On Fri, Apr 04, 2025 at 04:25:11PM +0000, Qing Zhao wrote: >>> It is not just the parser, it is also the human reader who should be >>> able to clearly distinguish this (which is why I still prefer >>> d

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-03-27 Thread Qing Zhao
Yeoul, Thanks for the writeup. So, basically, This writeup insisted on introducing a new “structure scope” (similar as the instance scope in C++) into C language ONLY for counted_by attribute: 1. Inside counted_by attribute, the name lookup starts: A. Inside the current structure first (t

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

2025-04-08 Thread Qing Zhao
ny comment? Qing > On Apr 8, 2025, at 10:53, Qing Zhao wrote: > > > >> On Apr 7, 2025, at 22:15, Siddhesh Poyarekar wrote: >> >> On 2025-04-07 14:53, Qing Zhao wrote: >>>> Is there a reason to do this at the very end like this and

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

2025-04-08 Thread Qing Zhao
> On Apr 7, 2025, at 13:43, Siddhesh Poyarekar wrote: > > On 2025-04-07 11:56, Qing Zhao wrote: >> when the type is a structure with flexible array member. > > Not just when the structure has a flexible array member, also when the FAM > size is recorded in a __coun

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-09 Thread Qing Zhao
> On Apr 9, 2025, at 11:31, Siddhesh Poyarekar wrote: > > On 2025-04-09 08:30, Qing Zhao wrote: >> After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument. >> And all the size expression before the call to .ACCESS_WITH_SIZE might be >> dead >

Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

2025-04-09 Thread Qing Zhao
Hi, Joseph and Martin, When I implemented the patch to attach the counted_by information to an array reference (FAM reference) in C FE, The work was done inside the routine “build_component_ref” in gcc/c/c-typeck.cc . and this is very reasonable and quite clean. Now, If

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-09 Thread Qing Zhao
> On Apr 8, 2025, at 21:13, Siddhesh Poyarekar wrote: > > On 2025-04-08 15:22, Qing Zhao wrote: >> Changing a pointer reference to a call to .ACCESS_WITH_SIZE will impact the >> compiler optimization in two aspects: >> 1. The new call site might become a barrier

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

2025-04-10 Thread Qing Zhao
Hi, Martin, Thanks a lot for all your comments and questions, really helpful. > On Apr 10, 2025, at 01:41, Martin Uecker wrote: > > Am Mittwoch, dem 09.04.2025 um 18:31 + schrieb Qing Zhao: >> Hi, Joseph and Martin, >> >> When I implemented the patch to attach

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

2025-04-10 Thread Qing Zhao
> On Apr 7, 2025, at 22:15, Siddhesh Poyarekar wrote: > > On 2025-04-07 14:53, Qing Zhao wrote: >>> Is there a reason to do this at the very end like this and not in the >>> GIMPLE_ASSIGN case in the switch block? Something like this: >>> >>>

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

2025-04-10 Thread Qing Zhao
> On Apr 10, 2025, at 13:43, Martin Uecker wrote: > > Am Donnerstag, dem 10.04.2025 um 17:05 + schrieb Qing Zhao: >> Hi, Martin, >> >> Thanks a lot for all your comments and questions, really helpful. >> >> > > ... >>> >>&g

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-04-01 Thread Qing Zhao
> On Apr 1, 2025, at 10:04, Martin Uecker wrote: > > > > Am Montag, dem 31.03.2025 um 13:59 -0700 schrieb Bill Wendling: >>> I'd like to offer up this to solve the issues we're facing. This is a >>> combination of everything that's been discussed here (or at least that >>> I've been able to r

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-04-01 Thread Qing Zhao
> On Apr 1, 2025, at 15:25, Martin Uecker wrote: > > Am Dienstag, dem 01.04.2025 um 18:58 + schrieb Qing Zhao: >> >>> On Apr 1, 2025, at 11:28, Martin Uecker wrote: >>> >>> Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao: >>&

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

2025-04-01 Thread Qing Zhao
> On Apr 1, 2025, at 11:28, Martin Uecker wrote: > > Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao: >> >>> On Apr 1, 2025, at 10:04, Martin Uecker wrote: >>> >>> >>> >>> Am Montag, dem 31.03.2025 um 13:59 -0700 sch

[Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

2025-04-07 Thread Qing Zhao
when the type is a structure with flexible array member. In tree-object-size.cc, if the size is UNKNOWN after evaluating use-def chain, We can evaluate the SIZE of the pointee TYPE ONLY when this TYPE is a structure type with flexible array member, since a structure with FAM can not be an element

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

2025-04-08 Thread Qing Zhao
> On Apr 8, 2025, at 12:54, Siddhesh Poyarekar wrote: > > On 2025-04-08 12:41, Qing Zhao wrote: >> The gimple IR is: >> 1 int main () >> 2 { >> 3 int D.5072; >> 4 >> 5 { >> 6 struct annotated * q;

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-11 Thread Qing Zhao
> On Apr 10, 2025, at 11:12, Martin Uecker wrote: > > Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar: >> On 2025-04-10 10:50, Andrew MacLeod wrote: >>> Its not clear to me exactly what is being asked, but I think the >>> suggestion is that pointer references are being

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-11 Thread Qing Zhao
> On Apr 10, 2025, at 10:55, Siddhesh Poyarekar wrote: > > On 2025-04-10 10:50, Andrew MacLeod wrote: >> Its not clear to me exactly what is being asked, but I think the suggestion >> is that pointer references are being replaced with a builtin function called >> .ACCESS_WITH_SIZE ?and I

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-11 Thread Qing Zhao
> On Apr 11, 2025, at 10:42, Andrew MacLeod wrote: > > > On 4/11/25 10:27, Qing Zhao wrote: >> >>> On Apr 10, 2025, at 11:12, Martin Uecker wrote: >>> >>> Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar: >>>>

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-11 Thread Qing Zhao
> On Apr 11, 2025, at 10:53, Martin Uecker wrote: > > Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod: >> On 4/11/25 10:27, Qing Zhao wrote: >>> >>>> On Apr 10, 2025, at 11:12, Martin Uecker wrote: >>>> >>>> A

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-11 Thread Qing Zhao
> On Apr 11, 2025, at 12:20, Martin Uecker wrote: > > Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao: >> >>> On Apr 11, 2025, at 10:53, Martin Uecker wrote: >>> >>> Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLe

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-11 Thread Qing Zhao
> On Apr 11, 2025, at 13:37, Martin Uecker wrote: > > Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao: >> >>> On Apr 11, 2025, at 12:20, Martin Uecker wrote: >>> >>> Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao: >>&g

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-11 Thread Qing Zhao
> On Apr 11, 2025, at 13:55, Siddhesh Poyarekar wrote: > > On 2025-04-11 13:37, Martin Uecker wrote: >>> My understanding is that such issue with the implicit data flow dependency >>> information missing is only for the >>> counted_by attribute, not for the other TYPE which already have the bo

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-11 Thread Qing Zhao
> On Apr 11, 2025, at 14:12, Martin Uecker wrote: > > Am Freitag, dem 11.04.2025 um 13:55 -0400 schrieb Siddhesh Poyarekar: >> On 2025-04-11 13:37, Martin Uecker wrote: My understanding is that such issue with the implicit data flow dependency information missing is only for the >>>

Re: .ACCESS_WITH_SIZE and pointer ranges

2025-04-11 Thread Qing Zhao
> On Apr 11, 2025, at 14:24, Martin Uecker wrote: > > Am Freitag, dem 11.04.2025 um 18:14 + schrieb Qing Zhao: >> >>> On Apr 11, 2025, at 13:37, Martin Uecker wrote: >>> >>> Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao: >>&g

[Stage 1][Middle-end][PATCH v5 1/3] Provide more contexts for -Warray-bounds, -Wstringop-*warning messages due to code movements from compiler transfromaton (Part 1) [PR109071, PR85788, PR88771, PR106

2025-04-07 Thread Qing Zhao
44 index 000..83d8a42b577 --- /dev/null +++ b/gcc/diagnostic-move-history.cc @@ -0,0 +1,265 @@ +/* Functions to handle move history. + Copyright (C) 2024 Free Software Foundation, Inc. + Contributed by Qing Zhao + + This file is part of GCC. + + GCC is free software; you can redistribu

[Stage 1][Middle-end][PATCH v5 2/3] Provide more contexts for -Warray-bounds, -Wstringop-*warning messages due to code movements from compiler transformation (Part 2) [PR109071, PR85788, PR88771, PR10

2025-04-07 Thread Qing Zhao
size.to_uhwi (), ref.base, TREE_TYPE (ref.base))) - || warning_at (loc, opt, + || warning_at (&richloc, opt, form ? G_("%qD forming offset %s is out of "

[Stage 1][Middle-end][PATCH v5 3/3] Provide more contexts for -Warray-bounds, -Wstringop-* warning messages due to code movements from compiler transformation (Part 3) [PR109071, PR85788, PR88771, PR1

2025-04-07 Thread Qing Zhao
[PR109071,PR85788,PR88771,PR106762,PR108770,PR115274,PR117179] Add debugging for move history. PR tree-optimization/109071 PR tree-optimization/85788 PR tree-optimization/88771 PR tree-optimization/106762 PR tree-optimization/108770 PR tree-optimiza

<    1   2   3   4   5   6   7   8   9   10   >