GCC GSoC 2022: Call for project ideas and mentors

2022-01-06 Thread Martin Jambor 
Hello,

another year is upon us and Google has announced there will be again
Google Summer of Code 2022 (though AFAIK there is no specific timeline
yet).  I'd like to volunteer to be the main Org Admin for GCC again so
let me know if you think I shouldn't or that someone else should, but
otherwise I'll assume that I will.

There will be a few important changes to the GSoC this year.  The most
important for us is that there will be two project sizes: medium-sized
projects which are expected to take about 175 hours to complete and
large projects expected to take approximately 350 hours (the size from
2020 and earlier).  I expect that most of our projects will be large but
I think we can offer one or two medium-sized ideas too.

Google will also increase timing flexibility, so the projects can run
for longer (up to 22 weeks) allowing mentors to go on vacation and
students to pause and focus on exams.  Talking about students, Google is
going to open the program to all adults, so from now on, the
participants working on the projects will be called GSoC contributors.

Slightly more information about these changes can be found at
https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html
I am sure we will learn more when the actual timeline is announced too.

 The most important bit: 

Even before that happens, I would like to ask all (moderately) seasoned
GCC contributors to consider mentoring a student this year and ideally
also come up with a project that they would like to lead.  I'm
collecting proposal on our wiki page
https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the
top list there.  Or, if you are unsure, post your offer and project idea
as a reply here to the mailing list.

=

Eventually, each listed project idea should have a) a project
title/description, b) more detailed description of the project (2-5
sentences), c) expected outcomes, d) skills required/preferred, e)
project size and difficulty and f) expected mentors.

Project ideas that come without an offer to also mentor them are always
fun to discuss, by all means feel free to reply to this email with yours
and I will attempt to find a mentor, but please be aware that we can
only use the suggestion it if we actually find one.

Everybody in the GCC community is invited to go over
https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
otherwise bad project suggestions and help improve viable ones.

Finally, please continue helping (prospective) students figure stuff out
about GCC like you always do.  So far I think all of them enjoyed
working with us, even if many sometimes struggled with GCC's complexity.

I will update you as more details about GSoC 2022 become available.

Thank you, let's hope we attract some new talent again this year.

Martin

gcc-9-20220106 is now available

2022-01-06 Thread GCC Administrator via Gcc 
Snapshot gcc-9-20220106 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20220106/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 
revision 4959b9853915fe602dc4b3304ae50a7c43dce1e5

You'll find:

 gcc-9-20220106.tar.xzComplete GCC

  SHA256=9fc9e251df4e90358536b5505e034da6ebf8a20db32332318cdf190863a95f33
  SHA1=1e05fe17ba751ba45964a047a3269e56a54665cd

Diffs from 9-20211230 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
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.

Why doesn't this pattern match?

2022-01-06 Thread Andras Tantos 
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  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

Re: Why doesn't this pattern match?

2022-01-06 Thread Andrew Pinski via Gcc 
On Thu, Jan 6, 2022 at 8:13 PM Andras Tantos  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  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
>
>