Re: RFC: Formalization of the Intel assembly syntax (PR53929)
On 23.01.2024 02:27, LIU Hao wrote:
> 在 2024-01-22 16:39, Jan Beulich 写道:
>> Right, I did some work in that direction a while ago. But iirc there are
>> still cases left to be addressed.
>
> Attached is a draft patch for GCC, bootstrapped on {i686,x86_64}-w64-mingw32
> with GCC 13.2 and
> binutils 2.41.0.
Right, but this is very "draft". You can't blindly assume the gas you use
actually can deal with quotation.
> This addresses the issue when a bad name exists in the same translation unit.
> In the case of an
> external symbol there's still an error:
>
> ```
> extern int bx;
> int get(const char* p) { return p[bx]; }
> ```
>
> ```
> lh_mouse@lhmouse-pc ~/Desktop $ x86_64-w64-mingw32-gcc -S -o - -masm=intel
> test.c | fgrep bx
> mov rax, QWORD PTR .refptr.bx[rip]
> .section.rdata$.refptr.bx, "dr"
> .globl .refptr.bx
> .refptr.bx:
> .quad bx
Sure, this one needs quoting then, too.
Jan
> lh_mouse@lhmouse-pc ~/Desktop $ x86_64-w64-mingw32-gcc -masm=intel test.c |
> fgrep bx
> C:\Users\lh_mouse\AppData\Local\Temp\ccuyuu6c.s: Assembler messages:
> C:\Users\lh_mouse\AppData\Local\Temp\ccuyuu6c.s:29: Error: invalid use of
> register
> C:\Users\lh_mouse\AppData\Local\Temp\ccuyuu6c.s:29: Warning: register value
> used as expression
> lh_mouse@lhmouse-pc ~/Desktop $
> ```
>
>
>
>
Re: RFC: Formalization of the Intel assembly syntax (PR53929)
在 2024-01-23 16:38, Jan Beulich 写道: Right, but this is very "draft". You can't blindly assume the gas you use actually can deal with quotation. Let's assume that for the time being, but there's something else; see below. .refptr.bx: .quad bx Sure, this one needs quoting then, too. The attached patch contains `&& name[0] != '*'` with a reason: In the function `assemble_name_raw` in 'gcc/varasm.cc', if `name` starts with a `*`, then its remaining part is output without decoration. I have no idea what `*` means; this `.quad bx` thing apparently results from something like assemble_name_raw (file, "*bx"); Quoting this would break the i686 DWARF2 code, which may contain an arithmetic expression like .long LXXYY-1# "LXXYY" minus one If it was quoted like `.long "LXXYY-1"`, it would mean something very different and cause linker errors. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature
Re: RFC: Formalization of the Intel assembly syntax (PR53929)
On 23.01.2024 10:00, LIU Hao wrote: > 在 2024-01-23 16:38, Jan Beulich 写道: >> Right, but this is very "draft". You can't blindly assume the gas you use >> actually can deal with quotation. > > Let's assume that for the time being, but there's something else; see below. > > >>> .refptr.bx: >>> .quad bx >> >> Sure, this one needs quoting then, too. > > The attached patch contains `&& name[0] != '*'` with a reason: In the > function `assemble_name_raw` > in 'gcc/varasm.cc', if `name` starts with a `*`, then its remaining part is > output without > decoration. I have no idea what `*` means; this `.quad bx` thing apparently > results from something like > > assemble_name_raw (file, "*bx"); > > Quoting this would break the i686 DWARF2 code, which may contain an > arithmetic expression like > > .long LXXYY-1# "LXXYY" minus one > > If it was quoted like `.long "LXXYY-1"`, it would mean something very > different and cause linker errors. Hmm, that would suggest to me that the Dwarf code abuses the interface. A "name" certainly shouldn't be an expression. And hence the result of the example ought to be .long "LXXYY"-1# "LXXYY" minus one Jan
Re: RFC: Formalization of the Intel assembly syntax (PR53929)
在 2024-01-23 17:03, Jan Beulich 写道: Hmm, that would suggest to me that the Dwarf code abuses the interface. A "name" certainly shouldn't be an expression. And hence the result of the example ought to be .long "LXXYY"-1# "LXXYY" minus one So I shouldn't have checked for `*` right? The calls to `output_addr_const()` are from `dw2_assemble_integer (int size, rtx x)` in 'gcc/dwarf2asm.cc'. Now I need some directives on how to fix this; parsing the symbol seems awkward. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature
Re: RFC: Formalization of the Intel assembly syntax (PR53929)
On 23.01.2024 10:21, LIU Hao wrote: > 在 2024-01-23 17:03, Jan Beulich 写道: >> Hmm, that would suggest to me that the Dwarf code abuses the interface. >> A "name" certainly shouldn't be an expression. And hence the result of >> the example ought to be >> >> .long "LXXYY"-1# "LXXYY" minus one > > So I shouldn't have checked for `*` right? I don't know. > The calls to `output_addr_const()` are from `dw2_assemble_integer (int size, > rtx x)` in > 'gcc/dwarf2asm.cc'. Now I need some directives on how to fix this; parsing > the symbol seems awkward. Indeed. Jan
Mystery instructions
Hi The GNU assembler supports two instructions for the T-Head risk machines called: th.ipop th.ipush With no arguments. These instructions (they are no macros or aliases) are UNDOCUMENTED in the T-Head instruction manuals that I have, and a google search yields absolutely nothing. Can anyone here point me to some documentation that describes what these instructions do? Thanks in advance.
Re: Mystery instructions
Hi, These instructions looks to be part of the T-head vendor extension instruction set. With the spec here https://github.com/T-head-Semi/thead-extension-spec. Best regards Alex > On Jan 23, 2024, at 8:42 AM, jacob navia via Gcc wrote: > > Hi > The GNU assembler supports two instructions for the T-Head risk machines > called: > > th.ipop > th.ipush > > With no arguments. These instructions (they are no macros or aliases) are > UNDOCUMENTED in the T-Head instruction manuals that I have, and a google > search yields absolutely nothing. > > Can anyone here point me to some documentation that describes what these > instructions do? > > Thanks in advance.
Re: GCC Decimal128 class
On Tue, 23 Jan 2024 at 02:01, Ming Cheng via Gcc wrote:
>
> Hi GCC,
>
> Seems Janis is not at IBM. Wondering someone from GCC can help my question?
>
> Thanks
> Ming.
>
> From: Ming Cheng
> Sent: Monday, January 22, 2024 3:18 PM
> To: janis...@us.ibm.com
> Subject: GCC Decimal128 class
>
> Hi Janis Johnson,
>
> I want to test GCC Decimal128 class.
>
> This is my code:
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include "decimal/decimal.h"
>
> int main (void)
> {
> std::decimal::decimal128 d128{};
> return 0;
> }
>
> When I compile by c++23 (/opt/rh/gcc-toolset-13/root/bin/g++ -rdynamic
> -std=c++23 -O2 ..)
> I got this error:
>
> /opt/rh/gcc-toolset-13/root/usr/include/c++/13/decimal/decimal.h:46:10:
> error: 'decimal32' does not name a type
>46 | inline decimal32::decimal32(decimal64 __r):
> __val(__r.__getval()) {}
>
> I checked /opt/rh/gcc-toolset-13/root/usr/include/c++/13/decimal/decimal.h
> and found this comments:
>
> /** @file decimal/decimal.h
> * This is an internal header file, included by other library headers.
> * Do not attempt to use it directly. @headername{decimal}
> */
>
> Wondering whether you can give some advice?
Like it says, you don't include
You want instead. That works fine.
Re: GCC Decimal128 class
On Tue, 23 Jan 2024 at 14:16, Jonathan Wakely wrote:
>
> On Tue, 23 Jan 2024 at 02:01, Ming Cheng via Gcc wrote:
> >
> > Hi GCC,
> >
> > Seems Janis is not at IBM. Wondering someone from GCC can help my question?
> >
> > Thanks
> > Ming.
> >
> > From: Ming Cheng
> > Sent: Monday, January 22, 2024 3:18 PM
> > To: janis...@us.ibm.com
> > Subject: GCC Decimal128 class
> >
> > Hi Janis Johnson,
> >
> > I want to test GCC Decimal128 class.
> >
> > This is my code:
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include "decimal/decimal.h"
> >
> > int main (void)
> > {
> > std::decimal::decimal128 d128{};
> > return 0;
> > }
> >
> > When I compile by c++23 (/opt/rh/gcc-toolset-13/root/bin/g++ -rdynamic
> > -std=c++23 -O2 ..)
> > I got this error:
> >
> > /opt/rh/gcc-toolset-13/root/usr/include/c++/13/decimal/decimal.h:46:10:
> > error: 'decimal32' does not name a type
> >46 | inline decimal32::decimal32(decimal64 __r):
> > __val(__r.__getval()) {}
> >
> > I checked /opt/rh/gcc-toolset-13/root/usr/include/c++/13/decimal/decimal.h
> > and found this comments:
> >
> > /** @file decimal/decimal.h
> > * This is an internal header file, included by other library headers.
> > * Do not attempt to use it directly. @headername{decimal}
> > */
> >
> > Wondering whether you can give some advice?
>
>
> Like it says, you don't include
>
> You want instead. That works fine.
This is documented at:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_headers.html#table.decfp_headers
Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls
Am 03.01.2024 um 00:12 schrieb Björn Schäpers: Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: From: Björn Schäpers Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except that libraries loaded after the backtrace_initialize are not handled. But as far as I can see that's the same for elf. Thanks, but I don't want a patch that loops using goto statements. Please rewrite to avoid that. It may be simpler to call a function. Also starting with a module count of 1000 seems like a lot. Do typical Windows programs load that many modules? Ian Rewritten using a function. If that is commited, could you attribute that commit to me (--author="Björn Schäpers ")? Thanks and kind regards, Björn. A friendly ping.
Re: GSoc Topics
Hello, We are delighted you found contributing to GCC interesting. GCC has applied to be part of GSoC 2024 but of course selected organizations have not been announced yet. On Fri, Jan 12 2024, Gaurang Aswal via Gcc wrote: > Hey I am Gaurang Aswal a 4th year B.E. Computer Science student from BITS > Goa, India and wanted some info and insights on the Fortran projects and I > am interested in working on them. While the list of suggested projects at https://gcc.gnu.org/wiki/SummerOfCode is undergoing review for 2024, I think the Fortran ones will not change much. Please look over them, try to figure out what they would entail and which you'd like best. In this reply I have also CCed the Fortran mailing list, people there might help you decide which Fortan project would be the best for you. > I have basic knowledge of C/C++ and I > have completed my basic computer science courses in the same language, > which included Object Oriented Programming, Data Structures and Algorithms, > Computer Architecture and Operating Systems. I would like to keep in touch > and want to know how to proceed working on the topics. Contributing to the compiler also requires some rudimentary theoretical background in compilers, at the very least understanding of the concept of Intermediate Representation (IR), often also called Intermediate Language (IL). Googling either of the two terms should help you to find a lot of material to familiarize yourself with it. Please also look again at the "Before you apply" section of the idea page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you are able to build, install and test GCC and then have it generate dumps and step through some function during compilation. Also, feel free to ask for help here with any specific GCC development issues you may encounter. Good luck, Martin
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: > > Am 03.01.2024 um 00:12 schrieb Björn Schäpers: > > Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: > >> On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: > >>> > >>> From: Björn Schäpers > >>> > >>> Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except > >>> that libraries loaded after the backtrace_initialize are not handled. > >>> But as far as I can see that's the same for elf. > >> > >> Thanks, but I don't want a patch that loops using goto statements. > >> Please rewrite to avoid that. It may be simpler to call a function. > >> > >> Also starting with a module count of 1000 seems like a lot. Do > >> typical Windows programs load that many modules? > >> > >> Ian > >> > >> > > > > Rewritten using a function. > > > > If that is commited, could you attribute that commit to me (--author="Björn > > Schäpers ")? > > > > Thanks and kind regards, > > Björn. > > I noticed that under 64 bit libraries loaded with LoadLibrary were missing. > EnumProcessModules stated the correct number of modules, but did not fill the > the HMODULEs, but set them to 0. While trying to investigate I noticed if I do > the very same thing from main (in C++) I even got fewer module HMODULEs. > > So I went a different way. This detects all libraries correctly, in 32 and 64 > bit. The question is, if it should be a patch on top of the previous, or > should > they be merged, or even only this solution and drop the EnumProcessModules > variant? Is there any reason to use both patches? Seems simpler to just use this one if it works. Thanks. Ian
Re: GSoc Topics
Thanks, I'll check them out. On Wed, 24 Jan, 2024, 03:52 Martin Jambor, wrote: > Hello, > > We are delighted you found contributing to GCC interesting. GCC has > applied to be part of GSoC 2024 but of course selected organizations > have not been announced yet. > > On Fri, Jan 12 2024, Gaurang Aswal via Gcc wrote: > > Hey I am Gaurang Aswal a 4th year B.E. Computer Science student from BITS > > Goa, India and wanted some info and insights on the Fortran projects and > I > > am interested in working on them. > > While the list of suggested projects at > https://gcc.gnu.org/wiki/SummerOfCode is undergoing review for 2024, I > think the Fortran ones will not change much. Please look over them, try > to figure out what they would entail and which you'd like best. In this > reply I have also CCed the Fortran mailing list, people there might help > you decide which Fortan project would be the best for you. > > > > I have basic knowledge of C/C++ and I > > have completed my basic computer science courses in the same language, > > which included Object Oriented Programming, Data Structures and > Algorithms, > > Computer Architecture and Operating Systems. I would like to keep in > touch > > and want to know how to proceed working on the topics. > > Contributing to the compiler also requires some rudimentary theoretical > background in compilers, at the very least understanding of the concept > of Intermediate Representation (IR), often also called Intermediate > Language (IL). Googling either of the two terms should help you to find > a lot of material to familiarize yourself with it. > > Please also look again at the "Before you apply" section of the idea > page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make > sure you are able to build, install and test GCC and then have it > generate dumps and step through some function during compilation. > > Also, feel free to ask for help here with any specific GCC development > issues you may encounter. > > Good luck, > > Martin >
RE: GCC Decimal128 class
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/libstdc++/api/a10385.html
should be the latest. I thought there is a std::string/char* constructor.
-Original Message-
From: Ming Cheng
Sent: Wednesday, January 24, 2024 2:20 PM
To: Jonathan Wakely
Cc: GCC Development
Subject: RE: GCC Decimal128 class
Hi Jonathan,
Yes, I can compile now. Come to Decimal128 document, I got this page
https://gcc.gnu.org/onlinedocs/gcc-4.8.1/libstdc++/api/a00702.html :
https://gcc.gnu.org/onlinedocs/gcc-4.8.1/libstdc++/api/a00702.html.
Is there a latest update?
Warm Regards.
Ming
-Original Message-
From: Jonathan Wakely
Sent: Tuesday, January 23, 2024 10:18 PM
To: Ming Cheng
Cc: GCC Development
Subject: Re: GCC Decimal128 class
ATTENTION: This email was sent from someone outside of FlexTrade. Always use
caution when opening attachments or clicking links.
On Tue, 23 Jan 2024 at 14:16, Jonathan Wakely wrote:
>
> On Tue, 23 Jan 2024 at 02:01, Ming Cheng via Gcc wrote:
> >
> > Hi GCC,
> >
> > Seems Janis is not at IBM. Wondering someone from GCC can help my question?
> >
> > Thanks
> > Ming.
> >
> > From: Ming Cheng
> > Sent: Monday, January 22, 2024 3:18 PM
> > To: janis...@us.ibm.com
> > Subject: GCC Decimal128 class
> >
> > Hi Janis Johnson,
> >
> > I want to test GCC Decimal128 class.
> >
> > This is my code:
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include "decimal/decimal.h"
> >
> > int main (void)
> > {
> > std::decimal::decimal128 d128{};
> > return 0;
> > }
> >
> > When I compile by c++23 (/opt/rh/gcc-toolset-13/root/bin/g++
> > -rdynamic -std=c++23 -O2 ..) I got this error:
> >
> > /opt/rh/gcc-toolset-13/root/usr/include/c++/13/decimal/decimal.h:46:10:
> > error: 'decimal32' does not name a type
> >46 | inline decimal32::decimal32(decimal64 __r):
> > __val(__r.__getval()) {}
> >
> > I checked /opt/rh/gcc-toolset-13/root/usr/include/c++/13/decimal/decimal.h
> > and found this comments:
> >
> > /** @file decimal/decimal.h
> > * This is an internal header file, included by other library headers.
> > * Do not attempt to use it directly. @headername{decimal} */
> >
> > Wondering whether you can give some advice?
>
>
> Like it says, you don't include
>
> You want instead. That works fine.
This is documented at:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_headers.html#table.decfp_headers
This communication is for informational purposes only. The contents of this
transmission are confidential and are intended solely for the use of the
individual or entity to whom they are addressed. If you have received this
email in error, please notify the sender by return email and delete this
message from your system. FlexTrade Systems Inc., its subsidiaries and
affiliates do not guarantee the completeness and accuracy of this
transmission's contents. Moreover, FlexTrade Systems Inc., its subsidiaries and
affiliates do not guarantee this communication to be free of viruses and accept
no liability for any damage caused thereof.
