GCC Mirror - FTP - HTTP - HTTPS - RSYNC
Hi We are a hosting service company that wants to provide services to open source software systems. In this regard, we have prepared a mirror for GCC support, which we want to put in your list after your review. Please check our mirror and let us know if we see a problem so we can fix it We are very happy to be able to become a mirror for GCC . Mirror *HTTP* URL: http://mirror.clientvps.com/gcc/ Mirror *HTTPS* URL: https://mirror.clientvps.com/gcc/ *FTP* Mirror: ftp://mirror.clientvps.com/gcc/ *RSYNC *Mirror: rsync -r rsync://mirror.clientvps.com:/gcc /path/to/mirror Country the mirror is located: Germany Update frequency : 2 times per day Contact email address: i...@clientvps.com contact person name: Eric Milon Rsync repository used: Yes I have subscribed the contact address to gcc@gcc.gnu.org At the moment, I rsync from this IP address: 148.251.214.203 I am checking the output from the rsync job on a regular basis : Yes
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
Hello Vincent, On Thu, 8 Oct 2020 at 15:52, Vincent Lefevre wrote: > > On 2020-10-01 18:55:04 +0200, Alejandro Colomar via Gcc wrote: > > On 2020-10-01 18:38, Michael Kerrisk (man-pages) wrote: > > > > +According to the C language standard, > > > > +a pointer to any object type may be converted to a pointer to > > > > +.I void > > > > +and back. > > > > +POSIX further requires that any pointer, > > > > +including pointers to functions, > > > > +may be converted to a pointer to > > > > +.I void > > > > +and back. > > > I know you are correct about POSIX, but which part of the > > > standard did you find this information in? The only > > > reference that I find in POSIX is the dlsym() spec. Is it > > > covered also somewhere else in the standrd? > [...] > > I've bean searching, and dlsym is the only one: > [...] > > The most explicit paragraph in dlsym is the following: > > > > [[ > > Note that conversion from a void * pointer to a function pointer as in: > > > > fptr = (int (*)(int))dlsym(handle, "my_function"); > > > > is not defined by the ISO C standard. > > This standard requires this conversion to work correctly > > on conforming implementations. > > ]] > > I think that "this conversion" applies only to the dlsym context, > and the conversion isn't defined in general. Imagine that the > void * pointer to function pointer conversion requires the compiler > to generate additional code. The compiler may be able to detect > that dlsym will not be used in some contexts (e.g. because of > always false condition) and do not generate such additional code, > making the conversion to have undefined behavior. Thanks. It's a good point that you raise. I agree that the wording in the standard is not too clear. But I believe the intent really is to allow [void *] <==> [function pointer] casts. The most relevant pieces I can find are as follows: In the current standard, in CHANGE HISTORY for dlsum(): [[ Issue 6 IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/14 is applied, correcting an example, and adding text to the RATIONALE describing issues related to conversion of pointers to functions and back again. Issue 7 POSIX.1-2008, Technical Corrigendum 1, XSH/TC1-2008/0074 [74] is applied. ]] https://www.austingroupbugs.net/view.php?id=74 This is a little thin. The initial report says: "The intent is simply to permit dlsym to use a void * as its return type." and no one seems to have questioned that. And then in https://pubs.opengroup.org/onlinepubs/7899949299/toc.pdf (TC1 for POSIXX.1-2001) there is: [[ Change Number: XSH/TC1/D6/14 [XSH ERN 13] On Page: 259 Line: 8566,8590 Section: dlsym In the EXAMPLES section, change from: fptr = (int (*)(int))dlsym(handle, "my_function"); to: *(void **)(&fptr) = dlsym(handle, "my_function"); In the RATIONALE section on Page 260, Line 8590, change from: "None." to: "The C Standard does not require that pointers to functions can be cast back and forth to pointers to data. Indeed, the C Standard does not require that an object of type void* can hold a pointer to a function. Systems supporting the X/Open System Interfaces Extension, however, do require that an object of type void* can hold a pointer to a function. The result of converting a pointer to a function into a pointer to another data type (except void*) is still undefined, however. ]] And one finds the above text in POSIX.1-2001 TC1 spec for dlsym(), although it was removed in POSIX.1-2008, and now we have just the smaller text that is present in the dlsym() page. But along the way, I can find nothing that speaks against the notion that POSIX was aiming to allow the more general cast of [void *] <==> [function pointer]. Your thoughts? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Are you going to fix the addcarry_u64 and subborrow_u64 bugs in the future?
The assembly GCC generates are just wrong, very wrong here. People have
reported the similar bugs since 2015 over and over again but GCC still could
not get it done right. Even MSVC is doing the right thing.
If you are not going to fix them, okay, I will start to write assembly manually.
I have tested all cases, including _addcarry_u64 and _subborrow_u64.
https://gcc.godbolt.org/z/asMrKv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97387
#include
#include
void add256(uint64_t a[4], uint64_t b[4]){
uint8_t carry = 0;
for (int i = 0; i < 4; ++i)
carry = _addcarry_u64(carry, a[i], b[i], (unsigned long long*)(a+i));
}
Assembly GCC generates
add256:
movq(%rsi), %rax
addq(%rdi), %rax
setc%dl
movq%rax, (%rdi)
movq8(%rdi), %rax
addb$-1, %dl
adcq8(%rsi), %rax
setc%dl
movq%rax, 8(%rdi)
movq16(%rdi), %rax
addb$-1, %dl
adcq16(%rsi), %rax
setc%dl
movq%rax, 16(%rdi)
movq24(%rsi), %rax
addb$-1, %dl
adcq%rax, 24(%rdi)
ret
setc?? LOLOLOL. This is a joke for me.
Clang generates:
add256:
movq(%rsi), %rax
addq%rax, (%rdi)
movq8(%rsi), %rax
adcq%rax, 8(%rdi)
movq16(%rsi), %rax
adcq%rax, 16(%rdi)
movq24(%rsi), %rax
adcq%rax, 24(%rdi)
retq
Sent from Mail for Windows 10
GCC DWARF Issue - Frame Pointer Dependency
Hi, I have a function for which GCC is generating the following code (just showing the relevant snippet here). 5a70 : 5a70: 4c 8d 54 24 08 lea0x8(%rsp),%r10 5a75: 48 83 e4 f0 and$0xfff0,%rsp 5a79: 41 ff 72 f8 pushq -0x8(%r10) 5a7d: 55 push %rbp 5a7e: 48 89 e5mov%rsp,%rbp 5a81: 41 57 push %r15 5a83: 41 56 push %r14 5a85: 41 55 push %r13 5a87: 41 54 push %r12 : 5b08: 5b pop%rbx 5b09: 41 5a pop%r10 5b0b: 41 5c pop%r12 5b0d: 41 5d pop%r13 5b0f: 41 5e pop%r14 5b11: 41 5f pop%r15 5b13: 5d pop%rbp *=>5b14: 49 8d 62 f8 lea-0x8(%r10),%rsp* 5b18: c3 retq I am using a SIGPROF based CPU profiler (Google CPU Profiler) to profile my code. The SIGPROF handler (of the Google CPU Profiler) tries to unwind the stack (using libunwind) every time it gets a SIGPROF. And libunwind (used for unwinding the stack) uses DWARF unwind table (dumped by gcc -O3 -mstackrealign -fomit-frame-pointer). And I noticed that I get a crash every time my code gets interrupted by SIGPROF while my program is in the middle of setting / resetting frame pointer and the frame pointer %rbp happens to point to the parent/previous frame at that point, for example, in instruction *5b14* (shown above with => and red). *=>5b14: 49 8d 62 f8 lea-0x8(%r10),%rsp* DWARF dumped by GCC for the snippet shown above is the following: 02f4 0044 02f8 FDE cie= pc=5a70..5d7c DW_CFA_advance_loc: 5 to 5a75 DW_CFA_def_cfa: r10 (r10) ofs 0 DW_CFA_advance_loc: 9 to 5a7e DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_advance_loc: 11 to 5a89 DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) DW_CFA_advance_loc: 5 to 5a8e DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref) DW_CFA_advance_loc: 4 to 5a92 *>> DW_CFA_expression: r3 (rbx) (DW_OP_breg6 (rbp): -48)* DW_CFA_advance_loc1: 121 to 5b0b DW_CFA_remember_state *>> DW_CFA_def_cfa: r10 (r10) ofs 0* DW_CFA_advance_loc: 13 to 5b18 DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_advance_loc: 8 to 5b20 DW_CFA_restore_state 02f4 0044 02f8 FDE cie= pc=5a70..5d7c LOC CFA rbx rbp r12 r13 r14 r15 ra 5a70 rsp+8u u u u u u c-8 5a75 r10+0u u u u u u c-8 5a7e r10+0u exp u u u u c-8 5a89 r10+0u exp exp exp exp exp c-8 5a8e exp u exp exp exp exp exp c-8 5a92 exp exp exp exp exp exp exp c-8 *5b0b r10+0**exp **exp exp exp exp exp c-8* 5b18 rsp+8exp exp exp exp exp exp c-8 5b20 exp exp exp exp exp exp exp c-8 And if you see here, the DWARF expression for fetching the CFA is correct, but what about the DWARF expression for fetching the value of %rbx? *>> DW_CFA_expression: r3 (rbx) (DW_OP_breg6 (rbp): -48)* Value of %rbx is (in DWARF) is “%rbp relative” and since %rbp is pointing to the wrong (parent/previous) frame, we will obviously get garbage for the value of %rbx. If you look at the generated DWARF carefully, pretty much everything is ‘%rbp relative’, so values for each of these registers cannot be restored in this scenario. DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) I was just wondering, instead of making these %rbp-relative, could we have made this CFA-relative? That would have taken care of this particular issue, since CFA is correctly maintained/restored in this example. Another question, is there a known work around for this issue? Regards AJ
Re: GCC DWARF Issue - Frame Pointer Dependency
On Tue, Oct 13, 2020 at 5:10 AM AJ D via Gcc wrote: > > Hi, > > > > I have a function for which GCC is generating the following code (just > showing the relevant snippet here). > > > > 5a70 : > > 5a70: 4c 8d 54 24 08 lea0x8(%rsp),%r10 > > 5a75: 48 83 e4 f0 and$0xfff0,%rsp > > 5a79: 41 ff 72 f8 pushq -0x8(%r10) > > 5a7d: 55 push %rbp > > 5a7e: 48 89 e5mov%rsp,%rbp > > 5a81: 41 57 push %r15 > > 5a83: 41 56 push %r14 > > 5a85: 41 55 push %r13 > > 5a87: 41 54 push %r12 > > : > > 5b08: 5b pop%rbx > > 5b09: 41 5a pop%r10 > > 5b0b: 41 5c pop%r12 > > 5b0d: 41 5d pop%r13 > > 5b0f: 41 5e pop%r14 > > 5b11: 41 5f pop%r15 > > 5b13: 5d pop%rbp > > *=>5b14: 49 8d 62 f8 lea-0x8(%r10),%rsp* > > 5b18: c3 retq > > > > I am using a SIGPROF based CPU profiler (Google CPU Profiler) to profile my > code. The SIGPROF handler (of the Google CPU Profiler) tries to unwind the > stack (using libunwind) every time it gets a SIGPROF. And libunwind (used > for unwinding the stack) uses DWARF unwind table (dumped by gcc -O3 > -mstackrealign -fomit-frame-pointer). > > > And I noticed that I get a crash every time my code gets interrupted by > SIGPROF while my program is in the middle of setting / resetting frame > pointer and the frame pointer %rbp happens to point to the parent/previous > frame at that point, for example, in instruction *5b14* (shown above with > => and red). > > > > *=>5b14: 49 8d 62 f8 lea-0x8(%r10),%rsp* > > > DWARF dumped by GCC for the snippet shown above is the following: > > > > 02f4 0044 02f8 FDE cie= > pc=5a70..5d7c > > DW_CFA_advance_loc: 5 to 5a75 > > DW_CFA_def_cfa: r10 (r10) ofs 0 > > DW_CFA_advance_loc: 9 to 5a7e > > DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) > > DW_CFA_advance_loc: 11 to 5a89 > > DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) > > DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) > > DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) > > DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) > > DW_CFA_advance_loc: 5 to 5a8e > > DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref) > > DW_CFA_advance_loc: 4 to 5a92 > > *>> DW_CFA_expression: r3 (rbx) (DW_OP_breg6 (rbp): -48)* > > DW_CFA_advance_loc1: 121 to 5b0b > > DW_CFA_remember_state > > *>> DW_CFA_def_cfa: r10 (r10) ofs 0* > > DW_CFA_advance_loc: 13 to 5b18 > > DW_CFA_def_cfa: r7 (rsp) ofs 8 > > DW_CFA_advance_loc: 8 to 5b20 > > DW_CFA_restore_state > > > > 02f4 0044 02f8 FDE cie= > pc=5a70..5d7c > >LOC CFA rbx rbp r12 r13 r14 r15 ra > > 5a70 rsp+8u u u u u u c-8 > > 5a75 r10+0u u u u u u c-8 > > 5a7e r10+0u exp u u u u c-8 > > 5a89 r10+0u exp exp exp exp exp c-8 > > 5a8e exp u exp exp exp exp exp c-8 > > 5a92 exp exp exp exp exp exp exp c-8 > > *5b0b r10+0**exp **exp exp exp exp exp c-8* > > 5b18 rsp+8exp exp exp exp exp exp c-8 > > 5b20 exp exp exp exp exp exp exp c-8 > > > > And if you see here, the DWARF expression for fetching the CFA is correct, > but what about the DWARF expression for fetching the value of %rbx? > > > > *>> DW_CFA_expression: r3 (rbx) (DW_OP_breg6 (rbp): -48)* > > > > Value of %rbx is (in DWARF) is “%rbp relative” and since %rbp is pointing > to the wrong (parent/previous) frame, we will obviously get garbage for the > value of %rbx. > > > > If you look at the generated DWARF carefully, pretty much everything is > ‘%rbp relative’, so values for each of these registers cannot be restored > in this scenario. > > > > DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) > > DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) > > DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) > > DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) > > > > I was just wondering, instead of making these %rbp-relative, could we have > made this CFA-relative? That would have taken care of this particular > issue, since CFA is correctly maintained/restored in this example. > > > > Another question, is there a known work around for this issue
