Re: Linux kernel: "mm: uninline copy_overflow()" breaks i386 build in Mellanox MLX4

[Richard Biener via Gcc]

On Thu, 9 Jun 2022, Mateusz Jończyk wrote:

> W dniu 26.04.2022 o 01:13, Jason Gunthorpe pisze:
> > On Thu, Apr 21, 2022 at 10:47:01PM +0200, Mateusz Jończyk wrote:
> >> Hello,
> >>
> >> commit ad7489d5262d ("mm: uninline copy_overflow()")
> >>
> >> breaks for me a build for i386 in the Mellanox MLX4 driver:
> >>
> >>     In file included from ./arch/x86/include/asm/preempt.h:7,
> >>  from ./include/linux/preempt.h:78,
> >>  from ./include/linux/percpu.h:6,
> >>  from ./include/linux/context_tracking_state.h:5,
> >>  from ./include/linux/hardirq.h:5,
> >>  from drivers/net/ethernet/mellanox/mlx4/cq.c:37:
> >>     In function ‘check_copy_size’,
> >>     inlined from ‘copy_to_user’ at ./include/linux/uaccess.h:159:6,
> >>     inlined from ‘mlx4_init_user_cqes’ at 
> >> drivers/net/ethernet/mellanox/mlx4/cq.c:317:9,
> >>     inlined from ‘mlx4_cq_alloc’ at 
> >> drivers/net/ethernet/mellanox/mlx4/cq.c:394:10:
> >>     ./include/linux/thread_info.h:228:4: error: call to 
> >> ‘__bad_copy_from’ declared with attribute error: copy source size is too 
> >> small
> >>   228 |    __bad_copy_from();
> >>   |    ^
> >>     make[5]: *** [scripts/Makefile.build:288: 
> >> drivers/net/ethernet/mellanox/mlx4/cq.o] Błąd 1
> >>     make[4]: *** [scripts/Makefile.build:550: 
> >> drivers/net/ethernet/mellanox/mlx4] Błąd 2
> >>     make[3]: *** [scripts/Makefile.build:550: 
> >> drivers/net/ethernet/mellanox] Błąd 2
> >>     make[2]: *** [scripts/Makefile.build:550: drivers/net/ethernet] 
> >> Błąd 2
> >>     make[1]: *** [scripts/Makefile.build:550: drivers/net] Błąd 2
> >>
> >> Reverting this commit fixes the build. Disabling Mellanox Ethernet drivers
> >> in Kconfig (tested only with also disabling of all Infiniband support) 
> >> also fixes the build.
> >>
> >> It appears that uninlining of copy_overflow() causes GCC to analyze the 
> >> code deeper.
> > This looks like a compiler bug to me, array_size(entries, cqe_size)
> > cannot be known at compile time, so the __builtin_constant_p(bytes)
> > should be compile time false meaning the other two bad branches should
> > have been eliminated.
> >
> > Jason
> 
> Hello,
> 
> This problem also exists in Linux v5.19-rc1. Compiling with GCC 8 and GCC 9 
> fails,
> but with GCC10 it compiles successfully.
> 
> I have extracted a standalone code snippet that triggers this bug, attaching
> it at the bottom of this e-mail.
> 
> This indeed looks like a compiler bug for me, as cqe_size cannot be known at 
> compile
> time. What is interesting, replacing
> 
>     err = copy_to_user2((void  *)buf, init_ents,
>     size_mul2(4096, cqe_size)) ? -14 : 0;
> 
> with
> 
>     err = copy_to_user2((void  *)buf, init_ents,
>     4096 * cqe_size) ? -14 : 0;
> 
> makes the code compile successfully.
> 
> I have bisected GCC to find which commit in GCC fixes this problem and
> obtained this:
> 
>     46dfa8ad6c18feb45d35734eae38798edb7c38cd is the first fixed commit
>     commit 46dfa8ad6c18feb45d35734eae38798edb7c38cd
>     Author: Richard Biener 
>     Date:   Wed Sep 11 11:16:54 2019 +
> 
>     re PR tree-optimization/90387 (__builtin_constant_p and 
> -Warray-bounds warnings)
> 
>     2019-09-11  Richard Biener  
> 
>     PR tree-optimization/90387
>     * vr-values.c (vr_values::extract_range_basic): After 
> inlining
>     simplify non-constant __builtin_constant_p to false.
> 
>     * gcc.dg/Warray-bounds-44.c: New testcase.
> 
>     From-SVN: r275639
> 
>  gcc/ChangeLog   |  6 ++
>  gcc/testsuite/ChangeLog |  5 +
>  gcc/testsuite/gcc.dg/Warray-bounds-44.c | 23 +++
>  gcc/vr-values.c | 11 ++-
>  4 files changed, 36 insertions(+), 9 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/Warray-bounds-44.c
> 
> Applying this patch on top of releases/gcc-9.5.0 fixes the build (of the 
> attached snippet and of
> drivers/net/ethernet/mellanox/mlx4/cq.c ).
> 
> Ccing Mr Richard Biener, as he is the author of this patch.

Note the patch simply avoids some instances of path isolation with
__builtin_constant_p by committing to constant/non-constant earlier.

Think of

 for (i = 0; i < n; ++i)
   if (__builtin_constant_p (i)) foo (); else bar ();

and GCC peeling the first iteration - then to GCC i is constant zero
in this first iteration but the remaining iterations will have i
non-constant.

The semantics of __builtin_constant_p are not strongly enough
defined to say whether that's "correct" or not given the
documentation suggests it is evaluated after optimization
(inlinin

Re: [RFC] Support for nonzero attribute

[Richard Biener via Gcc]

On Sat, Jun 4, 2022 at 12:27 PM Yair Lenga via Gcc  wrote:
>
> Before becoming a "C" programmer, I spent few years building simulations in
> Pascal. I still remember (and long for) the ability to define integer with
> range constraints:
>
> var foobar: 10..50 ; // Accept 10, 11, 12, ..., 49, 50

Just noting this is a range on a variable declaration while ...

> The specific non-zero constraint is a specific implementation of the range
> operator (with some exception see below). Wanted to suggest going for
> more ambitious goal: add min and max attributes to (integer) types and
> variables. This will address the specific case of non-zero, but has a lot
> of potential to be built upon: can be used for compile time testing, run
> time parameter checking, storage optimization (similar to packed), run time
> optimization (e.g. eliminating runtime tests),  Also expected range
> information can have a positive impact on code safety/validation.
>
> typedef int postivieInt __attribute__ (minValue(1), maxValue(INTMAX) ;
> typedef int foobar __attribute__ ((minValue(10), maxValue(50)) ;

... this would be on a type.  GCC internally has TYPE_{MIN,MAX}_VALUE
but no such thing on declarations which means that either the
attribute should be restricted to types or it would need to create distinct
types on-the-fly when applied to declarations.  I'm sure Ada supports something
similar btw.

Richard.

> If this can be implemented, it will provide for much more
> flexibility (e.g., ability to specify that any specific parameter must be
> non-zero).
>
> int foo (int x __attribute__ (minValue(1)), int y, int z __attribute__
> (minValue(1))  ;
>
> int foo (positiveInt x, int y, positiveInt y) ;
>
> Assuming this can be implemented, compile time tests should be automatic,
> whenever possible. Run time tests should be enabled with flags (to allow
> optimized code to run without expensive run time tests).
>
> Note1:
> While for many use cases non-zero (including  forcing ENUM value, and
> minValue(1) are the same, the above does not cover the user case where a
> signed int does not accept a zero. For this use case, I believe the nonZero
> attribute is still needed.
>
> typedef int limitedInt __attribute((minValue(-20)), maxValue(+20), nonZero)
>
> I do recall that few other languages had similar abilities (Ada, Java (via
> annotations), ...)
>
> Yair
>
>
> >
> >
> >
> > -- Forwarded message --
> > From: Miika 
> > To: "gcc@gcc.gnu.org" 
> > Cc:
> > Bcc:
> > Date: Fri, 03 Jun 2022 16:34:48 +
> > Subject: [RFC] Support for nonzero attribute
> > Hello,
> >
> > I would like to add support for new attribute: nonzero.
> > Nonzero attribute works the same way as nonnull but instead of checking for
> > NULL, it checks for integer or enum with value 0.
> >
> > Nonzero attribute would issue warnings with new compiler flag
> > -Wnonzero and -Wnonzero-compare.
> >
> > Nonzero could be useful when user wants to make sure that for example enum
> > with value of 0 is not used or flag argument is not set to 0.
> >
> >
> > For example compiling following code with "gcc -Wnonzero -Wnonzero-compare
> > foo.c"
> >
> > #include 
> > enum bar{NONE, SOME};
> >
> > void foo(int d, enum bar b) __attribute__ ((nonzero (1, 2)));
> > void foo(int d, enum bar b) {
> > printf("%d\n", d == 0);
> > printf("%d\n", b == NONE);
> > }
> >
> > int main() {
> > foo(0, NONE);
> > }
> >
> >
> > Would give the following error
> >
> > foo.c: In function 'main':
> > foo.c:11:9: warning: zero argument where nonzero required (argument 1)
> > [-Wnonzero]
> >11 | foo(0, NONE);
> >   | ^~~
> > ...

Re: GSoC Blog Post 0 - GCCprefab build system

[Jonathan Wakely via Gcc]

On Mon, 13 Jun 2022 at 02:51, Wileam Yonatan Phan via Gcc
 wrote:
>
> Hi everyone,
>
> This weekend marks the end of the community bonding period for GSoC '22, and
> here’s my progress so far with the GSoC project on Fortran DO CONCURRENT.
>
> I've initialized a GCC mirror on GitHub where I plan to track all patches that
> I will create during the GSoC:
> 
>
> I met with Tobias over a MS Teams call on May 30, 2022. Together, we picked 
> GCC
> PR# 102003 as a good starter issue to start delving into the Fortran parser in
> GCC. He also guided me through how to debug the compiler using gdb. Tobias,
> thanks a lot for spending some of your (technically) vacation time with me!
>
> In the meantime, I’ve implemented a simple build script system for GCC that I
> christen "GCCprefab". Before this build system existed, there are only two
> relatively easy ways to build GCC painlessly:
>
> 1. Using Spack package manager: `spack install gcc'
> 2. Using the install script for OpenCoarrays
> 

I disagree there are "only two" ways.

https://gcc.gnu.org/wiki/InstallingGCC describes an arguably much simpler way.

[RFC] Support for nonzero attribute

[Miika via Gcc]

Thank you for the feedback!

On Sunday, June 12th, 2022 at 7:25 AM, Prathamesh Kulkarni 
 wrote:
> On Mon, 6 Jun 2022 at 01:39, Miika via Gcc gcc@gcc.gnu.org wrote:
>
> > Based on Jakub's and Yair's comments I created a new attribute "inrange".
> > Inrage takes three arguments, pos min and max.
> > Pos being the argument position in the function, and min and max defines the
> > range of valid integer. Both min and max are inclusive and work with enums.
> > Warnings are enabled with the new flag: "-Winrange".
> >
> > The attribute definition would look something like this:
> > inrange(pos, min, max)
> >
> > So for example compiling this with "gcc foo.c -Winrange":
> >
> > #include 
> > void foo(int d) attribute ((inrange (1, 100, 200)));
> > void foo(int d) {
> > printf("%d\n", d == 0);
> > }
> >
> > int main() {
> > foo(0); // warning
> > foo(100); // no warning
> > }
> >
> > Would give the following error:
> >
> > foo.c: In function 'main':
> > foo.c:8:9: warning: argument in position 1 not in rage of 100..200 
> > [-Winrange]
> > 8 | foo(0); // warning
> > | ^~~
> >
> > I thought about having separate minval and maxval attributes but I 
> > personally
> > prefer that min and max values have to be defined explicitly.
> >
> > If this looks good, I could look into applying inrange to types and 
> > variables
> > and after that I could start looking into optimization.
> >
> > Patch for adding inrange is attached below
>
> Hi,
> Thanks for the POC patch!
> A few suggestions:
>
> (1) It doesn't apply as-is because of transition from .c to .cc filenames.
> Perhaps you're using an older version of trunk ?

I was using an older version. I should've created the patch based on the
master branch. My bad!

> (2) AFAIK, this warning will need an entry in doc/invoke.texi for
> documenting it.

Good point. I'll write up some documentation.

> (3) While this patch addresses warning, I suppose it could be extended
> so the tree optimizer
> can take advantage of value range info provided by the attribute.
> For example, the condition d > 20, could be optimized away in
>
> following function by inferring
> range from the attribute.
>
> attribute((inrange (1, 10, 20)))
> void foo(int d)
> {
> if (d > 20)
>
> __builtin_abort ();
> }

I agree. I'll try to add this too.

> > Miika
> >
> > ---
> > diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
> > index 3239311b5a4..2f5732b3ed2 100644
> > --- a/gcc/builtin-attrs.def
> > +++ b/gcc/builtin-attrs.def
> > @@ -98,6 +98,7 @@ DEF_ATTR_IDENT (ATTR_FORMAT, "format")
> > DEF_ATTR_IDENT (ATTR_FORMAT_ARG, "format_arg")
> > DEF_ATTR_IDENT (ATTR_MALLOC, "malloc")
> > DEF_ATTR_IDENT (ATTR_NONNULL, "nonnull")
> > +DEF_ATTR_IDENT (ATTR_INRANGE, "inrange")
> > DEF_ATTR_IDENT (ATTR_NORETURN, "noreturn")
> > DEF_ATTR_IDENT (ATTR_NOTHROW, "nothrow")
> > DEF_ATTR_IDENT (ATTR_LEAF, "leaf")
> > diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> > index ac936d5..d6dc9c37723 100644
> > --- a/gcc/c-family/c-attribs.c
> > +++ b/gcc/c-family/c-attribs.c
> > @@ -119,6 +119,7 @@ static tree handle_novops_attribute (tree *, tree, 
> > tree, int, bool *);
> > static tree handle_vector_size_attribute (tree *, tree, tree, int,
> > bool *);
> > static tree handle_nonnull_attribute (tree *, tree, tree, int, bool *);
> > +static tree handle_inrange_attribute (tree *, tree, tree, int, bool *);
> > static tree handle_nonstring_attribute (tree *, tree, tree, int, bool *);
> > static tree handle_nothrow_attribute (tree *, tree, tree, int, bool *);
> > static tree handle_cleanup_attribute (tree *, tree, tree, int, bool *);
> > @@ -379,6 +380,8 @@ const struct attribute_spec c_common_attribute_table[] =
> > handle_tls_model_attribute, NULL },
> > { "nonnull", 0, -1, false, true, true, false,
> > handle_nonnull_attribute, NULL },
> > + { "inrange", 3, 3, false, true, true, false,
> > + handle_inrange_attribute, NULL },
> > { "nonstring", 0, 0, true, false, false, false,
> > handle_nonstring_attribute, NULL },
> > { "nothrow", 0, 0, true, false, false, false,
> > @@ -3754,6 +3757,59 @@ handle_nonnull_attribute (tree *node, tree name,
> > return NULL_TREE;
> > }
> >
> > +/* Handle the "inrange" attribute. */
> > +
> > +static tree
> > +handle_inrange_attribute (tree *node, tree name,
> > + tree args, int ARG_UNUSED (flags),
> > + bool *no_add_attrs)
> > +{
> > + tree type = node;
> > +
> > + / Test the position argument */
> > + tree pos = TREE_VALUE (args);
> > + if (!positional_argument (type, name, pos, INTEGER_TYPE, 0))
> > + no_add_attrs = true;
> > +
> > + / Make sure that range args are INTEGRALs */
> > + bool range_err = false;
> > + for (tree range = TREE_CHAIN (args); range; range = TREE_CHAIN (range))
> > + {
> > + tree val = TREE_VALUE (range);
> > + if (val && TREE_CODE (val) != IDENTIFIER_NODE
> > + && TREE_CODE (val) != FUNCTION_DECL)
> > + val = default_conversion (val);
> > +
> > + if (TREE_CODE (val) != INTEGER_CST
> > + || !INTEGRAL_TYPE_P (TREE_TYPE (val)))
>
> Um, why the 

Re: GSoC Blog Post 0 - GCCprefab build system

[Jonathan Wakely via Gcc]

On Mon, 13 Jun 2022 at 14:34, Wileam Yonatan Phan wrote:
>
> Hi Jonathan,
>
> Thanks for the feedback. Regarding the linked page <
> https://gcc.gnu.org/wiki/InstallingGCC>
> if you're referring to the part that tells you to use your distro's package
> manager, yes that's indeed the simplest way to install GCC, but from pre-built
> binaries, not building directly from sources. But if you're referring to the
> example at the bottom of the page,

Yes, that's what I mean.

> this script does exactly that, but the build
> process is automated based on the build configuration file.

Yes, it does that, but takes 400 lines of shell script to do so.

If you want "relatively easy ways to build GCC painlessly" then you
can do it with nine lines of shell commands.

Or in about 80, for any non-prehistoric version, with no config file
needed (just a single option to the script, the release number or
snapshot name to build):
https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh

My point is just that there are already easier ways to do it, not only
by using spack or the OpenCoarrays build script.

N.B. your https://github.com/wyphan/gccprefab/blob/main/gcc12.cfg
config file says "Latest GCC 12 Release" but actually builds from the
tip of the branch, not a release.

Re: [C2x] Disallow function attributes after function identifier

[Jonathan Wakely via Gcc]

On Sat, 11 Jun 2022 at 21:17, Alejandro Colomar wrote:
> P.S.: Please consider deprecating 'auto' some day.  It would be nice to
> see C++'s auto in ISO C some day, even if it's 2060.  I'm not entirely
> happy doing `#define auto __auto_type` (of course it's UB, but it's nice) ;)

There's a proposal, but it leaves it open whether to standardize it as
"auto" or "__auto_type".

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2953.htm

Re: [RFC] Support for nonzero attribute

[Martin Sebor via Gcc]

On 6/13/22 06:55, Miika via Gcc wrote:

Thank you for the feedback!

On Sunday, June 12th, 2022 at 7:25 AM, Prathamesh Kulkarni 
 wrote:

On Mon, 6 Jun 2022 at 01:39, Miika via Gcc gcc@gcc.gnu.org wrote:


Based on Jakub's and Yair's comments I created a new attribute "inrange".
Inrage takes three arguments, pos min and max.
Pos being the argument position in the function, and min and max defines the
range of valid integer. Both min and max are inclusive and work with enums.
Warnings are enabled with the new flag: "-Winrange".

The attribute definition would look something like this:
inrange(pos, min, max)

So for example compiling this with "gcc foo.c -Winrange":

#include 
void foo(int d) attribute ((inrange (1, 100, 200)));
void foo(int d) {
printf("%d\n", d == 0);
}

int main() {
foo(0); // warning
foo(100); // no warning
}

Would give the following error:

foo.c: In function 'main':
foo.c:8:9: warning: argument in position 1 not in rage of 100..200 [-Winrange]
8 | foo(0); // warning
| ^~~

I thought about having separate minval and maxval attributes but I personally
prefer that min and max values have to be defined explicitly.

If this looks good, I could look into applying inrange to types and variables
and after that I could start looking into optimization.

Patch for adding inrange is attached below


Hi,
Thanks for the POC patch!
A few suggestions:

(1) It doesn't apply as-is because of transition from .c to .cc filenames.
Perhaps you're using an older version of trunk ?


I was using an older version. I should've created the patch based on the
master branch. My bad!


(2) AFAIK, this warning will need an entry in doc/invoke.texi for
documenting it.


Good point. I'll write up some documentation.


(3) While this patch addresses warning, I suppose it could be extended
so the tree optimizer
can take advantage of value range info provided by the attribute.
For example, the condition d > 20, could be optimized away in

following function by inferring
range from the attribute.

attribute((inrange (1, 10, 20)))
void foo(int d)
{
if (d > 20)

__builtin_abort ();
}


I agree. I'll try to add this too.


Miika

---
diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
index 3239311b5a4..2f5732b3ed2 100644
--- a/gcc/builtin-attrs.def
+++ b/gcc/builtin-attrs.def
@@ -98,6 +98,7 @@ DEF_ATTR_IDENT (ATTR_FORMAT, "format")
DEF_ATTR_IDENT (ATTR_FORMAT_ARG, "format_arg")
DEF_ATTR_IDENT (ATTR_MALLOC, "malloc")
DEF_ATTR_IDENT (ATTR_NONNULL, "nonnull")
+DEF_ATTR_IDENT (ATTR_INRANGE, "inrange")
DEF_ATTR_IDENT (ATTR_NORETURN, "noreturn")
DEF_ATTR_IDENT (ATTR_NOTHROW, "nothrow")
DEF_ATTR_IDENT (ATTR_LEAF, "leaf")
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index ac936d5..d6dc9c37723 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -119,6 +119,7 @@ static tree handle_novops_attribute (tree *, tree, tree, 
int, bool *);
static tree handle_vector_size_attribute (tree *, tree, tree, int,
bool *);
static tree handle_nonnull_attribute (tree *, tree, tree, int, bool *);
+static tree handle_inrange_attribute (tree *, tree, tree, int, bool *);
static tree handle_nonstring_attribute (tree *, tree, tree, int, bool *);
static tree handle_nothrow_attribute (tree *, tree, tree, int, bool *);
static tree handle_cleanup_attribute (tree *, tree, tree, int, bool *);
@@ -379,6 +380,8 @@ const struct attribute_spec c_common_attribute_table[] =
handle_tls_model_attribute, NULL },
{ "nonnull", 0, -1, false, true, true, false,
handle_nonnull_attribute, NULL },
+ { "inrange", 3, 3, false, true, true, false,
+ handle_inrange_attribute, NULL },
{ "nonstring", 0, 0, true, false, false, false,
handle_nonstring_attribute, NULL },
{ "nothrow", 0, 0, true, false, false, false,
@@ -3754,6 +3757,59 @@ handle_nonnull_attribute (tree *node, tree name,
return NULL_TREE;
}

+/* Handle the "inrange" attribute. */
+
+static tree
+handle_inrange_attribute (tree *node, tree name,
+ tree args, int ARG_UNUSED (flags),
+ bool *no_add_attrs)
+{
+ tree type = node;
+
+ / Test the position argument */
+ tree pos = TREE_VALUE (args);
+ if (!positional_argument (type, name, pos, INTEGER_TYPE, 0))
+ no_add_attrs = true;
+
+ / Make sure that range args are INTEGRALs */
+ bool range_err = false;
+ for (tree range = TREE_CHAIN (args); range; range = TREE_CHAIN (range))
+ {
+ tree val = TREE_VALUE (range);
+ if (val && TREE_CODE (val) != IDENTIFIER_NODE
+ && TREE_CODE (val) != FUNCTION_DECL)
+ val = default_conversion (val);
+
+ if (TREE_CODE (val) != INTEGER_CST
+ || !INTEGRAL_TYPE_P (TREE_TYPE (val)))


Um, why the check for INTEGRAL_TYPE_P here ?
IIUC, this will also accept non-constant integer values.
For eg, the following compiles without any warning:
int a;
int b;

void foo(int d) attribute ((inrange (1, a, b)));
void foo(int d) {
__builtin_printf("%d\n", d == 0);
}

Is this intended ?


This was intended behavior but now that I think about it,
it's probably best to just use constant integers. Good catch!


+ {
+ 

Re: GSoC Blog Post 0 - GCCprefab build system

[Jonathan Wakely via Gcc]

On Mon, 13 Jun 2022, 18:12 Wileam Yonatan Phan, 
wrote:

>
>
> Yes, you are correct that the script currently uses the tip of the
> `releases/gcc-[version]` branches. Is that not the same as using the
> published
> tarballs on the FTP server?



No.

I _do_ notice that these branches only get pushed
> whenever a minor version or a patchlevel is released.
>

For the gcc-12 branch, it currently changes several times a week:
https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/releases/gcc-12

Releases only happen every few months, and even snapshots from the branch
happen only once a week.

Your config file uses the tip of the branch, which is not the "latest GCC
12 release" as it claims. It's something different depending when you
happen to run the script, not a release.

The latest GCC 12 release would be the releases/gcc-12.1.0 tag in Git.

>

Re: fanalyzer: debugging zero state machine

[David Malcolm via Gcc]

On Sun, 2022-06-12 at 20:27 +0200, Tim Lange wrote:
> 
> 
> On Do, Jun 9 2022 at 13:40:06 -0400, David Malcolm 
>  wrote:
> > On Thu, 2022-06-09 at 16:49 +0200, Tim Lange wrote:
> > > 
> > >   > On Mi, Jun 8 2022 at 11:12:52 -0400, David Malcolm
> > >   wrote:
> > >   > > On Wed, 2022-06-08 at 01:42 +0200, Tim Lange wrote:
> > >   > >
> > >   > > Hi Dave,
> > 
> > Hi Tim; various responses inline below...
> > 
> > >   > >
> > >   > > I did spent some time to think about the zero state machine.
> > > I
> > >  first
> > >   > > thought about distinguishing between "assigned zero" and "EQ
> > > 0
> > >   > > condition on the path" for cases where e.g. unreachable() is
> > >  used
> > >  to
> > >   > > say that some variable will never be zero according to the
> > >  programmer.
> > >   > > In that case the dev might not want zero warnings from
> > >  conditions
> > >   > > outside the if body itself for dev build where unreachable
> > >  expands
> > >  to
> > >   > > some panic exit. But as the condition constraint is not
> > > pruned
> > >  when the
> > >   > > state machine is distinguishing the states, I'm not sure how
> > > to
> > >  know
> > >   > > whether the analysis already left the if body?
> > >   >
> > >   > The analyzer works on the gimple-ssa representation, which uses
> > >  basic
> > >   > blocks in a CFG, rather than an AST, so the only remants we
> > > have
> > >  of
> > >   > scope is in "clobber" statements (a special kind of assignment
> > >  stmt),
> > >   > which the gimplify adds as variables go out of scope.
> > >  If the constraints only lived until the immediate dominator of `if
> > >  (cond)`, I could easily distinguish:
> > >  1. if (x == 0) && still inside the if => zero
> > >  2. if (x == 0) && outside if => maybe zero
> > >  but as this seems to be not the case, if I want to distinguish 1.
> > > &
> > >  2.,
> > >  I'd have to find another way.
> > >   >
> > >   > For pruning, the analyzer's state_machine class has a
> > >  "can_purge_p"
> > >   > virtual function:
> > >   >
> > >   > /* Return true if it safe to discard the given state (to help
> > >   > when simplifying state objects).
> > >   > States that need leak detection should return false. */
> > >   > virtual bool can_purge_p (state_t s) const = 0;
> > >   >
> > >   > which should return true for a "zeroness" state machine, in
> > > that
> > >  we
> > >   > always consider pruning states for svalues that aren't needed
> > >  anymore
> > >   > along a path.
> > >  Is implemented and returns true.
> > >   >
> > >   > Is there some other kind of state explosion you're running
> > > into?
> > >  It's
> > >   > hard to figure this out further without seeing code.
> > >  No, my code is by far not that mature to be tested. I just had in
> > > my
> > >  head that I wanted to find out if I can distinguish the two cases.
> > >   >
> > >   >
> > >   > > Also, while trying out different things, it seems simple
> > >  assignments on
> > >   > > phi like here
> > >   > > int x;
> > >   > > if (argc == 1) {
> > >   > > x = 1; // x_5
> > >   > > } else {
> > >   > > x = 0; // x_4
> > >   > > }
> > >   > > printf("%i", 5 / x); // x_2
> > >   > > automatically work such that x_2 already inherits the state
> > > from
> > >   > > x_4/x_5 without me doing anything inside my sm's on_phi
> > >  function.
> > >  Same
> > >   > > for the simple y = 0; x = y; case. Where does this happen 
> > > inside
> > >  the
> > >   > > code?
> > >   >
> > >   > With the caveat that I'm seeing your code, what's probably
> > >  happening
> > >  is
> > >   > that we have either:
> > >   >
> > >   > BB (a):
> > >   > x_5 = 1;
> > >   > goto BB (c);
> > >   >
> > >   > BB (b):
> > >   > x_4 = 0;
> > >   > goto BB (c);
> > >   >
> > >   > BB (c):
> > >   > x_2 = PHI (x_5 from (a), x_4 from (b));
> > >  I compiled it with -g, so this one is like the dumped gimple.
> > >   >
> > >   > or (at higher optimization levels):
> > >   >
> > >   > BB (a):
> > >   > goto BB (c);
> > >   >
> > >   > BB (b):
> > >   > goto BB (c);
> > >   >
> > >   > BB (c):
> > >   > x_2 = PHI (1 from (a), 0 from (b));
> > >   >
> > >   > and I think that at the phi node we have 
> > > region_model::handle_phi,
> > >   > which is setting x_2 to either the constant 1 or the constant 0
> > > in
> > >  the
> > >   > store, and is calling the on_phi vfunc, leading to on_phi being
> > >  called
> > >   > for all state machines.
> > >  Thanks, that is the case. The set_value inside handle_phi seems to
> > >  this
> > >  for me.
> > >   >
> > >   > BTW, are you implementing an override for this vfunc:
> > >   > virtual state_machine::state_t get_default_state (const svalue
> > > *)
> > >   > const;
> > >   >
> > >   > to capture the inherently known zeroness/nonzeroness of
> > >  constant_svalue
> > >   > instances? That would make those constants have that state.
> > >  Yeah, I saw that on your nullness check. I tried it on a small
> > >  example
> > >  with and without, but didn't noticed a di

Re: GSoC Blog Post 0 - GCCprefab build system

[Damian Rouson]

On Mon, Jun 13, 2022 at 8:27 AM Jonathan Wakely via Fortran <
fort...@gcc.gnu.org> wrote:

>
> Yes, it does that, but takes 400 lines of shell script to do so.
>
> If you want "relatively easy ways to build GCC painlessly" then you
> can do it with nine lines of shell commands.
>
> Or in about 80, for any non-prehistoric version, with no config file
> needed (just a single option to the script, the release number or
> snapshot name to build):
>
> https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh


Do the above 9 lines or 80 lines include the entire prerequisite software
stack or just the ones that the download_prerequisites script downloads?
If I recall correctly, building gfortran also requires flex and building
flex requires bison and building bison requires m4 and the
download_prerequisites script didn't download any of those the last time I
checked.

I realize that building gfortran from source comes very easily to GCC
developers, especially if they do it regularly.  I've encountered a lot of
people who found it challenging, including myself initially, which was the
reason for incorporating the capability into the OpenCoarrays installer.

Damian