* How to get started with contribution @ 2022-01-05 20:26 Prakhar Khandelwal 2022-01-05 20:35 ` David Edelsohn 0 siblings, 1 reply; 5+ messages in thread From: Prakhar Khandelwal @ 2022-01-05 20:26 UTC (permalink / raw) To: gcc Hey !! I, Prakhar Khandelwal, am currently in the 3rd year of my engineering and majoring in Computer Science. I always wanted to work at a low level in software. That's why I want to contribute to your organization but wondering from where should I start, as I am new to this world of open-source. So, if you can guide me, then it would be great. Waiting for your precious response.!! Regards. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How to get started with contribution 2022-01-05 20:26 How to get started with contribution Prakhar Khandelwal @ 2022-01-05 20:35 ` David Edelsohn 2022-01-07 4:12 ` Why doesn't this pattern match? Andras Tantos 0 siblings, 1 reply; 5+ messages in thread From: David Edelsohn @ 2022-01-05 20:35 UTC (permalink / raw) To: Prakhar Khandelwal; +Cc: GCC Development On Wed, Jan 5, 2022 at 3:27 PM Prakhar Khandelwal via Gcc <gcc@gcc.gnu.org> wrote: > > Hey !! > I, Prakhar Khandelwal, am currently in the 3rd year of my engineering and > majoring in Computer Science. I always wanted to work at a low level in > software. That's why I want to contribute to your organization but > wondering from where should I start, as I am new to this world of > open-source. So, if you can guide me, then it would be great. > Waiting for your precious response.!! > Regards. Thanks for your interest in GCC. Welcome! A good place to start is the GCC Wiki Getting Started page: https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development and browse other recent answers to similar questions in the archives of this mailing list. Thanks, David ^ permalink raw reply [flat|nested] 5+ messages in thread
* Why doesn't this pattern match? 2022-01-05 20:35 ` David Edelsohn @ 2022-01-07 4:12 ` Andras Tantos 2022-01-07 4:25 ` Andrew Pinski 0 siblings, 1 reply; 5+ messages in thread From: Andras Tantos @ 2022-01-07 4:12 UTC (permalink / raw) To: GCC Development Hello! My name is Andras Tantos and I just joined this list, so if I'm asking something off-topic or not following the rules of the community, please let me know. What I'm working on is to port GCC (and Binutils) to a new CPU ISA, I call 'brew'. During developing for this target, I got the following error: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> first.c: In function ‘test_call’: first.c:61:52: error: insn does not satisfy its constraints: 61 | int test_call(int a, int b) { return test_qm(a,b); } | ^ (insn 25 8 9 (set (reg:SI 6 $r6) (reg:SI 0 $pc)) "first.c":61:38 17 {*movsi} (nil)) during RTL pass: final first.c:61:52: internal compiler error: in final_scan_insn_1, at final.c:2811 0x6c4c23 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../brew-gcc/gcc/rtl-error.c:108 0x6c4c4f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../brew-gcc/gcc/rtl-error.c:118 0x643585 final_scan_insn_1 ../../brew-gcc/gcc/final.c:2811 0xb1ef3f final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) ../../brew-gcc/gcc/final.c:2940 0xb1f207 final_1 ../../brew-gcc/gcc/final.c:1997 0xb1fbe6 rest_of_handle_final ../../brew-gcc/gcc/final.c:4285 0xb1fbe6 execute ../../brew-gcc/gcc/final.c:4363 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Clearly, the compiler couldn't find a rule that works for this register move. The relevant section of the .md file is: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (define_expand "movsi" [(set (match_operand:SI 0 "general_operand" "") (match_operand:SI 1 "general_operand" ""))] "" " { /* If this is a store, force the value into a register. */ if (! (reload_in_progress || reload_completed)) { if (MEM_P (operands[0])) { operands[1] = force_reg (SImode, operands[1]); if (MEM_P (XEXP (operands[0], 0))) operands[0] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP (operands[0], 0))); } else if (MEM_P (operands[1]) && MEM_P (XEXP (operands[1], 0))) operands[1] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP (operands[1], 0))); } }") (define_insn "*movsi" [(set (match_operand:SI 0 "nonimmediate_operand" "=r,r,r,W,A,B,r,r,r") (match_operand:SI 1 "brew_general_mov_src_operand" "O,r,i,r,r,r,W,A,B"))] "register_operand (operands[0], SImode) || register_operand (operands[1], SImode)" "@ %0 <- %0 - %0 %0 <- %1 %0 <- %1 mem[%0] <- %1 mem[%0] <- %1 mem[%0] <- %1 %0 <- mem[%1] %0 <- mem[%1] %0 <- mem[%1]" ) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< As you can imagine, I'm fairly new to GCC development, so I must be making some rookie mistake here, but I would have thought that the second alternative in the "*movsi" rule above would match the pattern. brew_general_mov_src_operand is defined as follows: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (define_predicate "brew_general_mov_src_operand" (match_code "mem,const_int,reg,subreg,symbol_ref,label_ref,const") { /* Any (MEM LABEL_REF) is OK. That is a pc-relative load. */ if (MEM_P (op) && GET_CODE (XEXP (op, 0)) == LABEL_REF) return 1; if (MEM_P (op) && GET_CODE (XEXP (op, 0)) == PLUS && GET_CODE (XEXP (XEXP (op, 0), 0)) == REG && GET_CODE (XEXP (XEXP (op, 0), 1)) == CONST_INT ) return 1; /* Any register is good too */ if (REG_P(op)) return 1; /* PC as source is also acceptable */ if (op == pc_rtx) return 1; return general_operand (op, mode); }) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Thanks for all the help, Andras ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Why doesn't this pattern match? 2022-01-07 4:12 ` Why doesn't this pattern match? Andras Tantos @ 2022-01-07 4:25 ` Andrew Pinski 2022-01-07 19:15 ` Andras Tantos 0 siblings, 1 reply; 5+ messages in thread From: Andrew Pinski @ 2022-01-07 4:25 UTC (permalink / raw) To: Andras Tantos; +Cc: GCC Development On Thu, Jan 6, 2022 at 8:13 PM Andras Tantos <andras@tantosonline.com> wrote: > > Hello! > > My name is Andras Tantos and I just joined this list, so if I'm asking > something off-topic or not following the rules of the community, please > let me know. > > What I'm working on is to port GCC (and Binutils) to a new CPU ISA, I > call 'brew'. During developing for this target, I got the following > error: How are the following constraints defined: W,A,B Does one include the pc register? Otherwise you have a mismatch between the predicate brew_general_mov_src_operand (which accepts the pc register) and the constraint which does not. Thanks, Andrew Pinski > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > first.c: In function ‘test_call’: > first.c:61:52: error: insn does not satisfy its constraints: > 61 | int test_call(int a, int b) { return test_qm(a,b); } > | ^ > (insn 25 8 9 (set (reg:SI 6 $r6) > (reg:SI 0 $pc)) "first.c":61:38 17 {*movsi} > (nil)) > during RTL pass: final > first.c:61:52: internal compiler error: in final_scan_insn_1, at > final.c:2811 > 0x6c4c23 _fatal_insn(char const*, rtx_def const*, char const*, int, > char const*) > ../../brew-gcc/gcc/rtl-error.c:108 > 0x6c4c4f _fatal_insn_not_found(rtx_def const*, char const*, int, char > const*) > ../../brew-gcc/gcc/rtl-error.c:118 > 0x643585 final_scan_insn_1 > ../../brew-gcc/gcc/final.c:2811 > 0xb1ef3f final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) > ../../brew-gcc/gcc/final.c:2940 > 0xb1f207 final_1 > ../../brew-gcc/gcc/final.c:1997 > 0xb1fbe6 rest_of_handle_final > ../../brew-gcc/gcc/final.c:4285 > 0xb1fbe6 execute > ../../brew-gcc/gcc/final.c:4363 > Please submit a full bug report, > with preprocessed source if appropriate. > Please include the complete backtrace with any bug report. > See <https://gcc.gnu.org/bugs/> for instructions. > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Clearly, the compiler couldn't find a rule that works for this register > move. The relevant section of the .md file is: > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > (define_expand "movsi" > [(set (match_operand:SI 0 "general_operand" "") > (match_operand:SI 1 "general_operand" ""))] > "" > " > { > /* If this is a store, force the value into a register. */ > if (! (reload_in_progress || reload_completed)) > { > if (MEM_P (operands[0])) > { > operands[1] = force_reg (SImode, operands[1]); > if (MEM_P (XEXP (operands[0], 0))) > operands[0] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP > (operands[0], 0))); > } > else > if (MEM_P (operands[1]) > && MEM_P (XEXP (operands[1], 0))) > operands[1] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP > (operands[1], 0))); > } > }") > > (define_insn "*movsi" > [(set (match_operand:SI 0 > "nonimmediate_operand" "=r,r,r,W,A,B,r,r,r") > (match_operand:SI 1 "brew_general_mov_src_operand" > "O,r,i,r,r,r,W,A,B"))] > "register_operand (operands[0], SImode) > || register_operand (operands[1], SImode)" > "@ > %0 <- %0 - %0 > %0 <- %1 > %0 <- %1 > mem[%0] <- %1 > mem[%0] <- %1 > mem[%0] <- %1 > %0 <- mem[%1] > %0 <- mem[%1] > %0 <- mem[%1]" > ) > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > As you can imagine, I'm fairly new to GCC development, so I must be > making some rookie mistake here, but I would have thought that the > second alternative in the "*movsi" rule above would match the pattern. > > brew_general_mov_src_operand is defined as follows: > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > (define_predicate "brew_general_mov_src_operand" > (match_code "mem,const_int,reg,subreg,symbol_ref,label_ref,const") > { > /* Any (MEM LABEL_REF) is OK. That is a pc-relative load. */ > if (MEM_P (op) && GET_CODE (XEXP (op, 0)) == LABEL_REF) > return 1; > > if (MEM_P (op) > && GET_CODE (XEXP (op, 0)) == PLUS > && GET_CODE (XEXP (XEXP (op, 0), 0)) == REG > && GET_CODE (XEXP (XEXP (op, 0), 1)) == CONST_INT > ) > return 1; > /* Any register is good too */ > if (REG_P(op)) > return 1; > /* PC as source is also acceptable */ > if (op == pc_rtx) > return 1; > return general_operand (op, mode); > }) > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Thanks for all the help, > Andras > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Why doesn't this pattern match? 2022-01-07 4:25 ` Andrew Pinski @ 2022-01-07 19:15 ` Andras Tantos 0 siblings, 0 replies; 5+ messages in thread From: Andras Tantos @ 2022-01-07 19:15 UTC (permalink / raw) To: Andrew Pinski; +Cc: GCC Development Thanks for the help, that's exactly it! Andras On Thu, 2022-01-06 at 20:25 -0800, Andrew Pinski wrote: > On Thu, Jan 6, 2022 at 8:13 PM Andras Tantos <andras@tantosonline.com > > wrote: > > Hello! > > > > My name is Andras Tantos and I just joined this list, so if I'm > > asking > > something off-topic or not following the rules of the community, > > please > > let me know. > > > > What I'm working on is to port GCC (and Binutils) to a new CPU ISA, > > I > > call 'brew'. During developing for this target, I got the following > > error: > > How are the following constraints defined: > W,A,B > > Does one include the pc register? > Otherwise you have a mismatch between the predicate > brew_general_mov_src_operand (which accepts the pc register) and the > constraint which does not. > > Thanks, > Andrew Pinski > > > > first.c: In function ‘test_call’: > > first.c:61:52: error: insn does not satisfy its constraints: > > 61 | int test_call(int a, int b) { return test_qm(a,b); } > > | ^ > > (insn 25 8 9 (set (reg:SI 6 $r6) > > (reg:SI 0 $pc)) "first.c":61:38 17 {*movsi} > > (nil)) > > during RTL pass: final > > first.c:61:52: internal compiler error: in final_scan_insn_1, at > > final.c:2811 > > 0x6c4c23 _fatal_insn(char const*, rtx_def const*, char const*, int, > > char const*) > > ../../brew-gcc/gcc/rtl-error.c:108 > > 0x6c4c4f _fatal_insn_not_found(rtx_def const*, char const*, int, > > char > > const*) > > ../../brew-gcc/gcc/rtl-error.c:118 > > 0x643585 final_scan_insn_1 > > ../../brew-gcc/gcc/final.c:2811 > > 0xb1ef3f final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) > > ../../brew-gcc/gcc/final.c:2940 > > 0xb1f207 final_1 > > ../../brew-gcc/gcc/final.c:1997 > > 0xb1fbe6 rest_of_handle_final > > ../../brew-gcc/gcc/final.c:4285 > > 0xb1fbe6 execute > > ../../brew-gcc/gcc/final.c:4363 > > Please submit a full bug report, > > with preprocessed source if appropriate. > > Please include the complete backtrace with any bug report. > > See <https://gcc.gnu.org/bugs/> for instructions. > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > Clearly, the compiler couldn't find a rule that works for this > > register > > move. The relevant section of the .md file is: > > > > (define_expand "movsi" > > [(set (match_operand:SI 0 "general_operand" "") > > (match_operand:SI 1 "general_operand" ""))] > > "" > > " > > { > > /* If this is a store, force the value into a register. */ > > if (! (reload_in_progress || reload_completed)) > > { > > if (MEM_P (operands[0])) > > { > > operands[1] = force_reg (SImode, operands[1]); > > if (MEM_P (XEXP (operands[0], 0))) > > operands[0] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP > > (operands[0], 0))); > > } > > else > > if (MEM_P (operands[1]) > > && MEM_P (XEXP (operands[1], 0))) > > operands[1] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP > > (operands[1], 0))); > > } > > }") > > > > (define_insn "*movsi" > > [(set (match_operand:SI 0 > > "nonimmediate_operand" "=r,r,r,W,A,B,r,r,r") > > (match_operand:SI 1 "brew_general_mov_src_operand" > > "O,r,i,r,r,r,W,A,B"))] > > "register_operand (operands[0], SImode) > > || register_operand (operands[1], SImode)" > > "@ > > %0 <- %0 - %0 > > %0 <- %1 > > %0 <- %1 > > mem[%0] <- %1 > > mem[%0] <- %1 > > mem[%0] <- %1 > > %0 <- mem[%1] > > %0 <- mem[%1] > > %0 <- mem[%1]" > > ) > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > As you can imagine, I'm fairly new to GCC development, so I must be > > making some rookie mistake here, but I would have thought that the > > second alternative in the "*movsi" rule above would match the > > pattern. > > > > brew_general_mov_src_operand is defined as follows: > > > > (define_predicate "brew_general_mov_src_operand" > > (match_code > > "mem,const_int,reg,subreg,symbol_ref,label_ref,const") > > { > > /* Any (MEM LABEL_REF) is OK. That is a pc-relative load. */ > > if (MEM_P (op) && GET_CODE (XEXP (op, 0)) == LABEL_REF) > > return 1; > > > > if (MEM_P (op) > > && GET_CODE (XEXP (op, 0)) == PLUS > > && GET_CODE (XEXP (XEXP (op, 0), 0)) == REG > > && GET_CODE (XEXP (XEXP (op, 0), 1)) == CONST_INT > > ) > > return 1; > > /* Any register is good too */ > > if (REG_P(op)) > > return 1; > > /* PC as source is also acceptable */ > > if (op == pc_rtx) > > return 1; > > return general_operand (op, mode); > > }) > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > Thanks for all the help, > > Andras > > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-01-07 19:15 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-05 20:26 How to get started with contribution Prakhar Khandelwal 2022-01-05 20:35 ` David Edelsohn 2022-01-07 4:12 ` Why doesn't this pattern match? Andras Tantos 2022-01-07 4:25 ` Andrew Pinski 2022-01-07 19:15 ` Andras Tantos
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).