Re: [PATCH v17 2/2] c: Add __countof__ operator

[Joseph Myers via Gcc]

On Fri, 8 Nov 2024, Alejandro Colomar wrote:

> Hi Thorsten, JeanHeyd,
> 
> I've just checked that JeanHeyd opened a survey about the name.
> It's here: .
> Thanks for the survey, JeanHeyd; It's a fair one.  (The only thing I
> miss is anouncing it to some relevant publics, but I guess I'm doing it
> now, so that's ok.)  Would you mind sharing provisional results before
> Nov 18?  That's the cut-off date for having this feature in GCC 15.
> If you don't want to publish provisional results for fear of influencing
> other voters, you could share them in private.

I don't consider such survey results to be of any relevance to reviewing a 
GCC patch.  The basis for review now is what's in C2Y now (which the 
proposed patch does not follow).  If a name change is accepted in Graz 
(possibly taking into account survey results at that point), that's the 
point at which it's relevant for GCC.

-- 
Joseph S. Myers
josmy...@redhat.com

Should we move the --param documention to gccint?

[Richard Sandiford via Gcc]

We changed one of the AArch64-specific --params for GCC 14.
Unfortunately, it seems that a lot of people were relying on the
previous behaviour.

Every --param is documented in the user-facing manual, so it's not
surprising that people picked it up.  The documentation of --param
itself starts with:

---
@opindex param
@item --param @var{name}=@var{value}
In some places, GCC uses various constants to control the amount of
optimization that is done.  For example, GCC does not inline functions
that contain more than a certain number of instructions.  You can
control some of these constants on the command line using the
@option{--param} option.

The names of specific parameters, and the meaning of the values, are
tied to the internals of the compiler, and are subject to change
without notice in future releases.
---

So we can point at the last paragraph above and say "nyah, nyah, told you so".
But that isn't helpful.  The disclaimer is at the head of a huge table,
and anyone interested in tuning things is likely to find the specific
params that interest them by searching for keywords, rather than by
reading the whole text from beginning to end.  Besides, the documentation
is supposed to be there to help people, rather than be something to hit
them over the head with.

The main purpose of --params is to provide a way of controlling something
on the command line without making a long-term commitment.  That's what
separates it from things like -f and -m options, and they're clearly a
useful thing to have.  But to avoid confusion, how about moving the
documentation of the individual --params from the user-facing manual
to gccint (with a link)?

Richard

'defer' (n3199) concerns

[Alejandro Colomar via Gcc]

Hi JeanHeyd,

I was involved this week in a fix for a bug I wrote some months ago
about a call to free(3) with a bad pointer.

The simplest reproducer is:

$ cat strsep_bad.c
#include 
#include 
#include 

int
main(void)
{
char  *p;

p = strdup("123;");
strsep(&p, ";");
free(p);

puts("done");
}

$ cc -Wall -Wextra strsep.c 
$ ./a.out 
free(): invalid pointer
Aborted

A fix for that program is to store a copy of the original pointer:

$ cat strsep_good.c
#include 
#include 
#include 

int
main(void)
{
char  *p, *dup;

p = dup = strdup("123;");
strsep(&p, ";");
free(dup);

puts("done");
}

While I could sympathize with 'defer', I'm wondering if it may simplify
some code avoiding goto's, at the expense of being obscurely dangerous
in other cases like this one.  I suspect one could blindly attempt to do
the following:

$ cat strsep_bad_defer.c
#include 
#include 
#include 

int
main(void)
{
char  *p;

p = strdup("123;");
defer free(p);

strsep(&p, ";");

printf("done");
}

Since 'p' in free(p) is evaluated after strsep(3), it is equivalent to
the first program, which is bogus.  I think goto better codifies the
evaluation order, and allows the programmer to think about what it's
doing.

So defer would only be good for the common case, which is usually
simple-enough that goto should be enough.  And it's bad in those corner
cases where you really to be careful.  I think I've changed my mind
about defer to not want it.

I wanted to have this thought written in a mailing list to be able to
reference it.


Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Re: 'defer' (n3199) concerns

[Martin Uecker via Gcc]

Am Freitag, dem 08.11.2024 um 16:40 +0100 schrieb Alejandro Colomar via Gcc:
> Hi JeanHeyd,
> 
> I was involved this week in a fix for a bug I wrote some months ago
> about a call to free(3) with a bad pointer.
> 
> The simplest reproducer is:
> 
>   $ cat strsep_bad.c
>   #include 
>   #include 
>   #include 
> 
>   int
>   main(void)
>   {
>   char  *p;
> 
>   p = strdup("123;");
>   strsep(&p, ";");
>   free(p);
> 
>   puts("done");
>   }
> 
>   $ cc -Wall -Wextra strsep.c 
>   $ ./a.out 
>   free(): invalid pointer
>   Aborted
> 
> A fix for that program is to store a copy of the original pointer:
> 
>   $ cat strsep_good.c
>   #include 
>   #include 
>   #include 
> 
>   int
>   main(void)
>   {
>   char  *p, *dup;
> 
>   p = dup = strdup("123;");
>   strsep(&p, ";");
>   free(dup);
> 
>   puts("done");
>   }
> 
> While I could sympathize with 'defer', I'm wondering if it may simplify
> some code avoiding goto's, at the expense of being obscurely dangerous
> in other cases like this one.  I suspect one could blindly attempt to do
> the following:
> 
>   $ cat strsep_bad_defer.c
> #include 
> #include 
> #include 
> 
> int
> main(void)
> {
> char  *p;
> 
> p = strdup("123;");
>   defer free(p);
> 
> strsep(&p, ";");
> 
> printf("done");
> }
> 
> Since 'p' in free(p) is evaluated after strsep(3), it is equivalent to
> the first program, which is bogus.  I think goto better codifies the
> evaluation order, and allows the programmer to think about what it's
> doing.
> 
> So defer would only be good for the common case, which is usually
> simple-enough that goto should be enough.  And it's bad in those corner
> cases where you really to be careful.  I think I've changed my mind
> about defer to not want it.
> 
> I wanted to have this thought written in a mailing list to be able to
> reference it.

When we wrote the original proposal for C23 Robert had a collection
of code examples before and after rewriting to use defer.  At that
time I somewhat lost a bit of interest in the feature ;-)   But many 
people seem to like it.   I think it would be useful to revisit
these (and more) realistic code examples to get some clarity.

Martin

Re: 'defer' (n3199) concerns

[Serge Hallyn]

Nov 8, 2024 09:41:00 Alejandro Colomar :

> Hi JeanHeyd,
>
> I was involved this week in a fix for a bug I wrote some months ago
> about a call to free(3) with a bad pointer.
>
> The simplest reproducer is:
>
>     $ cat strsep_bad.c
>     #include 
>     #include 
>     #include 
>
>     int
>     main(void)
>     {
>     char  *p;
>
>     p = strdup("123;");
>     strsep(&p, ";");
>     free(p);
>
>     puts("done");
>     }
>
>     $ cc -Wall -Wextra strsep.c
>     $ ./a.out
>     free(): invalid pointer
>     Aborted
>
> A fix for that program is to store a copy of the original pointer:
>
>     $ cat strsep_good.c
>     #include 
>     #include 
>     #include 
>
>     int
>     main(void)
>     {
>     char  *p, *dup;
>
>     p = dup = strdup("123;");
>     strsep(&p, ";");
>     free(dup);
>
>     puts("done");
>     }
>
> While I could sympathize with 'defer', I'm wondering if it may simplify
> some code avoiding goto's, at the expense of being obscurely dangerous
> in other cases like this one.  I suspect one could blindly attempt to do
> the following:
>
>     $ cat strsep_bad_defer.c
>     #include 
>     #include 
>     #include 
>
>     int
>     main(void)
>     {
>     char  *p;
>
>     p = strdup("123;");
>     defer free(p);
>
>     strsep(&p, ";");
>
>     printf("done");
>     }
>
> Since 'p' in free(p) is evaluated after strsep(3), it is equivalent to
> the first program, which is bogus.  I think goto better codifies the
> evaluation order, and allows the programmer to think about what it's
> doing.
>

lol yeah every time I deal with defer in go (and there have been some baroque 
instances) i have to write some tests to make sure I've got the behavior right.


> So defer would only be good for the common case, which is usually
> simple-enough that goto should be enough.  And it's bad in those corner
> cases where you really to be careful.  I think I've changed my mind
> about defer to not want it.
>
> I wanted to have this thought written in a mailing list to be able to
> reference it.
>
>
> Have a lovely day!
> Alex
>
> --
> 

gcc-13-20241108 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-13-20241108.tar.xz   Complete GCC

  SHA256=91ae3fe409dfc025d2f36c9af50af27433e59bd4b93f7e3a4dad71d5290afb8c
  SHA1=c3cc8cbb2ff50eb15b034db29330280eaf67f61f

Diffs from 13-20241101 are available in the diffs/ subdirectory.

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

Re: [PATCH v17 2/2] c: Add __countof__ operator

[Alejandro Colomar via Gcc]

Hi Joseph,

On Fri, Nov 08, 2024 at 03:54:51PM GMT, Joseph Myers wrote:
> On Fri, 8 Nov 2024, Alejandro Colomar wrote:
> 
> > Hi Thorsten, JeanHeyd,
> > 
> > I've just checked that JeanHeyd opened a survey about the name.
> > It's here: .
> > Thanks for the survey, JeanHeyd; It's a fair one.  (The only thing I
> > miss is anouncing it to some relevant publics, but I guess I'm doing it
> > now, so that's ok.)  Would you mind sharing provisional results before
> > Nov 18?  That's the cut-off date for having this feature in GCC 15.
> > If you don't want to publish provisional results for fear of influencing
> > other voters, you could share them in private.
> 
> I don't consider such survey results to be of any relevance to reviewing a 
> GCC patch.  The basis for review now is what's in C2Y now (which the 
> proposed patch does not follow).  If a name change is accepted in Graz 
> (possibly taking into account survey results at that point), that's the 
> point at which it's relevant for GCC.

Fair enough.  For now, I keep it for GCC 16.  Adding _Lengthof now to
GCC 15 may jeopardize my attempt to rename it in Graz, so I'll play my
cards.  If I see survey results that don't seem good for my renaming
attempts, I may reconsider and send _Lengthof next week; but for now I
have some hope.  :-)

BTW, I'm nevertheless going to rebase my patch, to test with the changes
that Martin did to arrays of 0 elements.  I may send another revision of
the _Countof patch set, just for having it in the list, but you can just
ignore it.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Secondary reload and pseudos

[Stefan Schulze Frielinghaus via Gcc]

Hi all,

For older s390 machines, which do not support vector extensions, I'm trying to
implement 2-byte GPR<->FPR moves.  Since GPRs are right-aligned and FPRs
left-aligned I cannot trivially copy between them.  However, at least since
z9-ec (TARGET_DFP) we have instructions ldgr/lgdr in order to move 8-byte
values between GPRs and FPRs.  A 2-byte GPR into FPR move could be implemented
by shifting the input GPR by 48 bit and storing the result in a scratch GPR
which is then finally copied as an 8-byte move into an FPR.  This means,
for a GPR into FPR move I need a scratch register which I could
allocated during reload.  So far I came up with

if (TARGET_DFP && !TARGET_VX && GET_MODE_SIZE (mode) == 2
&& ((in_p && (REG_P (x) || (SUBREG_P (x) && REG_P (SUBREG_REG (x
 && reg_classes_intersect_p (rclass, FP_REGS))
|| (!in_p && FP_REGNO_P (true_regnum (x))
&& reg_classes_intersect_p (rclass, GENERAL_REGS
  {
sri->icode = CODE_FOR_reload_half_into_fpr;
return NO_REGS;
  }

in TARGET_SECONDARY_RELOAD and the corresponding expander

(define_expand "reload_half_into_fpr"
  [(parallel [(match_operand0 "register_operand" "=f")
  (match_operand1 "register_operand"  "d")
  (match_operand:DI 2 "register_operand" "=d")])]
  "TARGET_DFP"
{
  gcc_assert (FP_REGNO_P (true_regnum (operands[0])));
  operands[1] = simplify_gen_subreg (DImode, operands[1], GET_MODE 
(operands[1]), 0);
  emit_insn (gen_rtx_SET (operands[2], operands[1]));
  emit_insn (gen_rtx_SET (operands[2], gen_rtx_ASHIFT (DImode, operands[2], 
GEN_INT (48;
  operands[2] = simplify_gen_subreg (DFmode, operands[2], GET_MODE 
(operands[2]), 0);
  emit_insn (gen_rtx_SET (gen_rtx_REG (DFmode, true_regnum (operands[0])), 
operands[2]));
  DONE;
})

This works for some minimal examples but bootstrap fails in lra_assign()

if (! lra_hard_reg_split_p && ! lra_asm_error_p && flag_checking)
  /* Check correctness of allocation but only when there are no hard reg
 splits and asm errors as in the case of errors explicit insns involving
 hard regs are added or the asm is removed and this can result in
 incorrect allocation.  */
  for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
if (lra_reg_info[i].nrefs != 0
&& reg_renumber[i] >= 0
&& overlaps_hard_reg_set_p (lra_reg_info[i].conflict_hard_regs,
PSEUDO_REGNO_MODE (i), reg_renumber[i]))
  gcc_unreachable ();

where we have for a reduced test and pseudo 68

(gdb) print reg_renumber[68]
$2 = 25
(gdb) call debug_hard_reg_set (lra_reg_info[68].conflict_hard_regs)
 0-5 12 14-23 25 33 35 38-53

which is why gcc_unreachable() fires.

To get straight to the point I fear that in the expander the final assignment to
gen_rtx_REG (DFmode, true_regnum (operands[0])) might be problematic.  In
reloads dump I see that in the expander I'm finally not writing into the former
target namely pseudo 68 but in its designated hard register f10 due to
true_regnum():

   70: r68:HF=r91:HF
  REG_DEAD r91:HF
Inserting the move before:
   93: r102:DI=r91:HF#0
   94: r102:DI=r102:DI<<0x30
   95: %f10:DF=r102:DI#0

Deleting move 70
   70: r68:HF=r91:HF
  REG_DEAD r91:HF
deleting insn with uid = 70.

I fear that this might have consequences while determining liveness et al. for
pseudo 68.  Long story short: am I allowed to write into the designated hard
register instead of its corresponding pseudo?

The tricky part seems to be that the initial mode of the target FPR is a 2-byte
mode, however, in the end I have to emit a move insn with an 8-byte mode.  If
the target FPR is a hard reg I'm allowed to change the mode.  However, in case 
of
a pseudo I cannot use a subreg since this would lead to infinite recursive
reloads.  This leaves me with assigning to its designated hard reg
gen_rtx_REG (DFmode, true_regnum (operands[0])) which might interfere with the
liveness (or whatever) of its corresponding pseudo.

In order to shift around this and enforce a hard register I went for allocating
a scratch register during secondary reload and a splitter which triggers after
reload where I'm certain that I only deal with hard registers, i.e., something
along the lines

(define_expand "reload_half_into_fpr"
  [(parallel [(match_operand0 "register_operand" "=f")
  (match_operand1 "register_operand"  "d")
  (match_operand:DI 2 "register_operand" "=d")])]
  "TARGET_DFP"
{
  emit_insn (gen_reload_half_into_fpr_helper (operands[0], operands[1], 
operands[2]));
  DONE;
})

(define_insn_and_split "reload_half_into_fpr_helper"
  [(set (match_operand 0 "register_operand" "=f")
(unspec [(match_operand1 "register_operand"  "d")
 (match_operand:DI 2 "register_operand" "=d")]
UNSPEC_GPRTOFPR))]
  "TARGET_DFP"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  emit_insn (gen_rtx_SET (operands[2], gen_rtx_REG (DImode, REGNO 
(oper

Re: Sourceware forge experiment

[Mark Wielaard]

Hi Eric,

On Thu, 2024-10-24 at 15:44 -0400, Eric Gallager wrote:
> On Sun, Oct 20, 2024 at 9:27 PM Mark Wielaard  wrote:
> > As an experiment Sourceware is now running an forgejo v9 instance at
> > https://forge.sourceware.org
> > 
> > Everybody with an @sourceware.org, @cygwin.com or @gcc.gnu.org address
> > can register an account (please use the same user name as your account
> > name).
> > 
> > The setup has disabled most "extras" (no badges, stars, issues, wikis,
> > packages, timetracking, milestones, etc.). And users can only fork
> > existing repos (it has mirrors of various sourceware projects).
> 
> Is the intent to get mirrors of all of them on there at some point?
> I'm only seeing a few at the moment...

To see how well it scales a couple more sourceware projects now have a
mirror on the forge: https://forge.sourceware.org/explore/organizations
gcc, binutils-gdb, glibc, elfutils, newlib, valgrind, debugedit,
bunsen, annobin, bzip2, cgen, dwz, insight, libabigail and systemtap.

If you are interested in others, please just ask.
https://sourceware.org/projects.html

> > There is also a new mailinglist for discussion about the setup and the
> > best way to create a pull-request workflow. Please subscribe if you
> > create an account and mention which project/organization you would
> > like do some experiments for. We can then add you to that organization.
> > 
> 
> ...is subscribing necessary? I'm trying to limit my subscriptions...
> 
> > https://sourceware.org/mailman/listinfo/forge

It isn't necessary, but it is a good place to discuss the forge
experiment. You don't have to be subscribed to post and you can read
the archives through https://inbox.sourceware.org/forge (also through
nntp, imap, atom or git cloning the whole thing).

Cheers,

Mark

Re: [PATCH v17 2/2] c: Add __countof__ operator

[Alejandro Colomar via Gcc]

Hi Thorsten, JeanHeyd,

I've just checked that JeanHeyd opened a survey about the name.
It's here: .
Thanks for the survey, JeanHeyd; It's a fair one.  (The only thing I
miss is anouncing it to some relevant publics, but I guess I'm doing it
now, so that's ok.)  Would you mind sharing provisional results before
Nov 18?  That's the cut-off date for having this feature in GCC 15.
If you don't want to publish provisional results for fear of influencing
other voters, you could share them in private.

Have a lovely day!
Alex

On Mon, Oct 28, 2024 at 01:34:04AM GMT, Thorsten Glaser wrote:
> Alejandro Colomar dixit:
> 
> >Yes; there are four n papers.  See below, plus the history of why
> >four papers.
> 
> Thanks, will look at them but probably on Tuesday.
> 
> >> >-  _Nelementsof
> >> >-  _Nelemsof
> >>
> >> If you want to shorten elements, elts is probably seen more
> >> often than elems, at least in my experience. But this is very
> >> low-grade bikeshedding, so just me pointing it out but putting
> >> not much weight behind it.
> >
> >That was my original proposal, but everybody I've talked so far told me
> >they preferred _Nelemsof.  I don't care about it at all, so whatever.
> 
> Ah, okay.
> 
> >> PS: Got any contacts in the OpenBSD and NetBSD worlds that can
> >> add input? They invest a lot into good C code as well, in
> >> the OpenBSD case rather heavily (if opinionated).
> >
> >I don't.  If you do, please let them know.  Theo doesn't seem to have a
> >good opinion of me, but maybe he could help.
> 
> I fear we share this property but I can try to reach out via
> Miod, he might have an idea, and via bsiegert to NetBSD.
> 
> bye,
> //mirabilos

-- 



signature.asc
Description: PGP signature

VLA representation in GCC internals

[Alejandro Colomar via Gcc]

Hi Martin,

I'm in the process of rebasing my __countof__ changes after your patch
that fixes support for [*] and [0].

I should update the implementation of the following function:

static bool
is_top_array_vla (tree type)
{
  bool zero, star, var;
  tree d;

  if (TREE_CODE (type) != ARRAY_TYPE)
return false;
  if (!COMPLETE_TYPE_P (type))
return false;

  d = TYPE_DOMAIN (type);
  zero = !TYPE_MAX_VALUE (d);
  star = (zero && C_TYPE_VARIABLE_SIZE (type));
  if (star)
return true;
  if (zero)
return false;

  var = (TREE_CODE (TYPE_MIN_VALUE (d)) != INTEGER_CST
|| TREE_CODE (TYPE_MAX_VALUE (d)) != INTEGER_CST);
  return var;
}

The 'star' calculation should be updated.  Would you mind proposing an
implementation of this function that works with your changes?  Thanks!

Have a lovely night!
Alex


-- 



signature.asc
Description: PGP signature

Re: [PATCH v17 2/2] c: Add __countof__ operator

[Thorsten Glaser]

On Fri, 8 Nov 2024, Alejandro Colomar wrote:

>I've just checked that JeanHeyd opened a survey about the name.
>It's here: .

Yes, I saw it on Fedi, where it was announced big, and filled it in.

Thanks,
//mirabilos
-- 
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that there is no makefile │ but somehow the Build.sh is
the least painful built system i've ever seen │ honours CC, {CPP,C,LD}FLAGS
properly │ looks cleary like done by someone who knows what they are doing