Re: libgompd output test
On Wed, Jun 29, 2022 at 06:45:51AM +0200, Mohamed Atef wrote:
> for this test case,
>
> 1.#include
> 2.#include
> 3.int
> 4.main()
> 5.{
> 6. omp_set_num_threads (5);
> 7. #pragma omp parallel
> 8.{
> 9. int th = omp_get_thread_num ();
> 10. printf ("i am thread %d\n", th);
> 11.}
> 12. return 0;
> 13.}
You can also use OMP_DISPLAY_ENV=verbose in the environment
to see how it is printed by the runtime.
> Reading symbols from a.out...
> OMPD GDB support loaded
> Run 'ompd init' to start debugging
> (gdb) ompd init
> Temporary breakpoint 1 at 0x40115a: file pro.c, line 6.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Temporary breakpoint 1, main () at pro.c:6
> 6 omp_set_num_threads (5);
> Loaded OMPD lib successfully!
Is the GDB OMPD patch available somewhere?
> (gdb) b 10
> Breakpoint 2 at 0x401198: file pro.c, line 10.
> (gdb) c
> Continuing.
> [New Thread 0x77d45700 (LWP 116224)]
> [New Thread 0x77544700 (LWP 116225)]
> [New Thread 0x76d43700 (LWP 116226)]
> [Switching to Thread 0x77d45700 (LWP 116224)]
>
> Thread 2 "a.out" hit Breakpoint -14, gomp_thread_start
> (xdata=0x7fffd950) at ../../../gcc/libgomp/config/linux/sem.h:46
> 46 *sem = value * SEM_INC;
> [New Thread 0x76542700 (LWP 116227)]
> [Switching to Thread 0x77544700 (LWP 116225)]
>
> Thread 3 "a.out" hit Breakpoint -14, gomp_thread_start
> (xdata=0x7fffd9d0) at ../../../gcc/libgomp/config/linux/sem.h:46
> 46 *sem = value * SEM_INC;
> [Switching to Thread 0x76d43700 (LWP 116226)]
>
> Thread 4 "a.out" hit Breakpoint -14, gomp_thread_start
> (xdata=0x7fffda50) at ../../../gcc/libgomp/config/linux/sem.h:46
> 46 *sem = value * SEM_INC;
> [Switching to Thread 0x76542700 (LWP 116227)]
>
> Thread 5 "a.out" hit Breakpoint -14, gomp_thread_start
> (xdata=0x7fffdad0) at ../../../gcc/libgomp/config/linux/sem.h:46
> 46 *sem = value * SEM_INC;
>
> Thread 5 "a.out" hit Breakpoint 2, main._omp_fn.0 () at pro.c:10
> 10printf ("i am thread %d\n", th);
> (gdb) bt
> #0 main._omp_fn.0 () at pro.c:10
> #1 0x77f9dd8e in gomp_thread_start (xdata=) at
> ../../../gcc/libgomp/team.c:131
> #2 0x77f48609 in start_thread (arg=) at
> pthread_create.c:477
> #3 0x77e6d133 in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> (gdb) ompd icv
> Initialized ICV map successfully for checking OMP API values.
> ICVName Scope Value
> ===
> cancel var address_space 0
> max task priority var address_space 0
> stack size var address_space 0
> debug var address_space 0
> OMP_DEBUGaddress_space enabled
> display affinity varaddress_space 0
> affinity format var address_space level %L thread
> %i affinity %A
This ought to be IMHO printed as a string literal, so "level %L thread %i
affinity %A"
> affinity format len var address_space 0
> wait policy var address_space 4294967295
> num teams var address_space 0
> teams thread limit var address_space 0
> spin count var address_space 30
> num proc varaddress_space 8
> throttled spin count varaddress_space 100
> managed threads var address_space 5
And also, it would be nice if it was clear which ICVs are GCC implementation
specific and which are standard (the spin count vars are non-standard).
Also, the names of ICVs in the standard are with hyphens, so perhaps print
cancel-var, max-task-priority-var etc.?
Jakub
Re: libgompd output test
On Wed, Jun 29, 2022 at 2:21 PM Jakub Jelinek wrote:
> On Wed, Jun 29, 2022 at 06:45:51AM +0200, Mohamed Atef wrote:
> > for this test case,
> >
> > 1.#include
> > 2.#include
> > 3.int
> > 4.main()
> > 5.{
> > 6. omp_set_num_threads (5);
> > 7. #pragma omp parallel
> > 8.{
> > 9. int th = omp_get_thread_num ();
> > 10. printf ("i am thread %d\n", th);
> > 11.}
> > 12. return 0;
> > 13.}
>
> You can also use OMP_DISPLAY_ENV=verbose in the environment
> to see how it is printed by the runtime.
>
> > Reading symbols from a.out...
> > OMPD GDB support loaded
> > Run 'ompd init' to start debugging
> > (gdb) ompd init
> > Temporary breakpoint 1 at 0x40115a: file pro.c, line 6.
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1".
> >
> > Temporary breakpoint 1, main () at pro.c:6
> > 6 omp_set_num_threads (5);
> > Loaded OMPD lib successfully!
>
> Is the GDB OMPD patch available somewhere?
>
No, this is the GDB plugin.
>
> > (gdb) b 10
> > Breakpoint 2 at 0x401198: file pro.c, line 10.
> > (gdb) c
> > Continuing.
> > [New Thread 0x77d45700 (LWP 116224)]
> > [New Thread 0x77544700 (LWP 116225)]
> > [New Thread 0x76d43700 (LWP 116226)]
> > [Switching to Thread 0x77d45700 (LWP 116224)]
> >
> > Thread 2 "a.out" hit Breakpoint -14, gomp_thread_start
> > (xdata=0x7fffd950) at ../../../gcc/libgomp/config/linux/sem.h:46
> > 46 *sem = value * SEM_INC;
> > [New Thread 0x76542700 (LWP 116227)]
> > [Switching to Thread 0x77544700 (LWP 116225)]
> >
> > Thread 3 "a.out" hit Breakpoint -14, gomp_thread_start
> > (xdata=0x7fffd9d0) at ../../../gcc/libgomp/config/linux/sem.h:46
> > 46 *sem = value * SEM_INC;
> > [Switching to Thread 0x76d43700 (LWP 116226)]
> >
> > Thread 4 "a.out" hit Breakpoint -14, gomp_thread_start
> > (xdata=0x7fffda50) at ../../../gcc/libgomp/config/linux/sem.h:46
> > 46 *sem = value * SEM_INC;
> > [Switching to Thread 0x76542700 (LWP 116227)]
> >
> > Thread 5 "a.out" hit Breakpoint -14, gomp_thread_start
> > (xdata=0x7fffdad0) at ../../../gcc/libgomp/config/linux/sem.h:46
> > 46 *sem = value * SEM_INC;
> >
> > Thread 5 "a.out" hit Breakpoint 2, main._omp_fn.0 () at pro.c:10
> > 10printf ("i am thread %d\n", th);
> > (gdb) bt
> > #0 main._omp_fn.0 () at pro.c:10
> > #1 0x77f9dd8e in gomp_thread_start (xdata=) at
> > ../../../gcc/libgomp/team.c:131
> > #2 0x77f48609 in start_thread (arg=) at
> > pthread_create.c:477
> > #3 0x77e6d133 in clone () at
> > ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> > (gdb) ompd icv
> > Initialized ICV map successfully for checking OMP API values.
> > ICVName Scope Value
> > ===
> > cancel var address_space 0
> > max task priority var address_space 0
> > stack size var address_space 0
> > debug var address_space 0
> > OMP_DEBUGaddress_space enabled
> > display affinity varaddress_space 0
> > affinity format var address_space level %L
> thread
> > %i affinity %A
>
> This ought to be IMHO printed as a string literal, so "level %L thread %i
> affinity %A"
>
> > affinity format len var address_space 0
> > wait policy var address_space 4294967295
> > num teams var address_space 0
> > teams thread limit var address_space 0
> > spin count var address_space 30
> > num proc varaddress_space 8
> > throttled spin count varaddress_space 100
> > managed threads var address_space 5
>
> And also, it would be nice if it was clear which ICVs are GCC
> implementation
> specific and which are standard (the spin count vars are non-standard).
> Also, the names of ICVs in the standard are with hyphens, so perhaps print
> cancel-var, max-task-priority-var etc.?
>
OK, I will fix it in the next patch.
>
> Jakub
>
>
[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (June 30, 2022)
Hi all, Here is the agenda for tomorrow's RISC-V GNU toolchain meeting. If you have any topics want to discuss or share, please let me know and I will add them to the agenda, thanks. Agenda: - RVV supports status RVV calling convention to aid lazy binding https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/296 RVV register 'vxrm/vxsat' calling convention https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/294 - RISC-V sub-extension supports status Zawrs ISA extension patches H-extension supported in binutils upstream Patches for zfinx update - Open topics Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting. Topic: RISC-V GNU Toolchain Biweekly Sync-up Time: June 30, 2022 11:00 PM Singapore Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://zoom.us/meeting/tZ0ufuqurjsjH9XTthkNg3MffX-QsRBuVBET/ics?icsToken=98tyKuGhrTIpHNSVuRyGRpx5A4r4b-7ziGJEgvplqAvtCA5UMS7wMNoPA6FNMs3m Join Zoom Meeting https://zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09 Meeting ID: 893 9360 0951 Passcode: 899662 BEIJING, China 11:00pThu, June 30 2022 12:00aFri, June 30 2022 PST/PDT, Pacific Standard Time (US) 8:00aThu, June 30 2022 9:00aThu, June 30 2022 PHILADELPHIA, United States, Pennsylvania 11:00aThu, June 30 2022 12:00aThu, June 30 2022 Paris, France 17:00pThu, June 30 2022 18:00pThu, June 30 2022BEGIN:VCALENDAR PRODID:-//zoom.us//iCalendar Event//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH CLASS:PUBLIC BEGIN:VTIMEZONE TZID:Asia/Singapore LAST-MODIFIED:20201011T015911Z TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Singapore X-LIC-LOCATION:Asia/Singapore BEGIN:STANDARD TZNAME:+08 TZOFFSETFROM:+0800 TZOFFSETTO:+0800 DTSTART:19700101T00 END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20220309T112636Z DTSTART;TZID=Asia/Singapore:20220310T23 DTEND;TZID=Asia/Singapore:20220311T00 SUMMARY:RISC-V GNU Toolchain Biweekly Sync-up RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20220630T16;INTERVAL=2;BYDAY=TH UID:ZOOM89393600951 TZID:Asia/Singapore DESCRIPTION:Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting .\n\nJoin Zoom Meeting\nhttps://us02web.zoom.us/j/89393600951?pwd=ZFpWMk Z6Tm1TbUFXT1hZZjZZMHhRQT09\n\nMeeting ID: 893 9360 0951\nPasscode: 89966 2\nOne tap mobile\n+6531651065\,\,89393600951#\,\,\,\,*899662# Singapore \n+6531587288\,\,89393600951#\,\,\,\,*899662# Singapore\n\nDial by your location\n+65 3165 1065 Singapore\n+65 3158 7288 Singapo re\n+1 669 900 9128 US (San Jose)\n+1 346 248 7799 US (H ouston)\n+1 253 215 8782 US (Tacoma)\n+1 312 626 6799 US (Chicago)\n+1 646 558 8656 US (New York)\n+1 301 715 85 92 US (Washington DC)\nMeeting ID: 893 9360 0951\nPasscode: 899662\nFind your local number: https://us02web.zoom.us/u/kk9cyIPNJ\n\n LOCATION:https://us02web.zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZj ZZMHhRQT09 BEGIN:VALARM TRIGGER:-PT10M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR
AArch64 vector ABI vs OpenMP
Last time aarch64 libmvec was discussed, the OpenMP
declare variant syntax support was not ready in gcc
and there were open questions around how simd isa
variants would be supported.
https://gcc.gnu.org/pipermail/gcc-patches/2019-October/532940.html
The vector function ABI for aarch64 allows the declare
variant syntax and that is the only way to declare
vector math functions for a particular isa only.
https://github.com/ARM-software/abi-aa/blob/main/vfabia64/vfabia64.rst#aarch64-variant-traits
I would like to get feedback if there may be anything
preventing declare variant simd support on aarch64 like
float64x2_t simd_cos (float64x2_t);
#pragma omp declare variant(simd_cos) \
match(construct={simd(simdlen(2), notinbranch)}, device={isa("simd")})
double cos (double);
where isa("simd") means simd_cos can be used when
auto vectorizing cos calls with advanced simd.
Our hope is that this enables libmvec on aarch64
such that at least advanced simd variants of
some math functions can be declared in math.h
and implemented in libm, suitable for vectorization.
(Using the vector ABI names of those functions.)
Eventually we want to add isa("sve") support too,
but that may require further work on how scalable
vector length is represented.
Please let me know if there are outstanding issues
with this approach.
thanks.
[PATCH v2] analyzer: add allocation size checker
Hi, I've addressed most of the points from the review. * The allocation size warning warns whenever region_model::get_capacity returns something useful, i.e. also on statically-allocated regions. * I added a new virtual function to the pending-diagnostic class, so that it is possible to emit a custom region creation description. * The test cases should have a better coverage now. * Conservative struct handling The warning now looks like this: /path/to/main.c:9:8: warning: allocated buffer size is not a multiple of the pointee's size [CWE-131] [-Wanalyzer-allocation-size] 9 | int *iptr = ptr; |^~~~ ‘main’: events 1-2 | |8 | void *ptr = malloc((long unsigned int)n * sizeof(short)); | | ^ | | | | | (1) allocated ‘(long unsigned int)n * 2’ bytes here |9 | int *iptr = ptr; | | | || | |(2) assigned to ‘int *’ here; ‘sizeof(int)’ is ‘4’ | /path/to/main.c:15:15: warning: allocated buffer size is not a multiple of the pointee's size [CWE-131] [-Wanalyzer-allocation-size] 15 | int *ptrw = malloc (sizeof (short)); | ^~~ ‘main’: events 1-2 | | 15 | int *ptrw = malloc (sizeof (short)); | | ^~~ | | | | | (1) allocated ‘2’ bytes here | | (2) assigned to ‘int *’ here; ‘sizeof (int)’ is ‘4’ | The only thing I couldn't address was moving the second event toward the lhs or assign token here. I tracked it down till get_stmt_location where it seems that the rhs is actually the location of the statement. Is there any way to get (2) to be focused on the lhs? Otherwise, the patch compiled coreutils, openssh, curl and httpd without any false-positive (but none of them contained a bug found by the checker either). `make check-gcc RUNTESTFLAGS="analyzer.exp"` tests pass and as I just worked on the event splitting, the regression tests are yet to run. - Tim This patch adds an checker that warns about code paths in which a buffer is assigned to a incompatible type, i.e. when the allocated buffer size is not a multiple of the pointee's size. gcc/analyzer/ChangeLog: * analyzer.opt: Added Wanalyzer-allocation-size. * checker-path.cc (region_creation_event::get_desc): Added call to new virtual function pending_diagnostic::describe_region_creation_event. * checker-path.h: Added region_creation_event::get_desc. * diagnostic-manager.cc (diagnostic_manager::add_event_on_final_node): New function. * diagnostic-manager.h: Added diagnostic_manager::add_event_on_final_node. * pending-diagnostic.h (struct region_creation): New event_desc struct. (pending_diagnostic::describe_region_creation_event): Added virtual function to overwrite description of a region creation. * region-model.cc (class dubious_allocation_size): New class. (capacity_compatible_with_type): New helper function. (class size_visitor): New class. (struct_or_union_with_inheritance_p): New helper function. (is_any_cast_p): New helper function. (region_model::check_region_size): New function. (region_model::set_value): Added call to region_model::check_region_size. * region-model.h (class region_model): New function check_region_size. * svalue.cc (region_svalue::accept): Changed to post-order traversal. (initial_svalue::accept): Likewise. (unaryop_svalue::accept): Likewise. (binop_svalue::accept): Likewise. (sub_svalue::accept): Likewise. (repeated_svalue::accept): Likewise. (bits_within_svalue::accept): Likewise. (widening_svalue::accept): Likewise. (unmergeable_svalue::accept): Likewise. (compound_svalue::accept): Likewise. (conjured_svalue::accept): Likewise. (asm_output_svalue::accept): Likewise. (const_fn_result_svalue::accept): Likewise. gcc/ChangeLog: * doc/invoke.texi: Added Wanalyzer-allocation-size. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/pr96639.c: Changed buffer size to omit warning. * gcc.dg/analyzer/allocation-size-1.c: New test. * gcc.dg/analyzer/allocation-size-2.c: New test. * gcc.dg/analyzer/allocation-size-3.c: New test. * gcc.dg/analyzer/allocation-size-4.c: New test. * gcc.dg/analyzer/allocation-size-5.c: New test. Signed-off-by: Tim Lange --- gcc/analyzer/analyzer.opt | 4 + gcc/analyzer/checker-path.cc | 11 +- gcc/analyzer/checker-path.h | 2 +- gcc/analyzer/diagnostic-manager.cc| 61 gcc/analyzer/diagnostic-manager.h | 4 + gcc/analyzer/pending-diagnostic.h
Re: [PATCH v2] analyzer: add allocation size checker
On Wed, 2022-06-29 at 17:39 +0200, Tim Lange wrote: > Hi, Thanks for the updated patch. Overall, looks nearly ready; various nits inline below, throughout... > > I've addressed most of the points from the review. > * The allocation size warning warns whenever region_model::get_capacity > returns > something useful, i.e. also on statically-allocated regions. Thanks. Looks like you added test coverage for this in allocation- size-5.c > * I added a new virtual function to the pending-diagnostic class, so that it > is possible to emit a custom region creation description. > * The test cases should have a better coverage now. > * Conservative struct handling > > The warning now looks like this: > /path/to/main.c:9:8: warning: allocated buffer size is not a multiple of the > pointee's size [CWE-131] [-Wanalyzer-allocation-size] > 9 | int *iptr = ptr; > |^~~~ > ‘main’: events 1-2 > | > |8 | void *ptr = malloc((long unsigned int)n * sizeof(short)); > | | ^ > | | | > | | (1) allocated ‘(long unsigned int)n * 2’ bytes here > |9 | int *iptr = ptr; > | | > | || > | |(2) assigned to ‘int *’ here; ‘sizeof(int)’ is ‘4’ > | Looks great. > > /path/to/main.c:15:15: warning: allocated buffer size is not a multiple of > the pointee's size [CWE-131] [-Wanalyzer-allocation-size] >15 | int *ptrw = malloc (sizeof (short)); > | ^~~ > ‘main’: events 1-2 > | > | 15 | int *ptrw = malloc (sizeof (short)); > | | ^~~ > | | | > | | (1) allocated ‘2’ bytes here Looks a bit weird to be quoting a number here; maybe whenever the expression is just a constant, print it unquoted? (though that could be fiddly to implement, so can be ignored if it turns out to be) . > | | (2) assigned to ‘int *’ here; ‘sizeof (int)’ is ‘4’ > | > The only thing I couldn't address was moving the second event toward the lhs > or > assign token here. I tracked it down till get_stmt_location where it seems > that > the rhs is actually the location of the statement. Is there any way to get (2) > to be focused on the lhs? Annoyingly, we've lost a lot of location information by the time the analyzer runs. In theory we could special-case for when we have the def-stmt of the SSA_NAME that's that default (i.e. initial) value of a VAR_DECL, and if we see the write is there, we could use the DECL_SOUCE_LOCATION of the VAR_DECL for the write, so that we'd get: | 15 | int *ptrw = malloc (sizeof (short)); | |^~~~ ^~~ | || | | || (1) allocated ‘2’ bytes here | |(2) assigned to ‘int *’ here; ‘sizeof (int)’ is ‘4’ | which is perhaps slightly more readable. I'm not sure it's worth it though. > > Otherwise, the patch compiled coreutils, openssh, curl and httpd without any > false-positive (but none of them contained a bug found by the checker either). Great. > `make check-gcc RUNTESTFLAGS="analyzer.exp"` tests pass and as I just worked > on > the event splitting, the regression tests are yet to run. > > - Tim > > > This patch adds an checker that warns about code paths in which a buffer is > assigned to a incompatible type, i.e. when the allocated buffer size is not a > multiple of the pointee's size. > > gcc/analyzer/ChangeLog: You should add a reference to the RFE bug to the top of the ChangeLog entries: PR analyzer/105900 Please also add it to the commit message, in the form " [PR105900]"; see the examples section twoards the end of https://gcc.gnu.org/contribute.html#patches > > * analyzer.opt: Added Wanalyzer-allocation-size. [...snip...] > > gcc/ChangeLog: ...and here > > * doc/invoke.texi: Added Wanalyzer-allocation-size. > > gcc/testsuite/ChangeLog: ...and here > > * gcc.dg/analyzer/pr96639.c: Changed buffer size to omit warning. > * gcc.dg/analyzer/allocation-size-1.c: New test. > * gcc.dg/analyzer/allocation-size-2.c: New test. > * gcc.dg/analyzer/allocation-size-3.c: New test. > * gcc.dg/analyzer/allocation-size-4.c: New test. > * gcc.dg/analyzer/allocation-size-5.c: New test. > > Signed-off-by: Tim Lange [...snip...] > diff --git a/gcc/analyzer/analyzer.opt b/gcc/analyzer/analyzer.opt > index 4aea52d3a87..912def2faf2 100644 > --- a/gcc/analyzer/analyzer.opt > +++ b/gcc/analyzer/analyzer.opt > @@ -54,6 +54,10 @@ The minimum number of supernodes within a function for the > analyzer to consider > Common Joined UInteger Var(param_analyzer_max_enodes_for_full_dump) > Init(200) Param > The maximum depth of exploded nodes that should appear in a dot dump before > swi
