[PATCH] Objective-C: fix crash with -fobjc-nilcheck

[Matt Jacobson via Gcc-patches]

When -fobjc-nilcheck is enabled, messages that result in a struct type should 
yield a zero-initialized struct when sent to nil.  Currently, the frontend 
crashes when it encounters this situation.  This patch fixes the crash by 
generating the tree for the `{}` initializer.

Tested by running the frontend against the example in PR101666 and inspecting 
the generated code.

I don't have commit access, so if this patch is suitable, I'd need someone else 
to commit it for me.  Thanks.


gcc/objc/ChangeLog:

2021-08-14  Matt Jacobson  

PR objc/101666
* objc-next-runtime-abi-02.c (build_v2_objc_method_fixup_call): Fix 
crash.
(build_v2_build_objc_method_call): Fix crash.


diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
b/gcc/objc/objc-next-runtime-abi-02.c
index e391ee527ce..42645e22316 100644
--- a/gcc/objc/objc-next-runtime-abi-02.c
+++ b/gcc/objc/objc-next-runtime-abi-02.c
@@ -1676,11 +1676,7 @@ build_v2_objc_method_fixup_call (int super_flag, tree 
method_prototype,
   if (TREE_CODE (ret_type) == RECORD_TYPE
  || TREE_CODE (ret_type) == UNION_TYPE)
{
- vec *rtt = NULL;
- /* ??? CHECKME. hmmm. think we need something more
-here.  */
- CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
- ftree = objc_build_constructor (ret_type, rtt);
+ ftree = objc_build_constructor (ret_type, NULL);
}
   else
ftree = fold_convert (ret_type, integer_zero_node);
@@ -1790,11 +1786,7 @@ build_v2_build_objc_method_call (int super, tree 
method_prototype,
   if (TREE_CODE (ret_type) == RECORD_TYPE
  || TREE_CODE (ret_type) == UNION_TYPE)
{
- vec *rtt = NULL;
- /* ??? CHECKME. hmmm. think we need something more
-here.  */
- CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
- ftree = objc_build_constructor (ret_type, rtt);
+ ftree = objc_build_constructor (ret_type, NULL);
}
   else
ftree = fold_convert (ret_type, integer_zero_node);

Re: [PATCH] Add range/nonzero info to generated ADD_OVERFLOW and simplify

[Jakub Jelinek via Gcc-patches]

On Fri, Aug 13, 2021 at 06:22:48PM -0700, apinski--- via Gcc-patches wrote:
> From: Andrew Pinski 
> 
> Even though this does not change the generated code,
> it does improve the initial RTL generation.
> 
> gcc/ChangeLog:
> 
>   * tree-ssa-math-opts.c (match_arith_overflow):
>   Add range and nonzero bits information to
>   the new overflow ssa name.  Also fold
>   the use statement.
> ---
>  gcc/tree-ssa-math-opts.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
> index c4a6492b50d..bb7edeaa6f7 100644
> --- a/gcc/tree-ssa-math-opts.c
> +++ b/gcc/tree-ssa-math-opts.c
> @@ -4221,6 +4221,8 @@ match_arith_overflow (gimple_stmt_iterator *gsi, gimple 
> *stmt,
>   }
>  }
>tree ovf = make_ssa_name (type);
> +  set_range_info (ovf, VR_RANGE, wi::zero (TYPE_PRECISION (type)), wi::one 
> (TYPE_PRECISION (type)));

Too long line.

> +  set_nonzero_bits (ovf, wi::one (TYPE_PRECISION (type)));

Are you sure this is really needed?
set_range_info should have computed that one from the range already:
  /* If it is a range, try to improve nonzero_bits from the min/max.  */
  if (range_type == VR_RANGE)
{
  wide_int xorv = ri->get_min () ^ ri->get_max ();
  if (xorv != 0)
xorv = wi::mask (precision - wi::clz (xorv), false, precision);
  ri->set_nonzero_bits (ri->get_nonzero_bits () & (ri->get_min () | xorv));
}

> @@ -4279,6 +4281,8 @@ match_arith_overflow (gimple_stmt_iterator *gsi, gimple 
> *stmt,
> gimple_assign_set_rhs1 (use_stmt, cond);
>   }
>   }
> +  gimple_stmt_iterator gsi1 = gsi_for_stmt (use_stmt);
> +  fold_stmt (&gsi1);
>update_stmt (use_stmt);

I don't think it is safe to do that here.
First of all, the update_stmt is right after it, then some further code
that still uses use_stmt right below and this is in a loop that iterates imm
uses of that use_stmt too.
If you want to fold use_stmt, can't it be done after the whole loop?

>if (code == MULT_EXPR && use_stmt != orig_use_stmt)
>   {
> -- 
> 2.27.0

Jakub

Re: [PATCH] Objective-C: fix crash with -fobjc-nilcheck

[Iain Sandoe via Gcc-patches]

Hi Matt,

> On 14 Aug 2021, at 09:14, Matt Jacobson via Gcc-patches 
>  wrote:
> 
> When -fobjc-nilcheck is enabled, messages that result in a struct type should 
> yield a zero-initialized struct when sent to nil.  Currently, the frontend 
> crashes when it encounters this situation.  This patch fixes the crash by 
> generating the tree for the `{}` initializer.
> 
> Tested by running the frontend against the example in PR101666 and inspecting 
> the generated code.
> 
> I don't have commit access, so if this patch is suitable, I'd need someone 
> else 
> to commit it for me.  Thanks.

Thanks for the patch,

a couple of requests tho:

1/ please can you either post using a mailer that doesn’t mangle patches or put 
the patch as a plain text attachment
  (pushing to a git branch somewhere public also works for me, but maybe not 
for all reviewers)
   - for small patches like this I can obviously fix things up by hand, but for 
anything larger not a good idea.

2/ since this is fixing a crashing case, we should add a test to the test suite 
for it (and also check the corresponding objective-c++).

thanks
Iain

> 
> 
> gcc/objc/ChangeLog:
> 
> 2021-08-14  Matt Jacobson  
> 
>   PR objc/101666
>   * objc-next-runtime-abi-02.c (build_v2_objc_method_fixup_call): Fix 
> crash.
>   (build_v2_build_objc_method_call): Fix crash.
> 
> 
> diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
> b/gcc/objc/objc-next-runtime-abi-02.c
> index e391ee527ce..42645e22316 100644
> --- a/gcc/objc/objc-next-runtime-abi-02.c
> +++ b/gcc/objc/objc-next-runtime-abi-02.c
> @@ -1676,11 +1676,7 @@ build_v2_objc_method_fixup_call (int super_flag, tree 
> method_prototype,
>   if (TREE_CODE (ret_type) == RECORD_TYPE
>  || TREE_CODE (ret_type) == UNION_TYPE)
>{
> - vec *rtt = NULL;
> - /* ??? CHECKME. hmmm. think we need something more
> -here.  */
> - CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
> - ftree = objc_build_constructor (ret_type, rtt);
> + ftree = objc_build_constructor (ret_type, NULL);
>}
>   else
>ftree = fold_convert (ret_type, integer_zero_node);
> @@ -1790,11 +1786,7 @@ build_v2_build_objc_method_call (int super, tree 
> method_prototype,
>   if (TREE_CODE (ret_type) == RECORD_TYPE
>  || TREE_CODE (ret_type) == UNION_TYPE)
>{
> - vec *rtt = NULL;
> - /* ??? CHECKME. hmmm. think we need something more
> -here.  */
> - CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
> - ftree = objc_build_constructor (ret_type, rtt);
> + ftree = objc_build_constructor (ret_type, NULL);
>}
>   else
>ftree = fold_convert (ret_type, integer_zero_node);
> 

[committed] i386: Fix ICE with V64QImode broadcast permutation with -mavx512f -mno-avx512bw [PR101896]

[Jakub Jelinek via Gcc-patches]

Hi!

The testcase shows another problem, for TARGET_AVX512BW we have a single insn
doing broadcast from the first element, but don't have one for broadcast
of 2nd+ element (so for d->perm[0] we must return false), but for
TARGET_AVX512F && !TARGET_AVX512BW we don't even have support for that other
broadcast.  V64QImode case was just added to the AVX2 cases which had
gcc_assert (!TARGET_AVX2 || d->perm[0]);
but for V64QImode we actually need
gcc_assert (!TARGET_AVX512BW || d->perm[0]);

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious.

2021-08-14  Jakub Jelinek  

PR target/101896
* config/i386/i386-expand.c (expand_vec_perm_broadcast_1)
: For this mode assert
!TARGET_AVX512BW || d->perm[0] rather than !TARGET_AVX2 || d->perm[0].

* gcc.target/i386/avx512f-pr101896.c: New test.

--- gcc/config/i386/i386-expand.c.jj2021-08-12 11:26:50.0 +0200
+++ gcc/config/i386/i386-expand.c   2021-08-13 10:05:40.820131381 +0200
@@ -20474,7 +20474,6 @@ expand_vec_perm_broadcast_1 (struct expa
   emit_move_insn (d->target, gen_lowpart (d->vmode, dest));
   return true;
 
-case E_V64QImode:
 case E_V32QImode:
 case E_V16HImode:
 case E_V8SImode:
@@ -20484,6 +20483,10 @@ expand_vec_perm_broadcast_1 (struct expa
   gcc_assert (!TARGET_AVX2 || d->perm[0]);
   return false;
 
+case E_V64QImode:
+  gcc_assert (!TARGET_AVX512BW || d->perm[0]);
+  return false;
+
 case E_V32HImode:
   gcc_assert (!TARGET_AVX512BW);
   return false;
--- gcc/testsuite/gcc.target/i386/avx512f-pr101896.c.jj 2021-08-13 
10:10:32.624070409 +0200
+++ gcc/testsuite/gcc.target/i386/avx512f-pr101896.c2021-08-13 
10:10:42.763929293 +0200
@@ -0,0 +1,5 @@
+/* PR target/101896 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx512f -mno-avx512bw" } */
+
+#include "../../gcc.dg/torture/vshuf-v64qi.c"

Jakub

Re: [PATCH] Fix xxeval predicates (PR 99921).

[Segher Boessenkool]

On Fri, Aug 13, 2021 at 04:33:26PM -0400, David Edelsohn wrote:
> On Fri, Aug 13, 2021 at 4:24 PM Segher Boessenkool
>  wrote:
> > On Fri, Aug 13, 2021 at 02:07:25PM -0400, David Edelsohn wrote:
> > > On Fri, Aug 13, 2021 at 12:08 PM Segher Boessenkool
> > >  wrote:
> > > > On Fri, Aug 13, 2021 at 11:15:21AM -0400, David Edelsohn wrote:
> > > > > On Fri, Aug 13, 2021 at 10:49 AM Segher Boessenkool
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, Aug 13, 2021 at 12:14:14AM -0400, Michael Meissner wrote:
> > > > > > > I noticed that the xxeval built-in function used the 
> > > > > > > altivec_register_operand
> > > > > > > predicate.  Since it takes vsx registers, this might force the 
> > > > > > > register
> > > > > > > allocate to issue a move when it could use a traditional floating 
> > > > > > > point
> > > > > > > register.  This patch fixes that.
> > > > > >
> > > > > > Why register_operand instead of gpc_reg_operand?  The former allows
> > > > > > subregs of memory, likely not what you want here (and not in other
> > > > > > rs6000 pattern that currently use it, either).
> > > > >
> > > > > Because it's consistent with the other patterns.
> > > >
> > > > Not with the vast majority of other patterns, no.
> > >
> > > For vector operands in altivec.md, if the predicates do not use
> > > altivec_register_operand, they use register_operand, not
> > > gpc_reg_operand.  Mike's change is consistent with the rest of the
> > > altivec.md file.
> > >
> > > Maybe the predicates for those patterns should be changed.  Maybe that
> > > change would be an improvement.
> > >
> > > Your statement about the vast majority of patterns is wrong with
> > > respect to altivec.md.
> >
> > There is nothing about that file that makes it any different for this?
> >
> > Anyway, the numbers:
> >
> >gpc_reg_operand   register_operand
> > config/rs6000/altivec.md   11 760
> > config/rs6000/crypto.md 0  14
> > config/rs6000/darwin.md25   1
> > config/rs6000/dfp.md   71   3
> > config/rs6000/fusion.md   349   0
> > config/rs6000/htm.md   10   0
> > config/rs6000/mma.md4   0
> > config/rs6000/pcrel-opt.md  8   0
> > config/rs6000/rs6000.md  1105 116
> > config/rs6000/sync.md   0   3
> > config/rs6000/vector.md 0  29
> > config/rs6000/vsx.md  102 122
> 
> There is a song from Sesame Street: "Which of these is not like the
> others?"  altivec.md seems like an outlier.  crypto.md and vsx.md also
> seem unusual.
> 
> We have
> 
> register_operand
> gpc_reg_operand
> altivec_register_operand
> vsx_register_operand
> 
> among various relevant options.

And register_operand is the strange one there: it allows subregs of
memory, and also allows sf_subreg_operand.  Those others (as well as
vfloat_operand, vint_operand, vlogical_operand -- we really could have
fewer than that, hrm) do not.

> It seems like this deserves to be
> cleaned up sometime, but a patch for xxeval is not the time.

Of course.  But I noticed it now, so I mentioned it now.  That is all.


Segher

Re: [PATCH] Fix xxeval predicates (PR 99921).

[Segher Boessenkool]

On Fri, Aug 13, 2021 at 07:57:53PM -0400, Michael Meissner wrote:
> On Fri, Aug 13, 2021 at 04:33:26PM -0400, David Edelsohn wrote:
> > There is a song from Sesame Street: "Which of these is not like the
> > others?"  altivec.md seems like an outlier.  crypto.md and vsx.md also
> > seem unusual.
> > 
> > We have
> > 
> > register_operand
> > gpc_reg_operand
> > altivec_register_operand
> > vsx_register_operand
> > 
> > among various relevant options.  It seems like this deserves to be
> > cleaned up sometime, but a patch for xxeval is not the time.
> 
> As the person who added altivec_register_operand, vsx_register_opernd, and
> various others, the original reason for adding these were to eliminate some
> issues we were seeing with register allocation, where the pre-LRA register
> allocator would often do wonky things, and not allowing GPRs helped eliminate
> some of the reloads.  There were some passes, particularly after register
> allocation that didn't look at the constraints.  Now that we've had LRA for
> awhile, maybe it is time to rethink these.

If we can get rid of ever generating subregs of mem (which has been
deprecated for decades now after all -- the last thing stopping removing
it was old reload), and we can also do what TARGET_NO_SF_SUBREG does
some other way, we could allow register_operand in the port again.  As
it is, we need to avoid it as a pattern predicate.

> I did actually think whether to use gpc_reg_operand or vsx_register_operand.  
> I
> opted to use register_operand just because most of the surrounding code used
> it.

Not an unreasonable thing to do.  But for that same reason, thinking it
is good because surrounding code does the same thing, is a trap as well!


Segher

[PATCH v2] Fix ICE when mixing VLAs and statement expressions [PR91038]

[Uecker, Martin]

Here is an update version of the patch. I now reorder
only the gimplification and not other preparation so that
replacing PLACEHOLDER_EXPRs for Ada should continue
to work.  I also removed a call to gimplify_type_sizes
somewhere else, which also caused some similar problemes.

This seems to fix most issues with variably-modified types
which are returned from statement expressions (which
works on clang).

The C FE bugs related to structs of variable size
were already fixed separately.

There are still two problems left:

- It still does not fix the probelm for constant
index 0 (see uncommented cases in vla-stexp-8.c)
Somehow this goes into a different code path
where things still go wrong.

- Returning a struct of variable size from
a statement expression (instead of returning
a pointer) does not work, see the FIXME.
We need to call gimplify_vla_decl (temp, pre_p)
at the beginning of gimplify_target_expr
for the tempory but when this depends on
sizes computed in the expression itself this
can not work. No idea how fix this.

 

Martin




Fix ICE when mixing VLAs and statement expressions [PR91038]

When returning VM-types from statement expressions, this can
lead to an ICE when declarations from the statement expression
are referred to later. Some of these issues can be addressed by
gimplifying the base expression earlier in gimplify_compound_lval.
This fixes PR91038 and some of the test cases from PR29970
(structs with VLA members need further work).


2021-08-01  Martin Uecker  

gcc/
PR c/91038
PR c/29970
* gimplify.c (gimplify_var_or_parm_decl): Update comment.
(gimplify_compound_lval): Gimplify base expression first.
(gimplify_target_expr): Do not gimplify size expression.

gcc/testsuite/
PR c/91038
PR c/29970
* gcc.dg/vla-stexp-3.c: New test.
* gcc.dg/vla-stexp-4.c: New test.
* gcc.dg/vla-stexp-5.c: New test.
* gcc.dg/vla-stexp-6.c: New test.
* gcc.dg/vla-stexp-7.c: New test.
* gcc.dg/vla-stexp-8.c: New test.


diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 21ff32ee4aa..9c12b1e3f87 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -2839,7 +2839,10 @@ gimplify_var_or_parm_decl (tree *expr_p)
  declaration, for which we've already issued an error.  It would
  be really nice if the front end wouldn't leak these at all.
  Currently the only known culprit is C++ destructors, as seen
- in g++.old-deja/g++.jason/binding.C.  */
+ in g++.old-deja/g++.jason/binding.C.
+ Another possible culpit are size expressions for variably modified
+ types which are lost in the FE or not gimplified correctly.
+  */
   if (VAR_P (decl)
   && !DECL_SEEN_IN_BIND_EXPR_P (decl)
   && !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
@@ -2984,16 +2987,22 @@ gimplify_compound_lval (tree *expr_p, gimple_seq 
*pre_p, gimple_seq *post_p,
  expression until we deal with any variable bounds, sizes, or
  positions in order to deal with PLACEHOLDER_EXPRs.
 
- So we do this in three steps.  First we deal with the annotations
- for any variables in the components, then we gimplify the base,
- then we gimplify any indices, from left to right.  */
+ The base expression may contain a statement expression that
+ has declarations used in size expressions, so has to be
+ gimplified before gimplifying the size expressions.
+
+ So we do this in three steps.  First we deal with variable
+ bounds, sizes, and positions, then we gimplify the base,
+ then we deal with the annotations for any variables in the
+ components and any indices, from left to right.  */
+
   for (i = expr_stack.length () - 1; i >= 0; i--)
 {
   tree t = expr_stack[i];
 
   if (TREE_CODE (t) == ARRAY_REF || TREE_CODE (t) == ARRAY_RANGE_REF)
{
- /* Gimplify the low bound and element type size and put them into
+ /* Deal with the low bound and element type size and put them into
 the ARRAY_REF.  If these values are set, they have already been
 gimplified.  */
  if (TREE_OPERAND (t, 2) == NULL_TREE)
@@ -3002,18 +3011,8 @@ gimplify_compound_lval (tree *expr_p, gimple_seq *pre_p, 
gimple_seq *post_p,
  if (!is_gimple_min_invariant (low))
{
  TREE_OPERAND (t, 2) = low;
- tret = gimplify_expr (&TREE_OPERAND (t, 2), pre_p,
-   post_p, is_gimple_reg,
-   fb_rvalue);
- ret = MIN (ret, tret);
}
}
- else
-   {
- tret = gimplify_expr (&TREE_OPERAND (t, 2), pre_p, post_p,
-   is_gimple_reg, fb_rvalue);
- ret = MIN (ret, tret);
-   }
 
  if (TREE_OPERAND (t, 3) == NULL_TREE)
{
@@ -3030,18 +3029,8 @@ gimplify_compound_lval (tree *expr_p, gimple_s

Re: [PATCH v2 0/2] OpenRISC support for cmodel=large

[Giulio Benetti]

Hi All,

On 5/1/21 11:11 PM, Stafford Horne wrote:

Changes from v1:
  - Added patch to enabled cmodle=large on crtstuff

This series fixes some bugs found when linking large binaries, both in buildroot
and glibc testing.

Stafford Horne (2):
   or1k: Add mcmodel option to handle large GOTs
   or1k: Use cmodel=large when building crtstuff

  gcc/config/or1k/or1k-opts.h   | 30 ++
  gcc/config/or1k/or1k.c| 11 +--
  gcc/config/or1k/or1k.h|  7 +++
  gcc/config/or1k/or1k.opt  | 19 +++
  gcc/doc/invoke.texi   | 12 +++-
  libgcc/config.host|  4 ++--
  libgcc/config/or1k/t-crtstuff |  2 ++
  7 files changed, 80 insertions(+), 5 deletions(-)
  create mode 100644 gcc/config/or1k/or1k-opts.h
  create mode 100644 libgcc/config/or1k/t-crtstuff



I've tested this patchset and works as expected.
It fixed libgeos build failure in conjunction with:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c3de29b048bca6b4aa4235c647b9328e71801b6

Hope this helps to commit it upstream since I still don't see it, or am 
I wrong?


Best regards
--
Giulio Benetti
Benetti Engineering sas

Re: [PATCH v2 0/2] OpenRISC support for cmodel=large

[Stafford Horne via Gcc-patches]

On Sat, Aug 14, 2021 at 11:01:16PM +0200, Giulio Benetti wrote:
> Hi All,
> 
> On 5/1/21 11:11 PM, Stafford Horne wrote:
> > Changes from v1:
> >   - Added patch to enabled cmodle=large on crtstuff
> > 
> > This series fixes some bugs found when linking large binaries, both in 
> > buildroot
> > and glibc testing.
> > 
> > Stafford Horne (2):
> >or1k: Add mcmodel option to handle large GOTs
> >or1k: Use cmodel=large when building crtstuff
> > 
> >   gcc/config/or1k/or1k-opts.h   | 30 ++
> >   gcc/config/or1k/or1k.c| 11 +--
> >   gcc/config/or1k/or1k.h|  7 +++
> >   gcc/config/or1k/or1k.opt  | 19 +++
> >   gcc/doc/invoke.texi   | 12 +++-
> >   libgcc/config.host|  4 ++--
> >   libgcc/config/or1k/t-crtstuff |  2 ++
> >   7 files changed, 80 insertions(+), 5 deletions(-)
> >   create mode 100644 gcc/config/or1k/or1k-opts.h
> >   create mode 100644 libgcc/config/or1k/t-crtstuff
> > 
> 
> I've tested this patchset and works as expected.
> It fixed libgeos build failure in conjunction with:
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c3de29b048bca6b4aa4235c647b9328e71801b6
> 
> Hope this helps to commit it upstream since I still don't see it, or am I
> wrong?

You are not wrong, I did not push the changed to GCC yet.  I will do soon.

-Stafford

Re: [PATCH v2 0/2] OpenRISC support for cmodel=large

[Giulio Benetti]

On 8/15/21 12:03 AM, Stafford Horne wrote:

On Sat, Aug 14, 2021 at 11:01:16PM +0200, Giulio Benetti wrote:

Hi All,

On 5/1/21 11:11 PM, Stafford Horne wrote:

Changes from v1:
   - Added patch to enabled cmodle=large on crtstuff

This series fixes some bugs found when linking large binaries, both in buildroot
and glibc testing.

Stafford Horne (2):
or1k: Add mcmodel option to handle large GOTs
or1k: Use cmodel=large when building crtstuff

   gcc/config/or1k/or1k-opts.h   | 30 ++
   gcc/config/or1k/or1k.c| 11 +--
   gcc/config/or1k/or1k.h|  7 +++
   gcc/config/or1k/or1k.opt  | 19 +++
   gcc/doc/invoke.texi   | 12 +++-
   libgcc/config.host|  4 ++--
   libgcc/config/or1k/t-crtstuff |  2 ++
   7 files changed, 80 insertions(+), 5 deletions(-)
   create mode 100644 gcc/config/or1k/or1k-opts.h
   create mode 100644 libgcc/config/or1k/t-crtstuff



I've tested this patchset and works as expected.
It fixed libgeos build failure in conjunction with:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c3de29b048bca6b4aa4235c647b9328e71801b6

Hope this helps to commit it upstream since I still don't see it, or am I
wrong?


You are not wrong, I did not push the changed to GCC yet.  I will do soon.


Ah ok, you're the maintainer :-) I thought there was someone else who 
needed to push it :-)


Best regards
--
Giulio Benetti
Benetti Engineering sas

Re: [PATCH v2 0/2] OpenRISC support for cmodel=large

[Stafford Horne via Gcc-patches]

On Sun, Aug 15, 2021 at 12:05:37AM +0200, Giulio Benetti wrote:
> On 8/15/21 12:03 AM, Stafford Horne wrote:
> > On Sat, Aug 14, 2021 at 11:01:16PM +0200, Giulio Benetti wrote:
> > > Hi All,
> > > 
> > > On 5/1/21 11:11 PM, Stafford Horne wrote:
> > > > Changes from v1:
> > > >- Added patch to enabled cmodle=large on crtstuff
> > > > 
> > > > This series fixes some bugs found when linking large binaries, both in 
> > > > buildroot
> > > > and glibc testing.
> > > > 
> > > > Stafford Horne (2):
> > > > or1k: Add mcmodel option to handle large GOTs
> > > > or1k: Use cmodel=large when building crtstuff
> > > > 
> > > >gcc/config/or1k/or1k-opts.h   | 30 ++
> > > >gcc/config/or1k/or1k.c| 11 +--
> > > >gcc/config/or1k/or1k.h|  7 +++
> > > >gcc/config/or1k/or1k.opt  | 19 +++
> > > >gcc/doc/invoke.texi   | 12 +++-
> > > >libgcc/config.host|  4 ++--
> > > >libgcc/config/or1k/t-crtstuff |  2 ++
> > > >7 files changed, 80 insertions(+), 5 deletions(-)
> > > >create mode 100644 gcc/config/or1k/or1k-opts.h
> > > >create mode 100644 libgcc/config/or1k/t-crtstuff
> > > > 
> > > 
> > > I've tested this patchset and works as expected.
> > > It fixed libgeos build failure in conjunction with:
> > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c3de29b048bca6b4aa4235c647b9328e71801b6
> > > 
> > > Hope this helps to commit it upstream since I still don't see it, or am I
> > > wrong?
> > 
> > You are not wrong, I did not push the changed to GCC yet.  I will do soon.
> 
> Ah ok, you're the maintainer :-) I thought there was someone else who needed
> to push it :-)

Yeah, I pushed it now.

Re: [PATCH v2 0/2] OpenRISC support for cmodel=large

[Giulio Benetti]

On 8/15/21 12:25 AM, Stafford Horne wrote:

On Sun, Aug 15, 2021 at 12:05:37AM +0200, Giulio Benetti wrote:

On 8/15/21 12:03 AM, Stafford Horne wrote:

On Sat, Aug 14, 2021 at 11:01:16PM +0200, Giulio Benetti wrote:

Hi All,

On 5/1/21 11:11 PM, Stafford Horne wrote:

Changes from v1:
- Added patch to enabled cmodle=large on crtstuff

This series fixes some bugs found when linking large binaries, both in buildroot
and glibc testing.

Stafford Horne (2):
 or1k: Add mcmodel option to handle large GOTs
 or1k: Use cmodel=large when building crtstuff

gcc/config/or1k/or1k-opts.h   | 30 ++
gcc/config/or1k/or1k.c| 11 +--
gcc/config/or1k/or1k.h|  7 +++
gcc/config/or1k/or1k.opt  | 19 +++
gcc/doc/invoke.texi   | 12 +++-
libgcc/config.host|  4 ++--
libgcc/config/or1k/t-crtstuff |  2 ++
7 files changed, 80 insertions(+), 5 deletions(-)
create mode 100644 gcc/config/or1k/or1k-opts.h
create mode 100644 libgcc/config/or1k/t-crtstuff



I've tested this patchset and works as expected.
It fixed libgeos build failure in conjunction with:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c3de29b048bca6b4aa4235c647b9328e71801b6

Hope this helps to commit it upstream since I still don't see it, or am I
wrong?


You are not wrong, I did not push the changed to GCC yet.  I will do soon.


Ah ok, you're the maintainer :-) I thought there was someone else who needed
to push it :-)


Yeah, I pushed it now.


Awesome, just seen now. Buildroot is already Openrisc toolchain bug 
free, only we have to wait for external toolchain to be rebuilt with 
suck patches. So we've got OpenRisc back to life :-).


Thank you!
--
Giulio Benetti
Benetti Engineering sas

Re: libgo patch committed: Update to Go1.17rc2 release

[Ian Lance Taylor via Gcc-patches]

On Fri, Aug 13, 2021 at 2:08 PM Rainer Orth  
wrote:
>
> unfortunately, things are considerably worse: syscall.lo fails to build
> and go1 even ICEs:
>
> /vol/gcc/src/hg/master/local/libgo/go/syscall/libcall_posix_utimesnano.go:13:1:
>  error: redefinition of ‘UtimesNano’
>13 | func UtimesNano(path string, ts []Timespec) error {
>   | ^
> /vol/gcc/src/hg/master/local/libgo/go/syscall/libcall_linux_utimesnano.go:13:1:
>  note: previous definition of ‘UtimesNano’ was here
>13 | func UtimesNano(path string, ts []Timespec) (err error) {
>   | ^
>
> The second file is Linux-only and needs a corresponding build guard.
>
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_unix.go:193:16: error: use 
> of undefined type ‘SysProcAttr’
>   193 | Sys   *SysProcAttr
>   |^
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_unix.go:235:15: error: 
> reference to field ‘Chroot’ in object which has no fields or methods
>   235 | if sys.Chroot != "" {
>   |   ^
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_unix.go:236:52: error: 
> reference to field ‘Chroot’ in object which has no fields or methods
>   236 | chroot, err = BytePtrFromString(sys.Chroot)
>   |^
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_unix.go:251:15: error: 
> reference to field ‘Setctty’ in object which has no fields or methods
>   251 | if sys.Setctty && sys.Foreground {
>   |   ^
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_unix.go:251:30: error: 
> reference to field ‘Foreground’ in object which has no fields or methods
>   251 | if sys.Setctty && sys.Foreground {
>   |  ^
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_unix.go:254:15: error: 
> reference to field ‘Setctty’ in object which has no fields or methods
>   254 | if sys.Setctty && sys.Ctty >= len(attr.Files) {
>   |   ^
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_unix.go:254:30: error: 
> reference to field ‘Ctty’ in object which has no fields or methods
>   254 | if sys.Setctty && sys.Ctty >= len(attr.Files) {
>   |  ^
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_unix.go:269:21: error: 
> reference to undefined name ‘forkAndExecInChild’
>   269 | pid, err1 = forkAndExecInChild(argv0p, argvp, envvp, chroot, 
> dir, attr, sys, p[1])
>   | ^
>
> I found that upstream has exec_libc.go for AIX and Solaris with the
> missing SysProcAttr and forkAndExecInChild definitions.  It doesn't work
> out of the box, though:
>
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_libc.go:63:9: error: 
> reference to undefined name ‘execveLibc’
>63 | execveLibc = execve
>   | ^
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_libc.go:137:25: error: 
> reference to undefined name ‘_Pid_t’
>   137 | pgrp := _Pid_t(sys.Pgid)
>   | ^
> /vol/gcc/src/hg/master/local/libgo/go/syscall/exec_libc.go:144:32: error: 
> reference to undefined name ‘_Pid_t’
>   144 | pgrp = _Pid_t(r1)
>   |^
>
> For one, switching to Pid_t is needed:
>
>
> Besides, support for execveLibc has been dropped in exec_unix.go
> compared to upstream.
>
> terminate called after throwing an instance of 'std::out_of_range'
>   what():  vector::_M_range_check: __n (which is 1) >= this->size() (which is 
> 1)
> go1: internal compiler error: Abort
> 0xce1abf crash_signal
> /vol/gcc/src/hg/master/local/gcc/toplev.c:328
>
> This went away after the fixes above.
>
> Next, I get
>
> /vol/gcc/src/hg/master/local/libgo/go/internal/syscall/unix/getrandom_solaris.go:10:15:
>  error: imported and not used: unsafe
>10 | "unsafe"
>   |   ^
> /vol/gcc/src/hg/master/local/libgo/go/internal/syscall/unix/getrandom_solaris.go:32:30:
>  error: reference to undefined name 'getrandomUnsupported'
>32 | if atomic.LoadInt32(&getrandomUnsupported) != 0 {
>   |  ^
> /vol/gcc/src/hg/master/local/libgo/go/internal/syscall/unix/getrandom_solaris.go:41:44:
>  error: reference to undefined name 'getrandomUnsupported'
>41 | atomic.StoreInt32(&getrandomUnsupported, 1)
>   |^
> make[4]: *** [Makefile:3008: internal/syscall/unix.lo] Error 1
>
> The definition dropped compared to upstream.
>
> /vol/gcc/src/hg/master/local/libgo/go/os/user/listgroups_unix.go:39:15: 
> error: reference to undefined name ‘libc_getgrouplist’
>39 | rv := libc_getgrouplist(nameC, userGID, &gidsC[0], &n)
>   |   ^
> /vol/gcc/src/hg/master/local/libgo/go/os/user/listgroups_unix.go:49:23: 
> error: reference to undefined name ‘libc_getgrouplist’
>49 |  

Re: [PATCH] Objective-C: fix crash with -fobjc-nilcheck

[Matt Jacobson via Gcc-patches]

> On Aug 14, 2021, at 5:25 AM, Iain Sandoe  wrote:
> 
> 1/ please can you either post using a mailer that doesn’t mangle patches or 
> put the patch as a plain text attachment
>  (pushing to a git branch somewhere public also works for me, but maybe not 
> for all reviewers)
>   - for small patches like this I can obviously fix things up by hand, but 
> for anything larger not a good idea.
> 
> 2/ since this is fixing a crashing case, we should add a test to the test 
> suite for it (and also check the corresponding objective-c++).

Sorry for the broken patch.  I *think* this one should apply cleanly.  If not, 
I’ve also pushed the change to branch "objc-fix-struct-nil-check-10.3.0” of 
, viewable at:



I’ve also added a test specifically for this bug and in the process added 
-fobjc-nilcheck to the compiler invocation in objc-torture.exp.  Let me know 
what you think.

I’m not sure what you mean w.r.t. Objective-C++ -- can you explain?


gcc/testsuite/ChangeLog:

2021-08-14  Matt Jacobson  

PR objc/101666
* lib/objc-torture.exp: Test -fobjc-nilcheck when supported by target.
* objc/compile/pr101666.m: New test.


gcc/objc/ChangeLog:

2021-08-14  Matt Jacobson  

PR objc/101666
* objc-next-runtime-abi-02.c (build_v2_objc_method_fixup_call): Fix 
crash.
(build_v2_build_objc_method_call): Fix crash.


diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
b/gcc/objc/objc-next-runtime-abi-02.c
index 66c13ad0db2..192731ff954 100644
--- a/gcc/objc/objc-next-runtime-abi-02.c
+++ b/gcc/objc/objc-next-runtime-abi-02.c
@@ -1676,11 +1676,7 @@ build_v2_objc_method_fixup_call (int super_flag, tree 
method_prototype,
   if (TREE_CODE (ret_type) == RECORD_TYPE
  || TREE_CODE (ret_type) == UNION_TYPE)
{
- vec *rtt = NULL;
- /* ??? CHECKME. hmmm. think we need something more
-here.  */
- CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
- ftree = objc_build_constructor (ret_type, rtt);
+ ftree = objc_build_constructor (ret_type, NULL);
}
   else
ftree = fold_convert (ret_type, integer_zero_node);
@@ -1790,11 +1786,7 @@ build_v2_build_objc_method_call (int super, tree 
method_prototype,
   if (TREE_CODE (ret_type) == RECORD_TYPE
  || TREE_CODE (ret_type) == UNION_TYPE)
{
- vec *rtt = NULL;
- /* ??? CHECKME. hmmm. think we need something more
-here.  */
- CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
- ftree = objc_build_constructor (ret_type, rtt);
+ ftree = objc_build_constructor (ret_type, NULL);
}
   else
ftree = fold_convert (ret_type, integer_zero_node);
diff --git a/gcc/testsuite/lib/objc-torture.exp 
b/gcc/testsuite/lib/objc-torture.exp
index 9aa5792f656..58c4b86f840 100644
--- a/gcc/testsuite/lib/objc-torture.exp
+++ b/gcc/testsuite/lib/objc-torture.exp
@@ -30,7 +30,11 @@ proc objc-set-runtime-options { dowhat args } {
 # that Darwin uses.  If NeXT is ported to another target, then it should
 # be listed here.
 if [istarget *-*-darwin*] {
-  lappend rtlist "-fnext-runtime" 
+  if { [istarget *64-*-*] || [istarget arm-*-*] } {
+   lappend rtlist "-fnext-runtime -fobjc-abi-version=2 -fobjc-nilcheck"
+  } else {
+   lappend rtlist "-fnext-runtime -fobjc-abi-version=1"
+  }
 }
 if [info exists OBJC_RUNTIME_OPTIONS] {
   foreach other $OBJC_RUNTIME_OPTIONS {
diff --git a/gcc/testsuite/objc/compile/pr101666.m 
b/gcc/testsuite/objc/compile/pr101666.m
new file mode 100644
index 000..bfde52d3b35
--- /dev/null
+++ b/gcc/testsuite/objc/compile/pr101666.m
@@ -0,0 +1,15 @@
+struct point { double x, y, z; };
+
+@interface Foo
+
+- (struct point)bar;
+
+@end
+
+Foo *f;
+
+int
+main(void)
+{
+  struct point p = [f bar];
+}

[committed] Improve many SImode shifts on the H8/300H.

[Jeff Law via Gcc-patches]

As I've mentioned before, the H8/300H can only shift a single bit 
position at a time.  Naturally this means many shifts are implemented as 
loops.  There's a variety of special cases that we can do without loops 
by using rotates, sub-word moves, etc.  The general guidance for the 
port has been to only use inline or special sequences if they're shorter 
or just one instruction longer than the loop.


This was pretty reasonable guidance for QI/HI mode.  It was relaxed a 
bit about 10 years ago for HImode in particular where the kpit team 
realized they could save 50-100 cycles for some shifts by allowing 2 
instructions of code growth over the loop implementation.


But they only re-tuned HImode shifts.  There's even bigger benefits for 
re-tuning SImode shifts.  There's cases where we can save close to 200 
cycles by allowing 2 additional instructions.


This patch re-tunes SImode shifts on the H8/300H primarily by inlining 
more often or using a special sequence + inlining for residuals.  Both 
cases were already supported and this just uses those existing 
capabilities more often, so it was trivial to implement.  I think 
there's some cases were entirely new special sequences could be used, 
but I haven't tried those yet.


There'll be a similar follow-up for the H8/S.  The gains aren't as 
spectacular as the H8/S gained shift-by-2 instructions, but they should 
still be significant.




Committed to the trunk after the usual testing and no regressions.

Jeff
commit 882f1d58bfa56737ff2de84c3cd1e0acfc318b86
Author: Jeff Law 
Date:   Sun Aug 15 00:13:23 2021 -0400

Improve many SImode shifts on the H8/300H

As I've mentioned before, the H8/300H can only shift a single bit position 
at a time.  Naturally this means many shifts are implemented as loops.  There's 
a variety of special cases that we can do without loops by using rotates, 
sub-word moves, etc.  The general guidance for the port has been to only use 
inline or special sequences if they're shorter or just one instruction longer 
than the loop.

This was pretty reasonable guidance for QI/HI mode.  It was relaxed a bit 
about 10 years ago for HImode in particular where the kpit team realized they 
could save 50-100 cycles for some shifts by allowing 2 instructions of code 
growth over the loop implementation.

But they only re-tuned HImode shifts.  There's even bigger benefits for 
re-tuning SImode shifts.  There's cases where we can save close to 200 cycles 
by allowing 2 additional instructions.

This patch re-tunes SImode shifts on the H8/300H primarily by inlining more 
often or using a special sequence + inlining for residuals.  Both cases were 
already supported and this just uses those existing capabilities more often, so 
it was trivial to implement.  I think there's some cases were entirely new 
special sequences could be used, but I haven't tried those yet.

gcc/

* config/h8300/h8300.c (shift_alg_si): Retune H8/300H shifts
to allow a bit more code growth, saving many dozens of cycles.
(h8300_option_override): Adjus shift_alg_si if optimizing for
code size.
(get_shift_alg): Use special + inline shifts for residuals
in more cases.

diff --git a/gcc/config/h8300/h8300.c b/gcc/config/h8300/h8300.c
index d2f6548a265..7959ad1e276 100644
--- a/gcc/config/h8300/h8300.c
+++ b/gcc/config/h8300/h8300.c
@@ -228,18 +228,18 @@ static enum shift_alg shift_alg_si[2][3][32] = {
 /*  89   10   11   12   13   14   15  */
 /* 16   17   18   19   20   21   22   23  */
 /* 24   25   26   27   28   29   30   31  */
-{ INL, INL, INL, INL, INL, LOP, LOP, LOP,
+{ INL, INL, INL, INL, INL, INL, INL, LOP,
   SPC, LOP, LOP, LOP, LOP, LOP, LOP, SPC,
-  SPC, SPC, SPC, SPC, LOP, LOP, LOP, LOP,
-  SPC, LOP, LOP, LOP, SPC, SPC, SPC, SPC }, /* SHIFT_ASHIFT   */
-{ INL, INL, INL, INL, INL, LOP, LOP, LOP,
+  SPC, SPC, SPC, SPC, SPC, SPC, SPC, SPC,
+  SPC, SPC, SPC, SPC, SPC, SPC, SPC, SPC }, /* SHIFT_ASHIFT   */
+{ INL, INL, INL, INL, INL, INL, INL, LOP,
   SPC, LOP, LOP, LOP, LOP, LOP, LOP, SPC,
-  SPC, SPC, SPC, SPC, LOP, LOP, LOP, LOP,
-  SPC, LOP, LOP, LOP, SPC, SPC, SPC, SPC }, /* SHIFT_LSHIFTRT */
-{ INL, INL, INL, INL, INL, LOP, LOP, LOP,
+  SPC, SPC, SPC, SPC, SPC, SPC, SPC, SPC,
+  SPC, SPC, SPC, SPC, SPC, SPC, SPC, SPC }, /* SHIFT_LSHIFTRT */
+{ INL, INL, INL, INL, INL, INL, INL, LOP,
   SPC, LOP, LOP, LOP, LOP, LOP, LOP, LOP,
-  SPC, SPC, SPC, SPC, LOP, LOP, LOP, LOP,
-  SPC, LOP, LOP, LOP, LOP, LOP, LOP, SPC }, /* SHIFT_ASHIFTRT */
+  SPC, SPC, SPC, SPC, SPC, SPC, SPC, SPC,
+  SPC, SPC, SPC, SPC, LOP, LOP, LOP, SPC }, /* SHIFT_ASHIFTRT */
   },
   {
 /* TARGET_H8300S  */
@@ -343,6 +343,36 @@ h8300_option_override (void)
   shift_alg_hi[H8_300H][SHIFT_ASHIFTRT][13] = SHIFT_LOOP;
   shift_alg_hi[H8_300H][SHIFT_ASHIFTRT][14] = SHIFT_LOO

New German PO file for 'cpplib' (version 11.1-b20210207)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the German team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/de.po

(This file, 'cpplib-11.1-b20210207.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-11.1-b20210207.de.po'

[Translation Project Robot]

cpplib-11.1-b20210207.de.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] PR fortran/99351 - ICE in gfc_finish_var_decl, at fortran/trans-decl.c:695

[Tobias Burnus]

Der Harald, hi all,

On 11.08.21 21:25, Harald Anlauf via Fortran wrote:


the checks for the STAT= and ERRMSG= arguments to the coarray SYNC statements
did not properly handle several cases, such as named constants (parameters).
While fixing this, I adjusted the code similarly to what was recently done
for (DE)ALLOCATE.  We now also accept function references with data pointer
result.  (See also PR101652).

Regtested on x86_64-pc-linux-gnu.  OK for mainline?


OK.

Thanks,

Tobias

PS: I will try to review your remaining patches later today or tomorrow. 
I am also aware of more pending patches.



Fortran: fix checks for STAT= and ERRMSG= arguments of SYNC ALL/SYNC IMAGES

gcc/fortran/ChangeLog:

PR fortran/99351
* match.c (sync_statement): Replace %v code by %e in gfc_match to
allow for function references as STAT and ERRMSG arguments.
* resolve.c (resolve_sync): Adjust checks of STAT= and ERRMSG= to
being definable arguments.  Function references with a data
pointer result are accepted.
* trans-stmt.c (gfc_trans_sync): Adjust assertion.

gcc/testsuite/ChangeLog:

PR fortran/99351
* gfortran.dg/coarray_sync.f90: New test.
* gfortran.dg/coarray_3.f90: Adjust to change error messages.