Re: The macro STACK_BOUNDARY may overflow

2024-01-12 Thread Paul Iannetta via Gcc
On Sat, Mar 25, 2023 at 10:28:02AM -0600, Jeff Law via Gcc wrote:
> On 3/24/23 07:48, Paul Iannetta via Gcc wrote:
> > Hi,
> > 
> > Currently, the macro STACK_BOUNDARY is defined as
> > 
> >Macro: STACK_BOUNDARY
> >   Define this macro to the minimum alignment enforced by hardware for
> >   the stack pointer on this machine.  The definition is a C
> >   expression for the desired alignment (measured in bits).  This
> >   value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not
> >   defined.  On most machines, this should be the same as
> >   'PARM_BOUNDARY'.
> > 
> > with no mentions about its type and bounds.  However, at some point, the 
> > value
> > of this macro gets assigned to the field "regno_pointer_align" of "struct
> > emit_status" which points to an "unsigned char", hence if STACK_BOUNDARY 
> > gets
> > bigger than 255, it will overflow...  Thankfully, the backend which defines 
> > the
> > highest value is microblaze with 128 < 255.
> > 
> > The assignment happens in "emit-rtl.c" through the REGNO_POINTER_ALIGN 
> > macro:
> > 
> > in function.h:
> >#define REGNO_POINTER_ALIGN(REGNO) 
> > (crtl->emit.regno_pointer_align[REGNO])
> > in emit-rtl.cc:
> >REGNO_POINTER_ALIGN (STACK_POINTER_REGNUM) = STACK_BOUNDARY;
> >[...]
> >REGNO_POINTER_ALIGN (VIRTUAL_OUTGOING_ARGS_REGNUM) = STACK_BOUNDARY;
> > 
> > Would it be possible to, either add an explicit bound to STACK_BOUNDARY in 
> > the
> > manual, and/or use an "unsigned int *" rather than and "unsigned char *" for
> > the field "regno_pointer_align".
> Feel free to send a suitable patch to gcc-patches.  THe alignment data isn't
> held in the RTX structures, so it's not critical that it be kept as small as
> possible.  We don't want to waste space, so an unsigned short might be
> better.  A char was good for 30 years, so we don't need to go crazy here.
> 
> The alternative would be to change the representation to store the log2 of
> the alignment.  That would be a much larger change and would trade off
> runtime for memory consumption.  I would have suggested this approach if the
> data were in the RTX structures amd space at a premium.
> 
> While I do see a trend in processor design to reduce/remove the misalignment
> penalties (thus eliminating the driver for increasing data alignment),
> that's been primarily in high end designs.
> 
> jeff

Hi,

Here is a patch that changes the type of the variable holding the
alignment to unsigned short for the reasons outlined above.  Should I
also mention the new upper bound for STACK_BOUNDARY in the
documentation or keep it silent?

Thanks,
Paul

>8---8<
From: Paul Iannetta 
Date: Fri, 12 Jan 2024 10:18:34 +0100
Subject: [PATCH] make regno_pointer_align a unsigned short*

This changes allows to align values greater than 128 to be used for
alignment.

* emit-rtl.cc (emit_status::ensure_regno_capacity): Change
  unsigned char* to unsigned short*
(init_emit): Likewise.
* function.h (struct GTY): Likewise.
---
 gcc/emit-rtl.cc | 6 +++---
 gcc/function.h  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc
index 1856fa4884f..f0f0ad193b5 100644
--- a/gcc/emit-rtl.cc
+++ b/gcc/emit-rtl.cc
@@ -1231,9 +1231,9 @@ emit_status::ensure_regno_capacity ()
   while (reg_rtx_no >= new_size)
 new_size *= 2;
 
-  char *tmp = XRESIZEVEC (char, regno_pointer_align, new_size);
+  short *tmp = XRESIZEVEC (short, regno_pointer_align, new_size);
   memset (tmp + old_size, 0, new_size - old_size);
-  regno_pointer_align = (unsigned char *) tmp;
+  regno_pointer_align = (unsigned short *) tmp;
 
   rtx *new1 = GGC_RESIZEVEC (rtx, regno_reg_rtx, new_size);
   memset (new1 + old_size, 0, (new_size - old_size) * sizeof (rtx));
@@ -5972,7 +5972,7 @@ init_emit (void)
   crtl->emit.regno_pointer_align_length = LAST_VIRTUAL_REGISTER + 101;
 
   crtl->emit.regno_pointer_align
-= XCNEWVEC (unsigned char, crtl->emit.regno_pointer_align_length);
+= XCNEWVEC (unsigned short, crtl->emit.regno_pointer_align_length);
 
   regno_reg_rtx
 = ggc_cleared_vec_alloc (crtl->emit.regno_pointer_align_length);
diff --git a/gcc/function.h b/gcc/function.h
index 2d775b877fc..c4a20060844 100644
--- a/gcc/function.h
+++ b/gcc/function.h
@@ -72,7 +72,7 @@ struct GTY(()) emit_status {
   /* Indexed by pseudo register number, if nonzero gives the known alignment
  for that pseudo (if REG_POINTER is set in x_regno_reg_rtx).
  Allocated in parallel with x_regno_reg_rtx.  */
-  unsigned char * GTY((skip)) regno_pointer_align;
+  unsigned short * GTY((skip)) regno_pointer_align;
 };







Re: lambda coding style

2024-01-12 Thread Martin Jambor
Hi,

On Thu, Jan 11 2024, Jason Merrill wrote:
> On 1/11/24 12:48, Martin Jambor wrote:
>> On Wed, Jan 10 2024, Jason Merrill via Gcc wrote:
>>> What formatting style do we want for non-trivial lambdas in GCC sources?
>>>I'm thinking the most consistent choice would be
>>>
>>> auto l = [&] (parms) // space between ] (
>>> {  // brace on new line, indented two spaces
>>>   return stuff;
>>> };
>>>
>>> By default, recent emacs lines up the { with the previous line, like an
>>> in-class function definition; I talked it into the above indentation with
>>>
>>> (defun lambda-offset (elem)
>>> (if (assq 'inline-open c-syntactic-context) '+ 0))
>>> (add-to-hook 'c++-mode-hook '(c-set-offset 'inlambda 'lambda-offset))
>> 
>> Is this really add-to-hook and not add-hook?
>
> Oops! add-to-hook is a custom variant I wrote back in like 1992; for 
> add-hook you'll want
>
> (add-hook 'c++-mode-hook
>'(lambda () (c-set-offset 'inlambda 'lambda-offset)))
>

I see, thanks!

Martin



GCC 14.0.1 Status Report (2024-01-12), Stage 4 in effect now

2024-01-12 Thread Richard Biener via Gcc
Status
==

The GCC development branch which will become GCC 14 is now
in regression and documentation fixes only mode (Stage 4).

Please concentrate now on fixing regressions from GCC 13
and earlier.

GCC 14.1 will be released when we reach the milestone of
zero P1 regressions (note not all regressions have been
prioritized yet).


Quality Data


Priority  #   Change from last report
---   ---
P1   32   +   2
P2  504   +   5
P3  241   -   3
P4  211   -   1
P5   25
---   ---
Total P1-P3 777   +   4
Total  1013   +   3


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2023-November/242898.html


GSoc Topics

2024-01-12 Thread Gaurang Aswal via Gcc
Hey I am Gaurang Aswal a 4th year B.E. Computer Science student from BITS
Goa, India and wanted some info and insights on the Fortran projects and I
am interested in working on them. I have basic knowledge of C/C++ and I
have completed my basic computer science courses in the same language,
which included Object Oriented Programming, Data Structures and Algorithms,
Computer Architecture and Operating Systems. I would like to keep in touch
and want to know how to proceed working on the topics.


gcc-12-20240112 is now available

2024-01-12 Thread GCC Administrator via Gcc
Snapshot gcc-12-20240112 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20240112/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

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

You'll find:

 gcc-12-20240112.tar.xz   Complete GCC

  SHA256=142c1e055b435da4c5827a538b760ee7515dfb952ef24dea4db13638a8f04ab5
  SHA1=9d548dd1ff6f8d0f8039592a703c6a8444225405

Diffs from 12-20240105 are available in the diffs/ subdirectory.

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


How to compress the size of a field in a structure?

2024-01-12 Thread Hanke Zhang via Gcc
Hi, I'm attempting to compress the size of a field in a structure for
memory-friendly purposes. I created an IPA pass to achieve this, but I
ran into some issues as follows:

// original
struct Foo {
  long a1;
  int a2;
};

// modified
struct Foo_update {
  int a1;
  int a2;
};

For the example structure Foo, I use `TREE_TYPE (field) =
integer_type_node` to compress the type of a1 from `long` to `int`.

But I don't know how to update its corresponding SSA variables,
because the number of them is huge. Is there any way to do it quickly?

Thanks
Hanke Zhang