gcc 12.4 release archive?

[Liviu Ionescu]

Hi,

GCC 12.4 was released two days ago, but I could not yet find the release 
archive at https://ftp.gnu.org/gnu/gcc/.

Could you upload it?

Thank you,

Liviu


> Begin forwarded message:
> 
> From: Jakub Jelinek via gcc-announce 
> Subject: GCC 12.4 Released
> Date: 20 June 2024 at 12:27:10 EEST
> To: gcc-annou...@gcc.gnu.org
> Reply-To: Jakub Jelinek 
> 
> The GNU Compiler Collection version 12.4 has been released.
> 
> GCC 12.4 is a bug-fix release from the GCC 12 branch
> containing important fixes for regressions and serious bugs in
> GCC 12.3 with more than 84 bugs fixed since the previous release.
> 
> This release is available from the FTP servers listed here:
> 
>  https://sourceware.org/pub/gcc/releases/gcc-12.4.0/
>  https://gcc.gnu.org/mirrors.html
> 
> Please do not contact me directly regarding questions or comments
> about this release.  Instead, use the resources available from
> http://gcc.gnu.org.
> 
> As always, a vast number of people contributed to this GCC release
> -- far too many to thank them individually!
> 

Re: Setting insn mnemonic partly automagically

[Georg-Johann Lay]

Am 22.06.24 um 10:46 schrieb Stefan Schulze Frielinghaus:

On Fri, Jun 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote:



Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc:

Hi all,

I'm trying to add an alternative to an existing insn foobar:

(define_insn "foobar"
[(set (match_operand ...)
  (match_operand ...))]
""
"@
 foo
 bar
 #")

Since the asm output depends on the operands in a non-trivial way which isn't
easily solved via iterators, I went for a general C function and came up with:

(define_insn "foobar"
[(set (match_operand ...)
  (match_operand ...))]
""
"@
 foo
 * return foobar_helper (operands[0], operands[1]);
 bar
 #"
[(set_attr_alternative "mnemonic" [(const_string "foo")
   (const_string "specialcase")
   (const_string "bar")
   (const_string "unknown")])])

If there exist a lot of alternatives, then setting the mnemonic attribute like
this feels repetitive and is error prone.  Furthermore, if there exists no
other insn with an output template containing foo/bar, then I would have to
declare foo/bar via

(define_attr "mnemonic" "...,foo,bar,..." (const_string "unknown"))

which again is repetitive.  Thus, I'm wondering if there exists a more elegant
way to achieve this?  Ultimately, I would like to set the mnemonic
attribute only manually for the alternative which is implemented via C
code and let the mnemonic attribute for the remaining alternatives be
set automagically.  Not sure whether this is supported?

If all fails, I have another idea how to solve this by utilizing PRINT_OPERAND.
However, now I'm curious whether my current attempt is feasible or not.

Cheers,
Stefan


It's a bit unclear to me what you are trying to do, as you are not only
adding an insn alternative, but also are adding insn attribute
"mnemonic", which the original insn did not have.


My take so far is that every insn has a mnemonic attribute which is set
either explicitly or implicitly (assuming that the target requested this
via define_attr "mnemonic" "...").  This is done in function
gen_mnemonic_attr() from gensupport.cc.  Thus, something like

(define_insn "foobar"
[(set (match_operand ...)
  (match_operand ...))]
""
"@
 foo
 bar
 #")

and

(define_insn "foobar"
[(set (match_operand ...)
  (match_operand ...))]
""
"@
 foo
 bar
 #"
[(set_attr_alternative "mnemonic" [(const_string "foo")
   (const_string "bar")
   (const_string "unknown")])])

should be equivalent.

Of course, the implicit method fails if the pattern is generated via C
statements which is way I set it manually in the initial example.  The
initial example contained 3 alternatives plus 1 for the generated one.
Setting it manually there might be feasible, however, for my actual
problem I have an insn with 27 alternatives where I do not want to set
and maintain it manually.  A side effect of setting the attribute
implicitly is that each mnemonic is added automatically to the mnemonic
hash table which I would have to do manually for my 27 alternatives
which I would like to avoid, too.



Also, it's unclear how PRINT_OPERAND would help with setting the attribute.


For my particular problem I think one can also utilize PRINT_OPERAND
which I should have elaborated a bit more but feared to make the example
unnecessarily complicated.  The C code

   foobar_helper (operands[0], operands[1])

emits actually an extended mnemonic "specialcase$VAR\t%0,%1" where $VAR
can be either A, B, or C.  The extended mnemonic is just syntactic sugar
for the base mnemonic "specialcase\t%0,%1,$IMM" which is why we can lie
and hard code the mnemonic attribute to specialcase since this won't
effect scheduling.  Since the choice which extended mnemonic should be
used depends only on operands[1] I thought about rewriting all this into

(define_insn "foobar"
[(set (match_operand ...)
  (match_operand ...))]
""
"@
 foo
 specialcase\t%0,%1,%X1
 bar
 #")

Obviously we have to sacrifice the usage of an extended mnemonic but
more problematic is that we have to allocate one of those very few codes
X just for this insn.  So this doesn't scale either if one has to come
up with many different codes.  Furthermore, this only works in my very
particular case since I can split the extended mnemonic into a base
mnemonic and an immediate which only depends on one operand, i.e., it
would fail if it depended on operands[0] and operands[1].

I hope this makes it a bit more clear, if not just let me know.

Cheers,
Stefan


Maybe the following syntax for setting an attribute is a better
fit in your case?

  [(set (attr "length")
(symbol_ref ("4 + reg_overlap_mentioned_p (operands[0], 
operands[1])")))


So you can hook

Re: Setting insn mnemonic partly automagically

[Stefan Schulze Frielinghaus via Gcc]

On Fri, Jun 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote:
> 
> 
> Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc:
> > Hi all,
> > 
> > I'm trying to add an alternative to an existing insn foobar:
> > 
> > (define_insn "foobar"
> >[(set (match_operand ...)
> >  (match_operand ...))]
> >""
> >"@
> > foo
> > bar
> > #")
> > 
> > Since the asm output depends on the operands in a non-trivial way which 
> > isn't
> > easily solved via iterators, I went for a general C function and came up 
> > with:
> > 
> > (define_insn "foobar"
> >[(set (match_operand ...)
> >  (match_operand ...))]
> >""
> >"@
> > foo
> > * return foobar_helper (operands[0], operands[1]);
> > bar
> > #"
> >[(set_attr_alternative "mnemonic" [(const_string "foo")
> >   (const_string "specialcase")
> >   (const_string "bar")
> >   (const_string "unknown")])])
> > 
> > If there exist a lot of alternatives, then setting the mnemonic attribute 
> > like
> > this feels repetitive and is error prone.  Furthermore, if there exists no
> > other insn with an output template containing foo/bar, then I would have to
> > declare foo/bar via
> > 
> > (define_attr "mnemonic" "...,foo,bar,..." (const_string "unknown"))
> > 
> > which again is repetitive.  Thus, I'm wondering if there exists a more 
> > elegant
> > way to achieve this?  Ultimately, I would like to set the mnemonic
> > attribute only manually for the alternative which is implemented via C
> > code and let the mnemonic attribute for the remaining alternatives be
> > set automagically.  Not sure whether this is supported?
> > 
> > If all fails, I have another idea how to solve this by utilizing 
> > PRINT_OPERAND.
> > However, now I'm curious whether my current attempt is feasible or not.
> > 
> > Cheers,
> > Stefan
> 
> It's a bit unclear to me what you are trying to do, as you are not only
> adding an insn alternative, but also are adding insn attribute
> "mnemonic", which the original insn did not have.

My take so far is that every insn has a mnemonic attribute which is set
either explicitly or implicitly (assuming that the target requested this
via define_attr "mnemonic" "...").  This is done in function
gen_mnemonic_attr() from gensupport.cc.  Thus, something like

(define_insn "foobar"
   [(set (match_operand ...)
 (match_operand ...))]
   ""
   "@
foo
bar
#")

and

(define_insn "foobar"
   [(set (match_operand ...)
 (match_operand ...))]
   ""
   "@
foo
bar
#"
   [(set_attr_alternative "mnemonic" [(const_string "foo")
  (const_string "bar")
  (const_string "unknown")])])

should be equivalent.

Of course, the implicit method fails if the pattern is generated via C
statements which is way I set it manually in the initial example.  The
initial example contained 3 alternatives plus 1 for the generated one.
Setting it manually there might be feasible, however, for my actual
problem I have an insn with 27 alternatives where I do not want to set
and maintain it manually.  A side effect of setting the attribute
implicitly is that each mnemonic is added automatically to the mnemonic
hash table which I would have to do manually for my 27 alternatives
which I would like to avoid, too.

> 
> Also, it's unclear how PRINT_OPERAND would help with setting the attribute.

For my particular problem I think one can also utilize PRINT_OPERAND
which I should have elaborated a bit more but feared to make the example
unnecessarily complicated.  The C code

  foobar_helper (operands[0], operands[1])

emits actually an extended mnemonic "specialcase$VAR\t%0,%1" where $VAR
can be either A, B, or C.  The extended mnemonic is just syntactic sugar
for the base mnemonic "specialcase\t%0,%1,$IMM" which is why we can lie
and hard code the mnemonic attribute to specialcase since this won't
effect scheduling.  Since the choice which extended mnemonic should be
used depends only on operands[1] I thought about rewriting all this into

(define_insn "foobar"
   [(set (match_operand ...)
 (match_operand ...))]
   ""
   "@
foo
specialcase\t%0,%1,%X1
bar
#")

Obviously we have to sacrifice the usage of an extended mnemonic but
more problematic is that we have to allocate one of those very few codes
X just for this insn.  So this doesn't scale either if one has to come
up with many different codes.  Furthermore, this only works in my very
particular case since I can split the extended mnemonic into a base
mnemonic and an immediate which only depends on one operand, i.e., it
would fail if it depended on operands[0] and operands[1].

I hope this makes it a bit more clear, if not just let me know.

Cheers,
Stefan

> 
> Johann

Re: SARIF support in GCC: wiki page and BZ keyword

[David Malcolm via Gcc]

On Fri, 2024-06-21 at 18:46 -0400, Eric Gallager wrote:
> On Fri, Jun 21, 2024 at 12:12 PM David Malcolm via Gcc
>  wrote:
> > 
> > I've create a wiki page to track our support for GCC:
> >   https://gcc.gnu.org/wiki/SARIF
> > 
> > and a keyword "SARIF" in our bugzilla instance for bugs relating to
> > it
> > (see links on the above page).
> > 
> 
> Hi, thanks for creating these. Since "SARIF" is a keyword, what
> component should bugs using it generally go under?

Good question.  Probably whatever component triggers the issue or is
most closely related to it.  Looking at the existing open bugs we have
a couple for "analyzer" that relate to -fanalyzer, PR 105916 is
specific to Fortran and thus has that as its component.  But our BZ
classification doesn't have to be perfect; hopefully the keyword will
make it easy to track such issues.

Dave

Re: Setting insn mnemonic partly automagically

[Stefan Schulze Frielinghaus via Gcc]

On Sat, Jun 22, 2024 at 01:00:54PM +0200, Georg-Johann Lay wrote:
> Am 22.06.24 um 10:46 schrieb Stefan Schulze Frielinghaus:
> > On Fri, Jun 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote:
> > > 
> > > 
> > > Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc:
> > > > Hi all,
> > > > 
> > > > I'm trying to add an alternative to an existing insn foobar:
> > > > 
> > > > (define_insn "foobar"
> > > > [(set (match_operand ...)
> > > >   (match_operand ...))]
> > > > ""
> > > > "@
> > > >  foo
> > > >  bar
> > > >  #")
> > > > 
> > > > Since the asm output depends on the operands in a non-trivial way which 
> > > > isn't
> > > > easily solved via iterators, I went for a general C function and came 
> > > > up with:
> > > > 
> > > > (define_insn "foobar"
> > > > [(set (match_operand ...)
> > > >   (match_operand ...))]
> > > > ""
> > > > "@
> > > >  foo
> > > >  * return foobar_helper (operands[0], operands[1]);
> > > >  bar
> > > >  #"
> > > > [(set_attr_alternative "mnemonic" [(const_string "foo")
> > > >(const_string "specialcase")
> > > >(const_string "bar")
> > > >(const_string "unknown")])])
> > > > 
> > > > If there exist a lot of alternatives, then setting the mnemonic 
> > > > attribute like
> > > > this feels repetitive and is error prone.  Furthermore, if there exists 
> > > > no
> > > > other insn with an output template containing foo/bar, then I would 
> > > > have to
> > > > declare foo/bar via
> > > > 
> > > > (define_attr "mnemonic" "...,foo,bar,..." (const_string "unknown"))
> > > > 
> > > > which again is repetitive.  Thus, I'm wondering if there exists a more 
> > > > elegant
> > > > way to achieve this?  Ultimately, I would like to set the mnemonic
> > > > attribute only manually for the alternative which is implemented via C
> > > > code and let the mnemonic attribute for the remaining alternatives be
> > > > set automagically.  Not sure whether this is supported?
> > > > 
> > > > If all fails, I have another idea how to solve this by utilizing 
> > > > PRINT_OPERAND.
> > > > However, now I'm curious whether my current attempt is feasible or not.
> > > > 
> > > > Cheers,
> > > > Stefan
> > > 
> > > It's a bit unclear to me what you are trying to do, as you are not only
> > > adding an insn alternative, but also are adding insn attribute
> > > "mnemonic", which the original insn did not have.
> > 
> > My take so far is that every insn has a mnemonic attribute which is set
> > either explicitly or implicitly (assuming that the target requested this
> > via define_attr "mnemonic" "...").  This is done in function
> > gen_mnemonic_attr() from gensupport.cc.  Thus, something like
> > 
> > (define_insn "foobar"
> > [(set (match_operand ...)
> >   (match_operand ...))]
> > ""
> > "@
> >  foo
> >  bar
> >  #")
> > 
> > and
> > 
> > (define_insn "foobar"
> > [(set (match_operand ...)
> >   (match_operand ...))]
> > ""
> > "@
> >  foo
> >  bar
> >  #"
> > [(set_attr_alternative "mnemonic" [(const_string "foo")
> >(const_string "bar")
> >(const_string "unknown")])])
> > 
> > should be equivalent.
> > 
> > Of course, the implicit method fails if the pattern is generated via C
> > statements which is way I set it manually in the initial example.  The
> > initial example contained 3 alternatives plus 1 for the generated one.
> > Setting it manually there might be feasible, however, for my actual
> > problem I have an insn with 27 alternatives where I do not want to set
> > and maintain it manually.  A side effect of setting the attribute
> > implicitly is that each mnemonic is added automatically to the mnemonic
> > hash table which I would have to do manually for my 27 alternatives
> > which I would like to avoid, too.
> > 
> > > 
> > > Also, it's unclear how PRINT_OPERAND would help with setting the 
> > > attribute.
> > 
> > For my particular problem I think one can also utilize PRINT_OPERAND
> > which I should have elaborated a bit more but feared to make the example
> > unnecessarily complicated.  The C code
> > 
> >foobar_helper (operands[0], operands[1])
> > 
> > emits actually an extended mnemonic "specialcase$VAR\t%0,%1" where $VAR
> > can be either A, B, or C.  The extended mnemonic is just syntactic sugar
> > for the base mnemonic "specialcase\t%0,%1,$IMM" which is why we can lie
> > and hard code the mnemonic attribute to specialcase since this won't
> > effect scheduling.  Since the choice which extended mnemonic should be
> > used depends only on operands[1] I thought about rewriting all this into
> > 
> > (define_insn "foobar"
> > [(set (match_operand ...)
> >   (match_operand ...))]
> > ""
> > "@
> >  foo

Re: gcc 12.4 release archive?

[Andrew Pinski via Gcc]

On Sat, Jun 22, 2024 at 3:19 AM Liviu Ionescu  wrote:
>
> Hi,
>
> GCC 12.4 was released two days ago, but I could not yet find the release 
> archive at https://ftp.gnu.org/gnu/gcc/.
>
> Could you upload it?


It is located at https://gcc.gnu.org/ftp/gcc/releases/gcc-12.4.0/ .

Looks like it was not updated to the ftp.gnu.org which required an
extra step, let me find out about that.

Thanks,
Andrew

>
> Thank you,
>
> Liviu
>
>
> > Begin forwarded message:
> >
> > From: Jakub Jelinek via gcc-announce 
> > Subject: GCC 12.4 Released
> > Date: 20 June 2024 at 12:27:10 EEST
> > To: gcc-annou...@gcc.gnu.org
> > Reply-To: Jakub Jelinek 
> >
> > The GNU Compiler Collection version 12.4 has been released.
> >
> > GCC 12.4 is a bug-fix release from the GCC 12 branch
> > containing important fixes for regressions and serious bugs in
> > GCC 12.3 with more than 84 bugs fixed since the previous release.
> >
> > This release is available from the FTP servers listed here:
> >
> >  https://sourceware.org/pub/gcc/releases/gcc-12.4.0/
> >  https://gcc.gnu.org/mirrors.html
> >
> > Please do not contact me directly regarding questions or comments
> > about this release.  Instead, use the resources available from
> > http://gcc.gnu.org.
> >
> > As always, a vast number of people contributed to this GCC release
> > -- far too many to thank them individually!
> >
>

Re: gcc 12.4 release archive?

[Liviu Ionescu]

> On 22 Jun 2024, at 22:02, Andrew Pinski  wrote:
> 
>> GCC 12.4 was released two days ago, but I could not yet find the release 
>> archive at https://ftp.gnu.org/gnu/gcc/.
>> 
>> Could you upload it?
> 
> It is located at https://gcc.gnu.org/ftp/gcc/releases/gcc-12.4.0/ .

Ok, just that this url is not advertised at https://www.gnu.org/prep/ftp.html.

> Looks like it was not updated to the ftp.gnu.org 
Is the hidden url preferable? Should I update the build scripts to get the 
archive from gcc.gnu.org/ftp, or stick to ftp.gnu.org /gnu?


Liviu

Re: gcc 12.4 release archive?

[Jonathan Wakely via Gcc]

On Sat, 22 Jun 2024, 20:41 Liviu Ionescu,  wrote:

>
>
> > On 22 Jun 2024, at 22:02, Andrew Pinski  wrote:
> >
> >> GCC 12.4 was released two days ago, but I could not yet find the
> release archive at https://ftp.gnu.org/gnu/gcc/.
> >>
> >> Could you upload it?
> >
> > It is located at https://gcc.gnu.org/ftp/gcc/releases/gcc-12.4.0/ .
>
> Ok, just that this url is not advertised at
> https://www.gnu.org/prep/ftp.html.
>

That is not a page controlled by the GCC project.


> > Looks like it was not updated to the ftp.gnu.org 
> Is the hidden url preferable? Should I update the build scripts to get the
> archive from gcc.gnu.org/ftp, or stick to ftp.gnu.org  >/gnu?
>

The GCC project makes GCC releases, not the GNU project. The mirror sites
given on the GCC website all have the release:

https://gcc.gnu.org/mirrors.html

gcc-14-20240622 is now available

[GCC Administrator via Gcc]

Snapshot gcc-14-20240622 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/14-20240622/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-14 revision 70d9d929cee3b6c7313aed62aeb4db7ae3fab59f

You'll find:

 gcc-14-20240622.tar.xz   Complete GCC

  SHA256=fb2bc3289e3e8b061c85241b53771dd1d1f7d7d225661182c6005c8360c5b986
  SHA1=33882ea720d92373ed470105806cd9b7c69e0912

Diffs from 14-20240615 are available in the diffs/ subdirectory.

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