A plugin for -ftime-trace like tracing in GCC
There were some discussions here about -ftime-trace. I've written a GCC plugin with similar functionality last year: https://github.com/royjacobson/externis. It works at least on GCC11 and GCC12. It was written by practically reverse engineering the GCC AST and can only make use of the GCC plugin callbacks, which are very limited, so the information it provides is sometimes inaccurate and heuristic. But maybe it can help by providing something to iterate on. Cheers, Roy
Re: [GSoC] Help needed for building on aarch64-apple-darwin22.1.0
Greetings, Iaian. On 2023-02-20 12:42, Iain Sandoe wrote: Hi Shengyu, On 20 Feb 2023, at 17:31, Shengyu Huang via Gcc wrote: After following the instructions here (https://gcc.gnu.org/wiki/InstallingGCC) and here (https://gcc.gnu.org/install/index.html), the `make` step simply fails with “*** Configuration aarch64-apple-darwin22.1.0 not supported”. I found this issue on Bugzilla (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168), but the status says it’s suspended. Does it mean there is no way I can build from source on my new laptop? My old MBP was unfortunately broken two months ago, so the new laptop with Apple M2 is the only device I have at the moment. I have a development branch for trunk here : https://github.com/iains/gcc-darwin-arm64 This is wonderful -- thank you for doing this! I am not interested in gfortran but rather gm2 and your branch for the trunk works quite well. Sincerely, john and for GCC-12 here: https://github.com/iains/gcc-12-branch until I have some time to upstream the work (which could not be before GCC-14, I think) you can use these. HTH, Iain
[GSoC][Static Analyzer] Some questions and request for a small patch to work on
Dear all, I want to work on the Static Analyzer project and just started to read the documentation these days, but what’s mentioned in 27.1.6 in the internal document (https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html#Analyzer-Internals) seems outdated or not detailed enough. For example, I didn’t find any “TODO/xfail” in the testsuite. Some points sound very interesting to me (specifically, 1) adding function pointer analysis, 2) assumption of reflexivity of constraint-handling, 3) expensive implementation of transitivity in constraint_manager), and I would like to look into these three points if you believe they can be converted into a valid GSoC project. Could you give me more details regarding these three points? In addition, would there be anything related and simple enough that I can work on before the application period? Best, Shengyu
Re: [GSoC][Static Analyzer] Some questions and request for a small patch to work on
On Tue, 2023-02-21 at 22:26 +0100, Shengyu Huang via Gcc wrote:
> Dear all,
Hi Shengyu, and welcome.
>
> I want to work on the Static Analyzer project and just started to
> read the documentation these days,
Excellent! I'm the author/maintainer of the analyzer, so I would
mentor any such GSoC project.
> but what’s mentioned in 27.1.6 in the internal document
> (https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html#Analyz
> er-Internals) seems outdated or not detailed enough.
Yeah, that section is rather out of date. Sorry about that.
We now have some function pointer analysis (thanks to Ankur Saini's
GSoC 2021 project).
> For example, I didn’t find any “TODO/xfail” in the testsuite.
Sorry, when it says "grep for TODO/xfail in the testsuite" I really
meant grep for "TODO" or for "xfail" in the testsuite.
But a better place to look would probably be in our bugzilla; see the
links on the wiki page:
https://gcc.gnu.org/wiki/StaticAnalyzer
The "open bugs" list currently has 41 "RFE" bugs ("request for
enhancement" i.e. ideas for new features), some of which might make
suitable GSoC ideas, and/or be of interest to you (ideally both!)
Also, the GSoC wiki page has some project ideas:
https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas
> Some points sound very interesting to me (specifically, 1) adding
> function pointer analysis,
> 2) assumption of reflexivity of constraint-handling, 3) expensive
> implementation of transitivity in constraint_manager), and I would
> like to look into these three points if you believe they can be
> converted into a valid GSoC project. Could you give me more details
> regarding these three points?
I believe that (2) and (3) are still true, but I don't think they'd
make good GSoC projects; I think the stuff in bugzilla is much more
interesting and higher priority.
>
> In addition, would there be anything related and simple enough that I
> can work on before the application period?
If you haven't seen it yet, you might find my guide to GCC for new
contributors helpful:
https://gcc-newbies-guide.readthedocs.io/en/latest/index.html
IIRC I saw you post a few days ago about trying to build gcc on your M2
laptop; did you manage this? Building GCC trunk from a git checkout,
and hacking in a "hello world" warning would be a great place to start.
See the guide above for some hints on how to make this process quicker,
and let me know if you need help if you run into difficulties. Given
that the analyzer is about emitting warnings, rather than generating
code, it may be that although we don't yet fully support your hardware,
we *might* already support it enough to allow for hacking on the
analyzer, perhaps with some judicious choices of "configure" options.
Hope this is helpful; welcome again.
Dave
>
> Best,
> Shengyu
>
[RISC-V] built-in atomic function implementation involving RISC-V memory model
Hi,
As stated in the comments of riscv_print_operand (the latest version of
gcc/config/riscv/riscv.cc), the RISCV-specific operand code 'A', which is used
in the implementation of 'atomic_cas_value_strong' in sync.md, is the atomic
operation suffix for memory model OP.
However, only '.aq' is considered in the current implementation:
case 'A':
if (riscv_memmodel_needs_amo_acquire ((enum memmodel) INTVAL (op)))
fputs (".aq", file);
break;
Currently, we cannot add '.rl' to the function like
atomic_compare_exchange_weak_release in glibc.
I think we should also take '.rl' & '.aqrl' into consideration. The correct
implementation in my understanding should be:
case 'A':
if (riscv_memmodel_needs_amo_acquire_release ((enum memmodel) INTVAL (op)))
fputs (".aqrl", file);
else if (riscv_memmodel_needs_amo_acquire ((enum memmodel) INTVAL (op)))
fputs (".aq", file);
else if (riscv_memmodel_needs_amo_release ((enum memmodel) INTVAL (op)))
fputs (".rl", file);
break;
Did I get it wrong? I'd appreciate it if you could explain it for me.
Thanks
Xuezheng
