Re: Query status of GSoC project: CPyChecker
Hi Eric, > Thanks for reaching out. The project is still in very early stages. So > far we have taught the analyzer the basic behavior for > PyLong_FromLong, PyList_New, and Py_DECREF via known function > subclassing. Additionally, Py_INCREF is supported out of the box. > Reference count checking functionality remains the priority, but it is > not yet fully implemented. Great! > Regarding CPython versions, the goal is to just get things working on > one version first. I arbitrarily picked 3.9, but happy to consider > another version as an initial goal if it’s more helpful to the CPython > community. I am not sure about this. cpychecker is more beneficial to CPython extension devs than to CPython devs, since it is almost impossible to let the cpychecker learn the most updated internal function definitions without handwritten attributes or seeing the whole function definitions. So it depends on the extension maintainer. I am observing this pattern that popular libraries are gradually upgrading. 3.9 and 3.10 is definitely the current mainstream. Saying so, I think 3.9 is fine for now, but it will be outdated after 2 to 3 years. Best, Steven
Re: types in GIMPLE IR
On Thu, 29 Jun 2023, Richard Biener wrote: The thing with signed bools is that the two relevant values are -1 (true) and 0 (false), those are used for vector bool components where we also need them to be of wider type (32bits in this case). My main confusion comes from seeing IR doing arithmetic such as _127; _169; ... _169 = _127 + -1; or _127; _169; ... _169 = -_127; and it was unclear to me what kind of arithmetic is allowed. I have now verified that all cases seems to be just one operation of this form (where _127 has the value 0 or 1), so it cannot construct values such as 42. But the wide signed Boolean can have the three different values 1, 0, and -1, which I still think is at least one too many. :) I'll update my tool to complain if the value is outside the range [-1, 1]. /Krister
Re: types in GIMPLE IR
Hello, On Thu, 29 Jun 2023, Krister Walfridsson wrote: > > The thing with signed bools is that the two relevant values are -1 (true) > > and 0 (false), those are used for vector bool components where we also > > need them to be of wider type (32bits in this case). > > My main confusion comes from seeing IR doing arithmetic such as > >_127; >_169; > ... > _169 = _127 + -1; > > or > >_127; >_169; > ... > _169 = -_127; > > and it was unclear to me what kind of arithmetic is allowed. > > I have now verified that all cases seems to be just one operation of this form > (where _127 has the value 0 or 1), so it cannot construct values such as 42. > But the wide signed Boolean can have the three different values 1, 0, and -1, > which I still think is at least one too many. :) It definitely is. For signed bool it should be -1 and 0, for unsigned bool 1 and 0. And of course, arithmetic on bools is always dubious, that should all be logical operations. Modulo-arithmetic (mod 2) could be made to work, but then we would have to give up the idea of signed bools and always use conversions to signed int to get a bitmaks of all-ones. And as mod-2-arithmetic is equivalent to logical ops it seems a bit futile to go that way. Of course, enforcing this all might lead to a surprising heap of errors, but one has to start somewhere, so ... > I'll update my tool to complain if the value is outside the range [-1, > 1]. ... maybe not do that, at least optionally, that maybe somewhen someone can look into fixing that all up? :-) -fdubious-bools? Ciao, Michael.
Re: types in GIMPLE IR
On Thu, Jun 29, 2023 at 2:06 PM Krister Walfridsson wrote: > > On Thu, 29 Jun 2023, Richard Biener wrote: > > > The thing with signed bools is that the two relevant values are -1 (true) > > and 0 (false), those are used for vector bool components where we also > > need them to be of wider type (32bits in this case). > > My main confusion comes from seeing IR doing arithmetic such as > > _127; > _169; >... >_169 = _127 + -1; > > or > > _127; > _169; >... >_169 = -_127; > > and it was unclear to me what kind of arithmetic is allowed. IIRC we have some simplification rules that turn bit operations into arithmetics. Arithmetic is allowed if it keeps the values inside [-1,0] for signed bools or [0, 1] for unsigned bools. > I have now verified that all cases seems to be just one operation of this > form (where _127 has the value 0 or 1), so it cannot construct values > such as 42. But the wide signed Boolean can have the three different > values 1, 0, and -1, which I still think is at least one too many. :) Yeah, I'd be interested in a testcase that shows this behavior. Richard. > I'll update my tool to complain if the value is outside the range [-1, 1]. > >/Krister
Re: [PATCH] Basic asm blocks should always be volatile
Hello,
On Thu, 29 Jun 2023, Julian Waters via Gcc wrote:
> int main() {
> asm ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
>
> asm volatile ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
> }
>
> objdump --disassemble-all -M intel -M intel-mnemonic a.exe > disassembly.txt
>
> 0001400028c0 :
>1400028c0: 48 83 ec 28 subrsp,0x28
>1400028c4: e8 37 ec ff ffcall 140001500 <__main>
>1400028c9: 90nop
>1400028ca: 90nop
>1400028cb: 90nop
>1400028cc: 31 c0 xoreax,eax
>1400028cd: 48 83 c4 28 addrsp,0x28
>1400028ce: c3ret
>
> Note how there are only 3 nops above when there should be 6, as the first 3
> have been deleted by the compiler. With the patch, the correct 6 nops
> instead of 3 are compiled into the final code.
>
> Of course, the above was compiled with the most extreme optimizations
> available to stress test the possible bug, -O3, -ffunction-sections
> -fdata-sections -Wl,--gc-sections -flto=auto. Compiled as C++17 and intel
> assembly syntax
Works just fine here:
% cat xx.c
int main() {
asm ("nop" "\n"
"\t" "nop" "\n"
"\t" "nop");
asm volatile ("nop" "\n"
"\t" "nop" "\n"
"\t" "nop");
}
% g++ -v
...
gcc version 12.2.1 20230124 [revision
193f7e62815b4089dfaed4c2bd34fd4f10209e27] (SUSE Linux)
% g++ -std=c++17 -flto=auto -O3 -ffunction-sections -fdata-sections xx.c
% objdump --disassemble-all -M intel -M intel-mnemonic a.out
...
00401020 :
401020: 90 nop
401021: 90 nop
401022: 90 nop
401023: 90 nop
401024: 90 nop
401025: 90 nop
401026: 31 c0 xoreax,eax
401028: c3 ret
401029: 0f 1f 80 00 00 00 00nopDWORD PTR [rax+0x0]
...
Testing with recent trunk works as well with no differences in output.
This is for x86_64-linux.
So, as suspected, something else is broken for you. Which compiler
version are you using? (And we need to check if it's something in the
mingw target)
Ciao,
Michael.
Re: types in GIMPLE IR
On Thu, 29 Jun 2023, Richard Biener wrote: IIRC we have some simplification rules that turn bit operations into arithmetics. Arithmetic is allowed if it keeps the values inside [-1,0] for signed bools or [0, 1] for unsigned bools. I have now verified that all cases seems to be just one operation of this form (where _127 has the value 0 or 1), so it cannot construct values such as 42. But the wide signed Boolean can have the three different values 1, 0, and -1, which I still think is at least one too many. :) Yeah, I'd be interested in a testcase that shows this behavior. I created PR 110487 with one example. I'll update my tool to complain if the value is outside the range [-1, 1]. It is likely that all issues I have seen so far are due to PR 110487, so I'll keep the current behavior that complains if the value is outside the range [-1, 0]. /Krister
Re: types in GIMPLE IR
On Thu, Jun 29, 2023 at 12:10 PM Krister Walfridsson via Gcc wrote: > > On Thu, 29 Jun 2023, Richard Biener wrote: > > > IIRC we have some simplification rules that turn bit operations into > > arithmetics. Arithmetic is allowed if it keeps the values inside > > [-1,0] for signed bools or [0, 1] for unsigned bools. > > > >> I have now verified that all cases seems to be just one operation of this > >> form (where _127 has the value 0 or 1), so it cannot construct values > >> such as 42. But the wide signed Boolean can have the three different > >> values 1, 0, and -1, which I still think is at least one too many. :) > > > > Yeah, I'd be interested in a testcase that shows this behavior. > > I created PR 110487 with one example. > > > >> I'll update my tool to complain if the value is outside the range [-1, 1]. > > It is likely that all issues I have seen so far are due to PR 110487, so > I'll keep the current behavior that complains if the value is outside the > range [-1, 0]. Yes there are many similar to this all over GCC's folding. In this case checking TYPE_PRECISION as described in the match.pd is not even the right approach. The whole TYPE_PRECISION on boolean types is definitely a big can of worms. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622 is related but that was signed boolean:1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106053 is another related case. For this weekend, I am going to audit some of the match patterns for these issues. > > /Krister
gcc-11-20230629 is now available
Snapshot gcc-11-20230629 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20230629/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 22e5d295199714f9fcebe970e3e8c29c204d30a6 You'll find: gcc-11-20230629.tar.xz Complete GCC SHA256=ddf79dab57bbba4a36e034dcd25cc5b26a1bd6009c51a7b2ad962d6472779f97 SHA1=aba12782d01d44b7ee2dfe364077c1bb03326b5c Diffs from 11-20230622 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Inquiry about Getting Started with GCC Projects as a Beginner
Dear GCC Company, I hope this email finds you well. I am writing to express my interest in working on GCC projects as a beginner and seeking guidance on how to get started. I am excited about the opportunity to contribute to your projects and gain valuable experience in the process. As a beginner, I understand that I might need to acquire certain skills, languages, frameworks, and tools to effectively participate in GCC projects. I would greatly appreciate it if you could provide me with some information on the following aspects: 1. Programming Languages: Which programming languages are commonly used in GCC projects? Are there any specific languages that you recommend beginners to focus on initially? 2. Frameworks: Are there any frameworks that are commonly utilized in GCC projects? If so, could you suggest any specific frameworks that beginners should become familiar with? 3. Tools: What are the essential tools utilized in GCC projects? It would be helpful to know which tools are commonly used for tasks such as version control, project management, documentation, and testing. 4. Learning Resources: Could you please recommend any online resources, tutorials, or documentation that can assist beginners in understanding GCC projects and the associated technologies? I understand that getting started with any new project can be challenging, but I am enthusiastic and committed to expanding my knowledge and skills to contribute effectively. Any guidance or suggestions you can provide would be greatly appreciated. Thank you for your time and consideration. I look forward to hearing from you and beginning my journey with GCC projects. Yours sincerely, Vatsalya Dubey
Re: [PATCH] Basic asm blocks should always be volatile
Hi Michael,
I'm on gcc 13.1 compiling for Windows x64, with the MinGW UCRT64 runtime
library
best regards,
Julian
On Thu, Jun 29, 2023 at 9:27 PM Michael Matz wrote:
> Hello,
>
> On Thu, 29 Jun 2023, Julian Waters via Gcc wrote:
>
> > int main() {
> > asm ("nop" "\n"
> > "\t" "nop" "\n"
> > "\t" "nop");
> >
> > asm volatile ("nop" "\n"
> > "\t" "nop" "\n"
> > "\t" "nop");
> > }
> >
> > objdump --disassemble-all -M intel -M intel-mnemonic a.exe >
> disassembly.txt
> >
> > 0001400028c0 :
> >1400028c0: 48 83 ec 28 subrsp,0x28
> >1400028c4: e8 37 ec ff ffcall 140001500 <__main>
> >1400028c9: 90nop
> >1400028ca: 90nop
> >1400028cb: 90nop
> >1400028cc: 31 c0 xoreax,eax
> >1400028cd: 48 83 c4 28 addrsp,0x28
> >1400028ce: c3ret
> >
> > Note how there are only 3 nops above when there should be 6, as the
> first 3
> > have been deleted by the compiler. With the patch, the correct 6 nops
> > instead of 3 are compiled into the final code.
> >
> > Of course, the above was compiled with the most extreme optimizations
> > available to stress test the possible bug, -O3, -ffunction-sections
> > -fdata-sections -Wl,--gc-sections -flto=auto. Compiled as C++17 and intel
> > assembly syntax
>
> Works just fine here:
>
> % cat xx.c
> int main() {
> asm ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
>
> asm volatile ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
> }
>
> % g++ -v
> ...
> gcc version 12.2.1 20230124 [revision
> 193f7e62815b4089dfaed4c2bd34fd4f10209e27] (SUSE Linux)
>
> % g++ -std=c++17 -flto=auto -O3 -ffunction-sections -fdata-sections xx.c
> % objdump --disassemble-all -M intel -M intel-mnemonic a.out
> ...
> 00401020 :
> 401020: 90 nop
> 401021: 90 nop
> 401022: 90 nop
> 401023: 90 nop
> 401024: 90 nop
> 401025: 90 nop
> 401026: 31 c0 xoreax,eax
> 401028: c3 ret
> 401029: 0f 1f 80 00 00 00 00nopDWORD PTR [rax+0x0]
> ...
>
> Testing with recent trunk works as well with no differences in output.
> This is for x86_64-linux.
>
> So, as suspected, something else is broken for you. Which compiler
> version are you using? (And we need to check if it's something in the
> mingw target)
>
>
> Ciao,
> Michael.
>
GCC 10.4.1 Status Report (2023-06-30), branch frozen for release
Status == The gcc-10 branch is frozen for release and closing. All changes require release manager approval. Previous Report === https://gcc.gnu.org/pipermail/gcc/2023-June/241839.html
