Re: [PATCH] loongarch: ignore zero-size fields in calling convention

[Xi Ruoyao via Gcc-patches]

Ping.

Normally we shouldn't ping a patch after only a few days, but we're
running out of time to catch GCC 12 milestone.  And once GCC 12 is
released the patch will become far more complicated for a psABI warning.

And please note that the ABI difference between GCC and G++ should be
considered a bug, and it has to be fixed anyway.  If you don't like the
idea of this patch, please develop another solution and apply it *before
GCC 12*.

On Wed, 2022-04-20 at 14:23 +0800, Xi Ruoyao via Gcc-patches wrote:
> Currently, LoongArch ELF psABI is not clear on the handling of zero-
> sized fields in aggregates arguments or return values [1].  The behavior
> of GCC trunk is puzzling considering the following cases:
> 
> struct test1
> {
>   double a[0];
>   float x;
> };
> 
> struct test2
> {
>   float a[0];
>   float x;
> };
> 
> GCC trunk passes test1::x via GPR, but test2::x via FPR.  I believe no
> rational Homo Sapiens can understand (or even expect) this.
> 
> And, to make things even worse, test1 behaves differently in C and C++.
> GCC trunk passes test1::x via GPR, but G++ trunk passes test1::x via
> FPR.
> 
> I've write a paragraph about current GCC behavior for the psABI [2], but
> I think it's cleaner to just ignore all zero-sized fields in the ABI. 
> This will require only a two-line change in GCC (this patch), and an
> one-line change in the ABI doc.
> 
> If there is not any better idea I'd like to see this reviewed and
> applied ASAP.  If we finally have to apply this patch after GCC 12
> release, we'll need to add a lot more boring code to emit a -Wpsabi
> inform [3].  That will be an unnecessary burden for both us, and the
> users using the compiler (as the compiler will spend CPU time only for
> checking if a warning should be informed).
> 
> [1]:https://github.com/loongson/LoongArch-Documentation/issues/48
> [2]:https://github.com/loongson/LoongArch-Documentation/pull/49
> [3]:https://gcc.gnu.org/PR102024
> 
> gcc/
> 
> * config/loongarch/loongarch.cc
> (loongarch_flatten_aggregate_field): Ignore empty fields for
> RECORD_TYPE.
> 
> gcc/testsuite/
> 
> * gcc.target/loongarch/zero-size-field-pass.c: New test.
> * gcc.target/loongarch/zero-size-field-ret.c: New test.
> ---
>  gcc/config/loongarch/loongarch.cc |  3 ++
>  .../loongarch/zero-size-field-pass.c  | 30 +++
>  .../loongarch/zero-size-field-ret.c   | 28 +
>  3 files changed, 61 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
>  create mode 100644 gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c
> 
> diff --git a/gcc/config/loongarch/loongarch.cc 
> b/gcc/config/loongarch/loongarch.cc
> index f22150a60cc..57e4d9f82ce 100644
> --- a/gcc/config/loongarch/loongarch.cc
> +++ b/gcc/config/loongarch/loongarch.cc
> @@ -326,6 +326,9 @@ loongarch_flatten_aggregate_field (const_tree type,
>    for (tree f = TYPE_FIELDS (type); f; f = DECL_CHAIN (f))
> if (TREE_CODE (f) == FIELD_DECL)
>   {
> +   if (DECL_SIZE (f) && integer_zerop (DECL_SIZE (f)))
> + continue;
> +
>     if (!TYPE_P (TREE_TYPE (f)))
>   return -1;
>  
> diff --git a/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c 
> b/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
> new file mode 100644
> index 000..999dc913a71
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
> @@ -0,0 +1,30 @@
> +/* Test that LoongArch backend ignores zero-sized fields of aggregates in
> +   argument passing.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mdouble-float -mabi=lp64d" } */
> +/* { dg-final { scan-assembler "\\\$f1" } } */
> +
> +struct test
> +{
> +  int empty1[0];
> +  double empty2[0];
> +  int : 0;
> +  float x;
> +  long empty3[0];
> +  long : 0;
> +  float y;
> +  unsigned : 0;
> +  char empty4[0];
> +};
> +
> +extern void callee (struct test);
> +
> +void
> +caller (void)
> +{
> +  struct test test;
> +  test.x = 114;
> +  test.y = 514;
> +  callee (test);
> +}
> diff --git a/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c 
> b/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c
> new file mode 100644
> index 000..40137d97555
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c
> @@ -0,0 +1,28 @@
> +/* Test that LoongArch backend ignores zero-sized fields of aggregates in
> +   returning.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mdouble-float -mabi=lp64d" } */
> +/* { dg-final { scan-assembler-not "\\\$r4" } } */
> +
> +struct test
> +{
> +  int empty1[0];
> +  double empty2[0];
> +  int : 0;
> +  float x;
> +  long empty3[0];
> +  long : 0;
> +  float y;
> +  unsigned : 0;
> +  char empty4[0];
> +};
> +
> +extern struct test callee (void);
> +
> +float
> +caller (void)
> +{
> +  struct test test = callee ();
> +  return test.x + test.y;
> +}

-- 

[Bug c/105363] -ftree-slp-vectorize decreases performance significantly (x64)

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105363

--- Comment #2 from Hongtao.liu  ---
Looks like neither ICC nor LLVM vectorized the loop
https://godbolt.org/z/sbheqbE6Y

Re: [PATCH 0/1] RISC-V: Fix canonical extension order (K and J)

[Kito Cheng]

Hi Tsukasa:

LGTM, and did you mind adding Signed-off-by to your patch and resending again?
I think this patch is small enough and the copyright process should
not be a blocker for this patch :)

See also: https://gcc.gnu.org/dco.html


On Sun, Apr 24, 2022 at 1:25 PM Tsukasa OI  wrote:
>
> **note**
>
> My copyright assignment to FSF is not yet started (will start just after
> sending this patch).  Please take care of the assignment status.
>
>
>
> This patch fixes RISC-V's canonical extension order...
> from: "J" -> "K"
> to  : "K" -> "J"
> as per the RISC-V ISA Manual draft-20210402-1271737 or later.
>
> This bug in the GCC is currently harmless because neither J nor
> Zj* extensions are implemented.  Intention of this commit is for future-
> proofness.
>
> This patch corresponds following patch for GNU Binutils:
> 
> [My copyright assignment is done on GNU Binutils]
>
> References:
> 
> 
>
>
>
>
> Tsukasa OI (1):
>   RISC-V: Fix canonical extension order (K and J)
>
>  gcc/common/config/riscv/riscv-common.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> base-commit: ab54f6007c79711fc2192098d4ccc3c24e95f3e6
> --
> 2.32.0
>

Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

[Kito Cheng]

> > and so it doesn't make
> > sense to mandate any particular ordering.
>
> No. It affects Z* extension ordering...

+1, we really need the order in ISA spec so that we could know the
canonical order for z* exts.

[Bug c/105363] -ftree-slp-vectorize decreases performance significantly (x64)

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105363

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
STLF issues here.
 Performance counter stats for './12.out':

 1,248,728,604  ld_blocks.store_forward:u

   5.756169101 seconds time elapsed

   5.746946000 seconds user
   0.001999000 seconds sys


and this case doens't need IPA, it's SLP inside the loop which has
cross-iteration data-dependence, I think we need to prevent that.

#define N 5
int a[N];

void insertionsort(int a[], int n)
{
  int i, j;

  for (i = 1; i < n; i++) {
for (j = i-1; j >= 0 && a[j] > a[j+1]; j--) {
  int t  = a[j+1];
  a[j+1] = a[j];
  a[j]   = t;
}
  }
}

dump:

   [local count: 958878294]:
  MEM  [(int *)_37] = vect__4.9_45;
  ivtmp.17_47 = ivtmp.17_28 + 18446744073709551612;
  if (_11 != ivtmp.17_47)
goto ; [94.50%]
  else
goto ; [5.50%]

   [local count: 114863531]:
  ivtmp.25_50 = ivtmp.25_9 + 1;
  ivtmp.28_52 = ivtmp.28_51 + 4;
  if (ivtmp.25_50 != _59)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 1014686024]:
  # ivtmp.17_28 = PHI 
  _37 = (void *) ivtmp.17_28;
  vect__8.8_46 = MEM  [(int *)_37];
  vect__4.9_45 = VEC_PERM_EXPR ;
  _43 = BIT_FIELD_REF ;
  _44 = BIT_FIELD_REF ;
  if (_43 > _44)
goto ; [94.50%]
  else
goto ; [5.50%]

   [local count: 14196616]:

[Bug target/105339] [x86] missing AVX-512F scalef functions when optimization is disabled

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105339

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Hongyu Wang :

https://gcc.gnu.org/g:3c940d42701707559fabe49be99296f60fbc43e7

commit r12-8238-g3c940d42701707559fabe49be99296f60fbc43e7
Author: Hongyu Wang 
Date:   Fri Apr 22 14:42:30 2022 +0800

AVX512F: Add missing macro for mask(z?)_scalf_s[sd] [PR 105339]

Add missing macro under O0 and adjust macro format for scalf
intrinsics.

gcc/ChangeLog:

PR target/105339
* config/i386/avx512fintrin.h (_mm512_scalef_round_pd):
Add parentheses for parameters and djust format.
(_mm512_mask_scalef_round_pd): Ditto.
(_mm512_maskz_scalef_round_pd): Ditto.
(_mm512_scalef_round_ps): Ditto.
(_mm512_mask_scalef_round_ps): Ditto.
(_mm512_maskz_scalef_round_ps): Ditto.
(_mm_scalef_round_sd): Use _mm_undefined_pd.
(_mm_scalef_round_ss): Use _mm_undefined_ps.
(_mm_mask_scalef_round_sd): New macro.
(_mm_mask_scalef_round_ss): Ditto.
(_mm_maskz_scalef_round_sd): Ditto.
(_mm_maskz_scalef_round_ss): Ditto.

gcc/testsuite/ChangeLog:

PR target/105339
* gcc.target/i386/sse-14.c: Add tests for new macro.

[Bug fortran/105372] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type

[xudong.luo--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105372

Bug ID: 105372
   Summary: The result of the merge function is different when
it's type of parameters  is the extensions type of
derived type
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xudong@compiler-dev.com
  Target Milestone: ---

Whether the mask is a constant or a variable causes inconsistent results of the
merge function when it's type of parameters  is the extensions type of derived
type.
1.The mask is constant
Program test00
  Type t
Integer :: c
  End Type
  Type,Extends(t) :: t2
Integer :: c2
  End Type
  Class(t),Allocatable :: x,y,r
  logical :: ok = .true.
  x = t2(1,-1)
  y = t2(2,-2)
  r = merge (x,y,.true.)
  Select Type (z=>r)
  Type Is (t)
print *,z%c
  Type Is (t2)
print *,z%c,z%c2
  End Select
End Program
2. The mask is variable
Program test01
  Type t
Integer :: c
  End Type
  Type,Extends(t) :: t2
Integer :: c2
  End Type
  Class(t),Allocatable :: x,y,r
  logical :: ok = .true.
  integer :: i = 1
  x = t2(1,-1)
  y = t2(2,-2)
  r = merge (x,y,i == 1)
  Select Type (z=>r)
  Type Is (t)
print *,z%c
  Type Is (t2)
print *,z%c,z%c2
  End Select
End Program

[Bug fortran/105371] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type

[xudong.luo--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105371

Bug ID: 105371
   Summary: The result of the merge function is different when
it's type of parameters  is the extensions type of
derived type
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xudong@compiler-dev.com
  Target Milestone: ---

Created attachment 52862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52862=edit
output

Whether the mask is a constant or a variable causes inconsistent results of the
merge function when it's type of parameters  is the extensions type of derived
type.
1.The mask is constant
Program test00
  Type t
Integer :: c
  End Type
  Type,Extends(t) :: t2
Integer :: c2
  End Type
  Class(t),Allocatable :: x,y,r
  logical :: ok = .true.
  x = t2(1,-1)
  y = t2(2,-2)
  r = merge (x,y,.true.)
  Select Type (z=>r)
  Type Is (t)
print *,z%c
  Type Is (t2)
print *,z%c,z%c2
  End Select
End Program
2. The mask is variable
Program test01
  Type t
Integer :: c
  End Type
  Type,Extends(t) :: t2
Integer :: c2
  End Type
  Class(t),Allocatable :: x,y,r
  logical :: ok = .true.
  integer :: i = 1
  x = t2(1,-1)
  y = t2(2,-2)
  r = merge (x,y,i == 1)
  Select Type (z=>r)
  Type Is (t)
print *,z%c
  Type Is (t2)
print *,z%c,z%c2
  End Select
End Program

gcc-12-20220424 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20220424 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20220424/
and on various mirrors, see http://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 master 
revision 6b7441a46c771aa6ecdc0c8ed96197417d036b9a

You'll find:

 gcc-12-20220424.tar.xz   Complete GCC

  SHA256=56c5e14e2b30ffe44cfdf9eb1e63eaa0251633a3bd34d933ba7d4290d32dda17
  SHA1=3395e838c47aaefc47130c7f4d6cdb610f13463c

Diffs from 12-20220417 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.

[Bug c/105369] Improved diagnostics for code from statement expressions documentation [C component]

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105369

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #0)
> Anyways, that's it for the plain-C code from that page; I'll open a separate
> bug for the C++ if it turns out that that needs one, too.

OK I opened bug 105370 for that.

(In reply to Andrew Pinski from comment #2)
> I don't think there is a way to get a warning for the abs really and maybe
> not even wanted.

OK so forget that part I guess; how about the rest of it?

[Bug c++/105370] New: Improved diagnostics for code from statement expressions documentation [C++ component]

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105370

Bug ID: 105370
   Summary: Improved diagnostics for code from statement
expressions documentation [C++ component]
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic, documentation
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---

This is the C++ counterpart to bug 105369. Code is taken from GCC documentation
on Statement Expressions here:
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs

Testcase:

$ cat stmt_exprsxx.cc
class A
{
public:
int Foo(void);
};

int decay(void)
{
A a;
return ({a;}).Foo();
}

#define X decay
#define macro(a)  ({__typeof__(a) b = (a); b + 3; })
template T function(T a) { T b = a; return b + 3; }

void foobar()
{
  macro(X());
  function(X());
}
$

The documentation says that there might be surprising behavior about
temporaries and construction and destruction, which lead the documentation to
the conclusion that "[t]hese considerations mean that it is probably a bad idea
to use statement expressions of this form in header files that are designed to
work with C++." Perhaps there should be some warning about this (current code
doesn't print any warnings with -Wall -Wextra -Weffc++ -pedantic).

[Bug c/105369] Improved diagnostics for code from statement expressions documentation [C component]

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105369

--- Comment #2 from Andrew Pinski  ---
I don't think there is a way to get a warning for the abs really and maybe not
even wanted.
There should definitely be a cross reference to where the documentation says
inline functions are fast as macros if there is not already one.

[Bug c/105369] Improved diagnostics for code from statement expressions documentation [C component]

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105369

--- Comment #1 from Eric Gallager  ---
Oh, I should probably add something to test the sentence that says, "If you
don’t know the type of the operand, you can still do this, but you must use
typeof or __auto_type (see Typeof)," too...

[Bug c/105369] New: Improved diagnostics for code from statement expressions documentation [C component]

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105369

Bug ID: 105369
   Summary: Improved diagnostics for code from statement
expressions documentation [C component]
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic, documentation
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---

So, I'm going back to reading GCC documentation again; I last left off with the
statement expressions documentation:
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs

I made this testcase from the plain-C code on that page:

$ cat stmt_exprs.c
int foo(void);
extern int global_var;

int compound_stmt(void)
{
global_var++;
return ({ int y = foo(); int z;
if (y > 0) z = y;
else z = -y;
z; });
}

#define max_bad(a,b) ((a) > (b) ? (a) : (b))
#define maxint(a,b) \
  ({int _a = (a), _b = (b); (_a > _b) ? _a : _b; })

int unsafe(void)
{
/* side effects: */
return max_bad(foo(), compound_stmt());
}

int shadowing1(void)
{
int _a = 1, _b = 2, c;
c = max_bad(_a, _b);
return c;
}

int shadowing2(void)
{
int _a = 1, _b = 2, c;
c = maxint(_a, _b);
return c;
}

#define maxint3(a, b, c) \
  ({int _a = (a), _b = (b), _c = (c); maxint(maxint(_a, _b), _c); })

int shadowing3(void)
{
int _a = 1, _b = 2, _c = 3, d;
d = maxint3(_a, _b, _c);
return d;
}

void bar1(void);
int bar2(void);
int baz(void);

int jumping(void)
{
a:
return foo(), (({ bar1(); goto a; 0; }) + bar2()), baz();
}
$

The documentation says that the statement expression in compound_stmt() is a
"valid (though slightly more complex than necessary) expression" (for getting
an absolute value); maybe there could be a warning to just use abs() instead?
It could go under the existing -Wabsolute-value flag. Next, in unsafe(), the
documentation says that that usage of max_bad() "computes either a or b twice,
with bad results if the operand has side effects", which deserves a warning,
IMO; Karen Pease took advantage of this property of C to win the 2014
"Underhanded C Contest": http://www.underhanded-c.org/_page_id_26.html

As for the 3 shadowing functions, there are plenty of warnings from -Wshadow
and -Wunused-variable there already, so they're probably fine, although it
might help to clean up the display of them a bit. In the final function,
jumping(), the documentation says it "calls foo and bar1 and does not call baz
but may or may not call bar2. If bar2 is called, it is called after foo and
before bar1." This behavior may be surprising. However, there is no warning for
code like that with -Wall -Wextra -Wjump-misses-init. Perhaps there should be
one? Anyways, that's it for the plain-C code from that page; I'll open a
separate bug for the C++ if it turns out that that needs one, too.

[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O

[tkoenig at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361

--- Comment #2 from Thomas Koenig  ---
As expected:

FAIL: gfortran.dg/list_read_8.f90   -O0  execution test
FAIL: gfortran.dg/list_read_8.f90   -O1  execution test
FAIL: gfortran.dg/list_read_8.f90   -O2  execution test
FAIL: gfortran.dg/list_read_8.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/list_read_8.f90   -O3 -g  execution test
FAIL: gfortran.dg/list_read_8.f90   -Os  execution test
FAIL: gfortran.dg/streamio_16.f90   -O0  execution test
FAIL: gfortran.dg/streamio_16.f90   -O1  execution test
FAIL: gfortran.dg/streamio_16.f90   -O2  execution test
FAIL: gfortran.dg/streamio_16.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/streamio_16.f90   -O3 -g  execution test
FAIL: gfortran.dg/streamio_16.f90   -Os  execution test

It might work to not call hit_eof only in the specific case
(doing list-directed input in the user-defined I/O from
within a list-directed input).

[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O

[tkoenig at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361

--- Comment #1 from Thomas Koenig  ---
This "fixes" the bug in question, but is almost certainly entirely
incorrect for a lot of other cases.  Will have to look a bit further.

--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2364,13 +2364,13 @@ finish_list_read (st_parameter_dt *dtp)
   if (likely (dtp->u.p.child_saved_iostat == LIBERROR_OK))
{
  c = next_char (dtp);
  if (c == EOF)
{
  free_line (dtp);
- hit_eof (dtp);
+ // hit_eof (dtp);
  return;
}
  if (c != '\n')
eat_line (dtp);
}
 }

[Bug tree-optimization/105368] New: [10/11/12 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368

Bug ID: 105368
   Summary: [10/11/12 Regression] ICE: SIGSEGV in powi_lookup_cost
(tree-ssa-math-opts.cc:1441) with -Ofast and
__builtin_powf()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 52861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52861=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Ofast testcase.c -wrapper valgrind,-q
==11132== Invalid read of size 1
==11132==at 0x15381AE: powi_lookup_cost (tree-ssa-math-opts.cc:1441)
==11132==by 0x15381AE: powi_cost(long) [clone .part.0]
(tree-ssa-math-opts.cc:1489)
==11132==by 0x153EA67: powi_cost (tree-ssa-math-opts.cc:1461)
==11132==by 0x153EA67: gimple_expand_builtin_pow(gimple_stmt_iterator*,
unsigned int, tree_node*, tree_node*) (tree-ssa-math-opts.cc:2048)
==11132==by 0x153EDE9: (anonymous
namespace)::pass_cse_sincos::execute(function*) (tree-ssa-math-opts.cc:2317)
==11132==by 0x1298129: execute_one_pass(opt_pass*) (passes.cc:2638)
==11132==by 0x12989EF: execute_pass_list_1(opt_pass*) (passes.cc:2738)
==11132==by 0x1298A01: execute_pass_list_1(opt_pass*) (passes.cc:2739)
==11132==by 0x1298A28: execute_pass_list(function*, opt_pass*)
(passes.cc:2749)
==11132==by 0xEBD785: expand (cgraphunit.cc:1835)
==11132==by 0xEBD785: cgraph_node::expand() (cgraphunit.cc:1788)
==11132==by 0xEBED1F: expand_all_functions (cgraphunit.cc:1999)
==11132==by 0xEBED1F: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2349)
==11132==by 0xEC1957: compile (cgraphunit.cc:2262)
==11132==by 0xEC1957: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2530)
==11132==by 0x13A405F: compile_file() (toplev.cc:479)
==11132==by 0xD0523D: do_compile (toplev.cc:2168)
==11132==by 0xD0523D: toplev::main(int, char**) (toplev.cc:2320)
==11132==  Address 0x801ffeffec10 is not stack'd, malloc'd or (recently)
free'd
==11132== 
during GIMPLE pass: sincos
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: Segmentation fault
6 | foo (short s, long l)
  | ^~~
0x13a3d9f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:322
0x15381ae powi_lookup_cost
/repo/gcc-trunk/gcc/tree-ssa-math-opts.cc:1441
0x15381ae powi_cost
/repo/gcc-trunk/gcc/tree-ssa-math-opts.cc:1489
0x153ea67 powi_cost
/repo/gcc-trunk/gcc/tree-ssa-math-opts.cc:1461
0x153ea67 gimple_expand_builtin_pow
/repo/gcc-trunk/gcc/tree-ssa-math-opts.cc:2048
0x153ede9 execute
/repo/gcc-trunk/gcc/tree-ssa-math-opts.cc:2317
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-8236-20220424133922-g6b7441a46c7-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-8236-20220424133922-g6b7441a46c7-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220424 (experimental) (GCC)

[Bug tree-optimization/105367] New: [12 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Ofast -mveclibabi=acml

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105367

Bug ID: 105367
   Summary: [12 Regression] ICE: SIGSEGV in contains_struct_check
(tree.h:3570) with -Ofast -mveclibabi=acml
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 52860
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52860=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Ofast -mveclibabi=acml testcase.c -wrapper
valgrind,-q
==27510== Invalid read of size 2
==27510==at 0x172F0A7: contains_struct_check (tree.h:3570)
==27510==by 0x172F0A7: ix86_veclibabi_acml(combined_fn, tree_node*,
tree_node*) (i386.cc:18903)
==27510==by 0x24C3B67: vectorizable_call(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, gimple**, _slp_tree*, vec*) (tree-vect-stmts.cc:3435)
==27510==by 0x24D4CDC: vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*,
_slp_tree*, _slp_instance*, vec*)
(tree-vect-stmts.cc:11173)
==27510==by 0x1641EF8: vect_slp_analyze_node_operations_1
(tree-vect-slp.cc:4501)
==27510==by 0x1641EF8: vect_slp_analyze_node_operations(vec_info*,
_slp_tree*, _slp_instance*, hash_set<_slp_tree*, false,
default_hash_traits<_slp_tree*> >&, vec<_slp_tree*, va_heap, vl_ptr>&,
vec*) (tree-vect-slp.cc:4685)
==27510==by 0x164363A: vect_slp_analyze_operations(vec_info*)
(tree-vect-slp.cc:4924)
==27510==by 0x164906B: vect_slp_analyze_bb_1 (tree-vect-slp.cc:5892)
==27510==by 0x164906B: vect_slp_region(vec, vec, vec*,
unsigned int, loop*) (tree-vect-slp.cc:5939)
==27510==by 0x164A864: vect_slp_bbs(vec
const&, loop*) (tree-vect-slp.cc:6130)
==27510==by 0x164AC2C: vect_slp_function(function*) (tree-vect-slp.cc:6218)
==27510==by 0x1652A32: (anonymous
namespace)::pass_slp_vectorize::execute(function*) (tree-vectorizer.cc:1506)
==27510==by 0x1298129: execute_one_pass(opt_pass*) (passes.cc:2638)
==27510==by 0x12989EF: execute_pass_list_1(opt_pass*) (passes.cc:2738)
==27510==by 0x1298A01: execute_pass_list_1(opt_pass*) (passes.cc:2739)
==27510==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==27510== 
during GIMPLE pass: slp
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: Segmentation fault
4 | foo() {
  | ^~~
0x13a3d9f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:322
0x172f0a7 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/repo/gcc-trunk/gcc/tree.h:3570
0x172f0a7 ix86_veclibabi_acml(combined_fn, tree_node*, tree_node*)
/repo/gcc-trunk/gcc/config/i386/i386.cc:18903
0x24c3b67 vectorizable_call
/repo/gcc-trunk/gcc/tree-vect-stmts.cc:3435
0x24d4cdc vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/repo/gcc-trunk/gcc/tree-vect-stmts.cc:11173
0x1641ef8 vect_slp_analyze_node_operations_1
/repo/gcc-trunk/gcc/tree-vect-slp.cc:4501
0x1641ef8 vect_slp_analyze_node_operations
/repo/gcc-trunk/gcc/tree-vect-slp.cc:4685
0x164363a vect_slp_analyze_operations(vec_info*)
/repo/gcc-trunk/gcc/tree-vect-slp.cc:4924
0x164906b vect_slp_analyze_bb_1
/repo/gcc-trunk/gcc/tree-vect-slp.cc:5892
0x164906b vect_slp_region
/repo/gcc-trunk/gcc/tree-vect-slp.cc:5939
0x164a864 vect_slp_bbs
/repo/gcc-trunk/gcc/tree-vect-slp.cc:6130
0x164ac2c vect_slp_function(function*)
/repo/gcc-trunk/gcc/tree-vect-slp.cc:6218
0x1652a32 execute
/repo/gcc-trunk/gcc/tree-vectorizer.cc:1506
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-8236-20220424133922-g6b7441a46c7-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-8236-20220424133922-g6b7441a46c7-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220424 (experimental) (GCC)

[Bug analyzer/105366] New: [11/12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366

Bug ID: 105366
   Summary: [11/12 Regression] ICE: in cmp_cst, at
analyzer/svalue.cc:309 with -O -fanalyzer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 52859
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52859=edit
reduced testcase

The testcase got quite ugly while reducing (taking address of functions), but
it ICEs the same way as the original testcase; this might be different than
PR105365 , since this also fails in gcc-11

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fanalyzer testcase.c 
during IPA pass: analyzer
testcase.c: In function 'foo':
testcase.c:13:7: internal compiler error: in cmp_cst, at analyzer/svalue.cc:309
   13 |   u32 r = u + c;
  |   ^
0x8341f0 cmp_cst
/repo/gcc-trunk/gcc/analyzer/svalue.cc:309
0x17bd00d cmp_cst
/repo/gcc-trunk/gcc/analyzer/svalue.cc:326
0x17bd3fa ana::svalue::cmp_ptr(ana::svalue const*, ana::svalue const*)
/repo/gcc-trunk/gcc/analyzer/svalue.cc:435
0x256c220 cmp1
/repo/gcc-trunk/gcc/sort.cc:153
0x256c274 netsort
/repo/gcc-trunk/gcc/sort.cc:170
0x256c274 mergesort
/repo/gcc-trunk/gcc/sort.cc:207
0x256c7ff gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
/repo/gcc-trunk/gcc/sort.cc:266
0x175632f vec::qsort(int (*)(void
const*, void const*))
/repo/gcc-trunk/gcc/vec.h:1147
0x175632f vec::qsort(int (*)(void const*,
void const*))
/repo/gcc-trunk/gcc/vec.h:2121
0x175632f ana::program_state::detect_leaks(ana::program_state const&,
ana::program_state const&, ana::svalue const*, ana::extrinsic_state const&,
ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/program-state.cc:1420
0x17566c9 ana::program_state::prune_for_point(ana::exploded_graph&,
ana::program_point const&, ana::exploded_node*, ana::uncertainty_t*) const
/repo/gcc-trunk/gcc/analyzer/program-state.cc:1214
0x1744361 ana::exploded_graph::process_node(ana::exploded_node*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:3780
0x174520a ana::exploded_graph::process_worklist()
/repo/gcc-trunk/gcc/analyzer/engine.cc:3198
0x174754b ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:5777
0x1748443 ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:5851
0x1738138 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-8236-20220424133922-g6b7441a46c7-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-8236-20220424133922-g6b7441a46c7-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220424 (experimental) (GCC)

[Bug analyzer/105365] New: [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -fanalyzer

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365

Bug ID: 105365
   Summary: [12 Regression] ICE: in cmp_cst, at
analyzer/svalue.cc:309 with -fanalyzer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 52858
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52858=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fanalyzer testcase.c 
during IPA pass: analyzer
testcase.c: In function 'foo':
testcase.c:13:9: internal compiler error: in cmp_cst, at analyzer/svalue.cc:309
   13 |   bar(f + k);
  |   ~~^~~
0x8341f0 cmp_cst
/repo/gcc-trunk/gcc/analyzer/svalue.cc:309
0x17bd00d cmp_cst
/repo/gcc-trunk/gcc/analyzer/svalue.cc:326
0x17bd3fa ana::svalue::cmp_ptr(ana::svalue const*, ana::svalue const*)
/repo/gcc-trunk/gcc/analyzer/svalue.cc:435
0x256c220 cmp1
/repo/gcc-trunk/gcc/sort.cc:153
0x256c274 netsort
/repo/gcc-trunk/gcc/sort.cc:170
0x256c274 mergesort
/repo/gcc-trunk/gcc/sort.cc:207
0x256c7ff gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
/repo/gcc-trunk/gcc/sort.cc:266
0x175632f vec::qsort(int (*)(void
const*, void const*))
/repo/gcc-trunk/gcc/vec.h:1147
0x175632f vec::qsort(int (*)(void const*,
void const*))
/repo/gcc-trunk/gcc/vec.h:2121
0x175632f ana::program_state::detect_leaks(ana::program_state const&,
ana::program_state const&, ana::svalue const*, ana::extrinsic_state const&,
ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/program-state.cc:1420
0x17566c9 ana::program_state::prune_for_point(ana::exploded_graph&,
ana::program_point const&, ana::exploded_node*, ana::uncertainty_t*) const
/repo/gcc-trunk/gcc/analyzer/program-state.cc:1214
0x1744361 ana::exploded_graph::process_node(ana::exploded_node*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:3780
0x174520a ana::exploded_graph::process_worklist()
/repo/gcc-trunk/gcc/analyzer/engine.cc:3198
0x174754b ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:5777
0x1748443 ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:5851
0x1738138 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[committed] exec-stack warning for test which wants executable stacks

[Jeff Law via Gcc]

About a week ago many targets started failing pr94157_0.c test like this 
(bfin-elf, but many other targets are also affected):


spawn -ignore SIGHUP /home/jlaw/test/obj/bfin-elf/obj/gcc/gcc/xgcc 
-B/home/jlaw/test/obj/bfin-elf/obj/gcc/gcc/ c_lto_pr94157_0.o 
-fdiagnostics-plain-output -dumpbase  -O0 -fipa-vrp -flto 
-Wa,--noexecstack -Wa,--noexecstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -msim 
-Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort 
-Wl,gcc_tg.o -o gcc-dg-lto-pr94157-01.exe^M
/home/jlaw/test/obj/bfin-elf/installed/bfin-elf/bin/ld: warning: 
/tmp/ccfJUEvZ.ltrans0.ltrans.o: requires executable stack (because the 
.note.GNU-stack section is executable)^M
FAIL: gcc.dg/lto/pr94157 c_lto_pr94157_0.o-c_lto_pr94157_0.o link,  
-O0 -fipa-vrp -flto -Wa,--noexecstack -Wa,--noexecstack 
-Wa,--execstack  -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack


This is due to a new binutils warning.  This patch just suppresses the 
warning for the one test where we explicitly wanted an executable stack.


I'm guessing the repeated -Wa,--noexecstack options in this test are 
supposed to trigger a  buffer overflow or something similar, so I left 
those alone and just appended to the argument list.


I used -z execstack rather than --no-warn-execstack as the former is 
recognized by older versions of ld, but the latter is a new option.


The other approach would have been to prune the warning, but this seemed 
better since we'd like most tests to fail if somehow their stacks were 
executable.



Committed to the trunk.

Jeff

commit 6b7441a46c771aa6ecdc0c8ed96197417d036b9a
Author: Jeff Law 
Date:   Sun Apr 24 13:38:14 2022 -0400

[committed] exec-stack warning for test which wants executable stacks

gcc/testsuite
* gcc.dg/lto/pr94157_0.c: Also request executable stack from
the linker.

diff --git a/gcc/testsuite/gcc.dg/lto/pr94157_0.c 
b/gcc/testsuite/gcc.dg/lto/pr94157_0.c
index a6e308b855b..a76141b1809 100644
--- a/gcc/testsuite/gcc.dg/lto/pr94157_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr94157_0.c
@@ -1,6 +1,6 @@
 /* { dg-lto-do link } */
 /* { dg-require-effective-target gas } */
-/* { dg-lto-options { { -O0 -fipa-vrp -flto -Wa,--noexecstack 
-Wa,--noexecstack -Wa,--execstack  -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack } } } */
+/* { dg-lto-options { { -O0 -fipa-vrp -flto -Wa,--noexecstack 
-Wa,--noexecstack -Wa,--execstack  -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wl,-z,execstack} } } */
 
 int main() {
 

[no subject]

[Ashlyn Harris via Gcc]

Greetings

my name is Ashlyn Harris I would love to know you better please reply me

[Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Mikael Morin
:

https://gcc.gnu.org/g:4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809

commit r10-10554-g4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809
Author: Mikael Morin 
Date:   Fri Jan 28 22:00:57 2022 +0100

fortran: Backport associate character length fixes [PR104228]

Backport commits:
r12-7217-g57da34939703a6e6d3267a0d25d1fb9369d3ac0e
r12-7726-g907811ddc35da6c1701ed22355ece63a8c3ed7fb

--

fortran: Unshare associate var charlen [PR104228]

PR104228 showed that character lengths were shared between associate
variable and associate targets.  This is problematic when the associate
target is itself a variable and gets a variable to hold the length, as
the length variable is added (and all the variables following it in the
chain)
to both the associate variable scope and the target variable scope.
This caused an ICE when compiling with -O0 -fsanitize=address.

This change forces the creation of a separate character length for the
associate variable.  It also forces the initialization of the character
length variable to avoid regressing associate_32 and associate_47 tests.

--

fortran: Separate associate character lengths earlier [PR104570]

This change workarounds an ICE in the evaluation of the character length
of an array expression referencing an associate variable; the code is
not prepared to see a non-scalar expression as it doesnât initialize the
scalarizer.

Before this change, associate length symbols get a new gfc_charlen at
resolution stage to unshare them from the associate expression, so that
at translation stage it is a decl specific to the associate symbol that
is initialized, not the decl of some other symbol.  This
reinitialization of gfc_charlen happens after expressions referencing
the associate symbol have been parsed, so that those expressions retain
the original gfc_charlen they have copied from the symbol.
At translation stage, the gfc_charlen for the associate symbol is setup
with the decl holding the actual length value, but the expressions have
retained the original gfc_charlen without any decl.  So they need to
evaluate the character length, and this is where the ICE happens.

This change moves the reinitialization of gfc_charlen earlier at parsing
stage, so that at resolution stage the gfc_charlen can be retained as
itâs already not shared with any other symbol, and the expressions which
now share their gfc_charlen with the symbol are automatically updated
when the length decl is setup at translation stage.  There is no need
any more to evaluate the character length as it has all the required
information, and the ICE doesnât happen.

The first resolve.c hunk is necessary to avoid regressing on the
associate_35.f90 testcase.

--

PR fortran/104228
PR fortran/104570

gcc/fortran/ChangeLog:

* parse.c (parse_associate): Use a new distinct gfc_charlen if
the copied type has one whose length is not known to be
constant.
* resolve.c (resolve_assoc_var): Also create a new character
length for non-dummy associate targets.  Reset charlen if itâs
shared with the associate target regardless of the expression
type.  Donât reinitialize charlen if itâs deferred.
* trans-stmt.c (trans_associate_var): Initialize character
length even if no temporary is used for the associate variable.

gcc/testsuite/ChangeLog:

* gfortran.dg/asan_associate_58.f90: New test.
* gfortran.dg/asan_associate_59.f90: New test.
* gfortran.dg/associate_58.f90: New test.

[Bug fortran/104570] [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3681 since r12-7217-g57da34939703a6e6

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Mikael Morin
:

https://gcc.gnu.org/g:4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809

commit r10-10554-g4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809
Author: Mikael Morin 
Date:   Fri Jan 28 22:00:57 2022 +0100

fortran: Backport associate character length fixes [PR104228]

Backport commits:
r12-7217-g57da34939703a6e6d3267a0d25d1fb9369d3ac0e
r12-7726-g907811ddc35da6c1701ed22355ece63a8c3ed7fb

--

fortran: Unshare associate var charlen [PR104228]

PR104228 showed that character lengths were shared between associate
variable and associate targets.  This is problematic when the associate
target is itself a variable and gets a variable to hold the length, as
the length variable is added (and all the variables following it in the
chain)
to both the associate variable scope and the target variable scope.
This caused an ICE when compiling with -O0 -fsanitize=address.

This change forces the creation of a separate character length for the
associate variable.  It also forces the initialization of the character
length variable to avoid regressing associate_32 and associate_47 tests.

--

fortran: Separate associate character lengths earlier [PR104570]

This change workarounds an ICE in the evaluation of the character length
of an array expression referencing an associate variable; the code is
not prepared to see a non-scalar expression as it doesnât initialize the
scalarizer.

Before this change, associate length symbols get a new gfc_charlen at
resolution stage to unshare them from the associate expression, so that
at translation stage it is a decl specific to the associate symbol that
is initialized, not the decl of some other symbol.  This
reinitialization of gfc_charlen happens after expressions referencing
the associate symbol have been parsed, so that those expressions retain
the original gfc_charlen they have copied from the symbol.
At translation stage, the gfc_charlen for the associate symbol is setup
with the decl holding the actual length value, but the expressions have
retained the original gfc_charlen without any decl.  So they need to
evaluate the character length, and this is where the ICE happens.

This change moves the reinitialization of gfc_charlen earlier at parsing
stage, so that at resolution stage the gfc_charlen can be retained as
itâs already not shared with any other symbol, and the expressions which
now share their gfc_charlen with the symbol are automatically updated
when the length decl is setup at translation stage.  There is no need
any more to evaluate the character length as it has all the required
information, and the ICE doesnât happen.

The first resolve.c hunk is necessary to avoid regressing on the
associate_35.f90 testcase.

--

PR fortran/104228
PR fortran/104570

gcc/fortran/ChangeLog:

* parse.c (parse_associate): Use a new distinct gfc_charlen if
the copied type has one whose length is not known to be
constant.
* resolve.c (resolve_assoc_var): Also create a new character
length for non-dummy associate targets.  Reset charlen if itâs
shared with the associate target regardless of the expression
type.  Donât reinitialize charlen if itâs deferred.
* trans-stmt.c (trans_associate_var): Initialize character
length even if no temporary is used for the associate variable.

gcc/testsuite/ChangeLog:

* gfortran.dg/asan_associate_58.f90: New test.
* gfortran.dg/asan_associate_59.f90: New test.
* gfortran.dg/associate_58.f90: New test.

[Bug preprocessor/105362] Improvement: diagnose undefined behavior in preprocessing directives

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105362

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c   |preprocessor

--- Comment #1 from Andrew Pinski  ---
The preprocessor has its own constant folding and diagnostics

[PATCH] libstdc++: Add pretty printer for std::initializer_list

[Philipp Fent via Gcc-patches]

Re-using the std::span printer, this now shows the contents of the
initializer list instead of the pointer and length members.

Signed-off-by: Philipp Fent 
---
 libstdc++-v3/python/libstdcxx/v6/printers.py  | 23 +--
 .../libstdc++-prettyprinters/cxx11.cc |  6 +
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 6d8b765f2..48798b6c1 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -1657,7 +1657,7 @@ class StdRegexStatePrinter:
 class StdSpanPrinter:
 "Print a std::span"
 
-class _iterator(Iterator):
+class iterator(Iterator):
 def __init__(self, begin, size):
 self.count = 0
 self.begin = begin
@@ -1686,7 +1686,24 @@ class StdSpanPrinter:
 return '%s of length %d' % (self.typename, self.size)
 
 def children(self):
-return self._iterator(self.val['_M_ptr'], self.size)
+return self.iterator(self.val['_M_ptr'], self.size)
+
+def display_hint(self):
+return 'array'
+
+class StdInitializerListPrinter:
+"Print a std::initializer_list"
+
+def __init__(self, typename, val):
+self.typename = typename
+self.val = val
+self.size = val['_M_len']
+
+def to_string(self):
+return '%s of length %d' % (self.typename, self.size)
+
+def children(self):
+return StdSpanPrinter.iterator(self.val['_M_array'], self.size)
 
 def display_hint(self):
 return 'array'
@@ -2156,6 +2173,8 @@ def build_libstdcxx_dictionary ():
 libstdcxx_printer.add_version('std::tr1::', 'unordered_multiset',
   Tr1UnorderedSetPrinter)
 
+libstdcxx_printer.add_version('std::', 'initializer_list', 
StdInitializerListPrinter)
+
 # std::regex components
 libstdcxx_printer.add_version('std::__detail::', '_State',
   StdRegexStatePrinter)
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
index 4262ca88b..621d13bd0 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "../util/testsuite_allocator.h" // NullablePointer
 
 typedef std::tuple ExTuple;
@@ -191,6 +192,11 @@ main()
   std::error_code ecfut0 = std::make_error_code(std::future_errc{});
   // { dg-final { note-test ecfut0 {std::error_code = {"future": 0}} } }
 
+  std::initializer_list emptyIl = {};
+  // { dg-final { note-test emptyIl {std::initializer_list of length 0} } }
+  std::initializer_list il = {3, 4};
+  // { dg-final { note-test il {std::initializer_list of length 2 = {3, 4}} } }
+
   placeholder(""); // Mark SPOT
   use(efl);
   use(fl);
-- 
2.36.0

[Bug plugins/105364] New: lto-wrapper generates URLs escape sequences despite -fdiagnostic-urls=never

[wavexx at thregr dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105364

Bug ID: 105364
   Summary: lto-wrapper generates URLs escape sequences despite
-fdiagnostic-urls=never
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wavexx at thregr dot org
  Target Milestone: ---

Warnings generated by lto-wrapper do not seem to check the current terminal
settings (TERM=dumb doesn't do anything useful) and/or even respect
-fdiagnostics-urls=never provided while linking:

gcc -Wl,--as-needed -fdiagnostics-urls=never -fPIE -pie -fuse-ld=mold -flto -o
spectrwm spectrwm.o linux.o -lX11-xcb -lX11 -lxcb-icccm -lxcb-keysyms
-lxcb-randr -lxcb-util -lxcb -lxcb-xinput -lxcb-xtest -lXcursor -lXft 
lto-wrapper: warning: using serial compilation of 3 LTRANS jobs
lto-wrapper: note: see the
]8;;https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto‘-flto’
option documentation]8;; for more information

(note the inline escape ESC ] 8)

% gcc --version
gcc (Debian 12-20220319-1) 12.0.1 20220319 (experimental) [master
r12-7719-g8ca61ad148f]

[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349

--- Comment #2 from Segher Boessenkool  ---
Oh, or you didn't see the next commit?

[Bug c/90181] Feature request: provide a way to explicitly select specific named registers in constraints

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181

--- Comment #14 from Segher Boessenkool  ---
It is *impossible* to have the stack registers as inputs to an inline asm, and
reliably generate correct code for it that does what the writer of that code
expected: loading up the operands to the asm may modify the stack registers, so
which of the values does the asm expect, the old or the new value?

It is *impossible* to have stack registers as output (or scratch) from an
inline asm, always.  This violates basic requirements.

"Stack registers" here are those used by the ABI to address the stack, which
are required to be valid at all times, for example.  Stack pointer, (hard)
frame pointer, that kind of thing.  Most archs have register classes that
include such registers, like x86's "R", but crucially always other registers
are allowed there as well.

[Bug c/105363] New: -ftree-slp-vectorize decreases performance significantly (x64)

[mtzguido at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105363

Bug ID: 105363
   Summary: -ftree-slp-vectorize decreases performance
significantly (x64)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mtzguido at gmail dot com
  Target Milestone: ---

Created attachment 52857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52857=edit
Source file and outputs

Hello,

I found this example where using -O2 (which implies -ftree-slp-vectorize)
decreases performance by about 4x wrt -O1. I've pinned it down to the
-ftree-slp-vectorize, and -O3 -fno-tree-slp-vectorize works very well.

   $ gcc bug_opt.c -O3 -o bug_opt-O3
   $ time ./bug_opt-O3

   real 0m6.627s
   user 0m6.619s
   sys  0m0.005s

   $ gcc bug_opt.c -O3 -fno-tree-slp-vectorize -o bug_opt-O3-novec
   $ time ./bug_opt-O3-novec

   real 0m1.703s
   user 0m1.701s
   sys  0m0.000s

I've verified this with the current HEAD (1ceddd7497) and with 11.2 (though in
that version -O2 does not imply -ftree-slp-vectorize, so the problem starts to
appear at -O3).

I've minimized the example into a pretty basic insertion sort.

I have not checked the generated assembly.

I'm attaching the .c source, which has some more comments with timings. Also
attaching my /proc/cpuinfo, and the temp files generated with -O3. I imagine
the .o and binary is not too helpful, but can send them if needed.

Thanks,
Guido

[Bug c/105362] New: Improvement: diagnose undefined behavior in preprocessing directives

[pavel.morozkin at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105362

Bug ID: 105362
   Summary: Improvement: diagnose undefined behavior in
preprocessing directives
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel.morozkin at gmail dot com
  Target Milestone: ---

#if 1 << -1
#endif

$ gcc -std=c11 -pedantic -Wall -Wextra -O3 -c

Expected diagnostics:
warning: left shift count is negative [-Wshift-count-negative]

Actual diagnostics:

[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:fa5cd7102da676dcb1757b1288421f5f3439ae0e

commit r12-8235-gfa5cd7102da676dcb1757b1288421f5f3439ae0e
Author: Mikael Morin 
Date:   Sun Apr 24 15:05:41 2022 +0200

fortran: Detect duplicate unlimited polymorphic types [PR103662]

This fixes a type-based alias analysis issue with unlimited polymorphic
class descriptors (types behind class(*)) causing data initialisation to
be removed by optimization.

The fortran front-end may create multiple declarations for types, for
example if a type is redeclared in each program unit it is used in.
To avoid optimization seeing them as non-aliasing, a list of derived
types is created at resolution time, and used at translation to set
the same TYPE_CANONICAL type for each duplicate type declaration.

This mechanism didnât work for unlimited polymorphic descriptors types,
as there is a short-circuit return skipping all the resolution handling
for them, including the type registration.

This change adds type registration at the short-circuit return, and
updates type comparison to handle specifically unlimited polymorphic
fake symbols, class descriptor types and virtual table types.

The test, which exhibited mismatching dynamic types had to be fixed as
well.

PR fortran/103662

gcc/fortran/ChangeLog:

* interface.cc (gfc_compare_derived_types): Support comparing
unlimited polymorphic fake symbols.  Recursively compare class
descriptor types and virtual table types.
* resolve.cc (resolve_fl_derived): Add type to the types list
on unlimited polymorphic short-circuit return.

gcc/testsuite/ChangeLog:

* gfortran.dg/unlimited_polymorphic_3.f03 (foo): Separate
bind(c) and sequence checks to...
(foo_bc, foo_sq): ... two different procedures.
(main, foo*): Change type declarations so that type name,
component name, and either bind(c) or sequence attribute match
between the main type declarations and the procedure type
declarations.
(toplevel): Add optimization dump checks.

Co-Authored-By: Jakub Jelinek 

[Bug sanitizer/105336] truncated address sanitizer stack traces

[avi at scylladb dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336

--- Comment #6 from Avi Kivity  ---
(the reproducer was executed by gcc 12 prerelease, not gcc 11)

[Bug sanitizer/105336] truncated address sanitizer stack traces

[avi at scylladb dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336

--- Comment #5 from Avi Kivity  ---
I reduced it to a few lines (attached, intentionally triggers use-after-free).
The culprit is -Og.

With

   g++ coroutine-asan.cc -o coroutine-asan --std=c++20 -fsanitize=address -Og

I see

READ of size 8 at 0x60700020 thread T0
#0 0x4018e2 in test() (/home/avi/tests/coroutine-asan+0x4018e2)
#1 0x40192b in main (/home/avi/tests/coroutine-asan+0x40192b)
#2 0x7fb2e0a1d58f in __libc_start_call_main (/lib64/libc.so.6+0x2d58f)
#3 0x7fb2e0a1d648 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x2d648)
#4 0x401144 in _start (/home/avi/tests/coroutine-asan+0x401144)

0x60700020 is located 0 bytes inside of 80-byte region
[0x60700020,0x60700070)
freed by thread T0 here:
#0 0x7fb2e0fdebc8 in operator delete(void*) (/lib64/libasan.so.8+0xbbbc8)
#1 0x40164f in
test_coroutine(test_coroutine(std::__n4861::coroutine_handle&)::_Z14test_coroutineRNSt7__n486116coroutine_handleIvEE.Frame*)
[clone .actor] (/home/avi/tests/coroutine-asan+0x40164f)
#2 0x40200f  (/home/avi/tests/coroutine-asan+0x40200f)

previously allocated by thread T0 here:
#0 0x7fb2e0fde188 in operator new(unsigned long)
(/lib64/libasan.so.8+0xbb188)
#1 0x4016c0 in test_coroutine(std::__n4861::coroutine_handle&)
(/home/avi/tests/coroutine-asan+0x4016c0)


The stack traces are truncated, compared to

g++ coroutine-asan.cc -o coroutine-asan --std=c++20 -fsanitize=address

which yields

READ of size 8 at 0x60700020 thread T0
#0 0x401cef in std::__n4861::coroutine_handle::resume() const
(/home/avi/tests/coroutine-asan+0x401cef)
#1 0x401b0f in test() (/home/avi/tests/coroutine-asan+0x401b0f)
#2 0x401b85 in main (/home/avi/tests/coroutine-asan+0x401b85)
#3 0x7f79b8be958f in __libc_start_call_main (/lib64/libc.so.6+0x2d58f)
#4 0x7f79b8be9648 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x2d648)
#5 0x4011a4 in _start (/home/avi/tests/coroutine-asan+0x4011a4)

0x60700020 is located 0 bytes inside of 80-byte region
[0x60700020,0x60700070)
freed by thread T0 here:
#0 0x7f79b91aabc8 in operator delete(void*) (/lib64/libasan.so.8+0xbbbc8)
#1 0x4019a5 in
test_coroutine(test_coroutine(std::__n4861::coroutine_handle&)::_Z14test_coroutineRNSt7__n486116coroutine_handleIvEE.Frame*)
[clone .actor] (/home/avi/tests/coroutine-asan+0x4019a5)
#2 0x401cf7 in std::__n4861::coroutine_handle::resume() const
(/home/avi/tests/coroutine-asan+0x401cf7)
#3 0x401b0f in test() (/home/avi/tests/coroutine-asan+0x401b0f)
#4 0x401b85 in main (/home/avi/tests/coroutine-asan+0x401b85)
#5 0x7f79b8be958f in __libc_start_call_main (/lib64/libc.so.6+0x2d58f)

previously allocated by thread T0 here:
#0 0x7f79b91aa188 in operator new(unsigned long)
(/lib64/libasan.so.8+0xbb188)
#1 0x401293 in test_coroutine(std::__n4861::coroutine_handle&)
(/home/avi/tests/coroutine-asan+0x401293)
#2 0x401af9 in test() (/home/avi/tests/coroutine-asan+0x401af9)
#3 0x401b85 in main (/home/avi/tests/coroutine-asan+0x401b85)
#4 0x7f79b8be958f in __libc_start_call_main (/lib64/libc.so.6+0x2d58f)


The traces go all the away to main.

[Bug sanitizer/105336] truncated address sanitizer stack traces

[avi at scylladb dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336

--- Comment #4 from Avi Kivity  ---
Created attachment 52856
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52856=edit
intentionally buggy reproducer

[PATCH] libgo: Recognize off64_t / loff_t type definition of musl libc

[soeren--- via Gcc-patches]

From: Sören Tempel 

The libgo code assumes both off64_t and loff_t to be present. For
example, for the splice(2) function prototype. Similar to glibc,
musl libc supports these types but defines them as macros, not as
typedefs. Unfortunately, -fdump-go-spec only recognizes types defined
using typedef. To workaround that, this commit adds explicit typedefs
for these types if off64_t or loff_t are defined as macros.

Furthermore, loff_t is only defined on musl with -D_GNU_SOURCE and
requires an include of fcntl.h (this is in accordance with the splice(2)
man page). Therefore, the configure script has also been adjusted
accordingly.
---
 libgo/configure|  6 +-
 libgo/configure.ac |  6 +-
 libgo/sysinfo.c| 14 ++
 3 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/libgo/configure b/libgo/configure
index ffe17c9b..b83ddfb3 100755
--- a/libgo/configure
+++ b/libgo/configure
@@ -15546,7 +15546,10 @@ _ACEOF
 
 fi
 
-ac_fn_c_check_type "$LINENO" "loff_t" "ac_cv_type_loff_t" 
"$ac_includes_default"
+CFLAGS_hold=$CFLAGS
+CFLAGS="$CFLAGS -D_GNU_SOURCE"
+ac_fn_c_check_type "$LINENO" "loff_t" "ac_cv_type_loff_t" "#include 
+"
 if test "x$ac_cv_type_loff_t" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
@@ -15556,6 +15559,7 @@ _ACEOF
 
 fi
 
+CFLAGS=$CFLAGS_hold
 
 LIBS_hold="$LIBS"
 LIBS="$LIBS -lm"
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 7e2b98ba..b8f7d1a0 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -601,7 +601,11 @@ AC_STRUCT_DIRENT_D_TYPE
 
 AC_CHECK_FUNCS(accept4 dup3 epoll_create1 faccessat fallocate fchmodat 
fchownat futimesat getxattr inotify_add_watch inotify_init inotify_init1 
inotify_rm_watch listxattr mkdirat mknodat open64 openat pipe2 removexattr 
renameat setxattr sync_file_range splice syscall tee unlinkat unshare utimensat)
 AC_TYPE_OFF_T
-AC_CHECK_TYPES([loff_t])
+
+CFLAGS_hold=$CFLAGS
+CFLAGS="$CFLAGS -D_GNU_SOURCE"
+AC_CHECK_TYPES([loff_t], [], [], [[#include ]])
+CFLAGS=$CFLAGS_hold
 
 LIBS_hold="$LIBS"
 LIBS="$LIBS -lm"
diff --git a/libgo/sysinfo.c b/libgo/sysinfo.c
index 8ce061e2..22f52e5b 100644
--- a/libgo/sysinfo.c
+++ b/libgo/sysinfo.c
@@ -343,6 +343,20 @@ enum {
 #endif
 };
 
+// musl libc has both off64_t and loff_t. However, both of these types
+// are defined as CPP macros, not as C typedefs. Unfortunately, the GCC
+// option -fdump-go-spec only recognizes types defined using typedefs.
+#if defined(HAVE_OFF64_T) && defined(off64_t)
+typedef off64_t __musl_off64_t;
+#undef off64_t
+typedef __musl_off64_t off64_t;
+#endif
+#if defined(HAVE_LOFF_T) && defined(loff_t)
+typedef loff_t __musl_loff_t;
+#undef loff_t
+typedef __musl_loff_t loff_t;
+#endif
+
 // SIOCGIFMTU can't be added in the above enum as it might
 // be signed in some OSes.
 #ifdef SIOCGIFMTU

[PATCH] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS)

[Yang Yujie]

Hello,

This patch fixes libgccjit link failure on loongarch* targets,
and could probably be useful for future ports.

Currently libgccjit is linked with objects from $(EXTRA_GCC_OBJS) and
libbackend.a, which is in turn linked with $(EXTRA_OBJS) files.
Thus, common object files that's shared between those two $(EXTRA_*)
lists would cause the linker to abort for "redefined symbol"s.

For now, this patch doesn't affect any target other than LoongArch,
but might be useful for future ports that want to share more object
files between the compiler proper and the GCC driver than
${cpu_arch}-common.o.

Regression tested on loongarch64-linux-gnuf64 an x86_64-pc-linux-gnu.
Ok for trunk?

Yujie
>From 5d9121fa052c556fd854596af35da8e5649e8f08 Mon Sep 17 00:00:00 2001
From: Yang Yujie 
Date: Fri, 22 Apr 2022 14:36:37 +0800
Subject: [PATCH] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and
 $(EXTRA_OBJS)

The final link of libgccjit involves libbackend.a and
$(EXTRA_GCC_OBJS) as input, where libbackend.a contains object files
from the $(EXTRA_OBJS) list.

This assumes that no target-specific object file should be shared
between those two lists (or the linker would complain about redefined
symbols and abort).

With this patch, libgccjit can built properly for LoongArch
and other architectures that shares target-specific objects between
gcc and cc1 etc.

* gcc/jit/ChangeLog:

	* Make-lang.in: only link objects from $(EXTRA_GCC_OBJS)
	that's not in $(EXTRA_OBJS) into libgccjit.
---
 gcc/jit/Make-lang.in | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in
index 6e10abfd0ac..248ec45b729 100644
--- a/gcc/jit/Make-lang.in
+++ b/gcc/jit/Make-lang.in
@@ -157,18 +157,23 @@ LIBGCCJIT_EXTRA_OPTS = $(LIBGCCJIT_VERSION_SCRIPT_OPTION) \
 endif
 endif
 
+# Only link objects from $(EXTRA_GCC_OBJS) that's not already
+# included in libbackend.a ($(EXTRA_OBJS)).
+EXTRA_GCC_OBJS_EXCLUSIVE = $(foreach _obj1, $(EXTRA_GCC_OBJS), \
+	$(if $(filter $(_obj1), $(EXTRA_OBJS)),, $(_obj1)))
+
 # We avoid using $(BACKEND) from Makefile.in in order to avoid pulling
 # in main.o
 $(LIBGCCJIT_FILENAME): $(jit_OBJS) \
 	libbackend.a libcommon-target.a libcommon.a \
 	$(CPPLIB) $(LIBDECNUMBER) \
 	$(LIBDEPS) $(srcdir)/jit/libgccjit.map \
-	$(EXTRA_GCC_OBJS) $(jit.prev)
+	$(EXTRA_GCC_OBJS_EXCLUSIVE) $(jit.prev)
 	@$(call LINK_PROGRESS,$(INDEX.jit),start)
 	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ -shared \
 	 $(jit_OBJS) libbackend.a libcommon-target.a libcommon.a \
 	 $(CPPLIB) $(LIBDECNUMBER) $(EXTRA_GCC_LIBS) $(LIBS) $(BACKENDLIBS) \
-	 $(EXTRA_GCC_OBJS) \
+	 $(EXTRA_GCC_OBJS_EXCLUSIVE) \
 	 $(LIBGCCJIT_EXTRA_OPTS)
 	@$(call LINK_PROGRESS,$(INDEX.jit),end)
 
-- 
2.31.1

[Bug target/104723] [12 regression] Redundant usage of stack

[lili.cui at intel dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104723

--- Comment #11 from cuilili  ---
(In reply to Jakub Jelinek from comment #10)

> And for the backend, the question is how big the penalty for the overlapping
> store is compared to doing multiple non-overlapping stores.  Say for those
> 49 bytes one could do one OI, one TI/V1TI and one QI load/store as opposed to
> one aligned and one misaligned OI load/store.
> 
> For say:
> void
> foo (void *p, void *q)
> {
>   __builtin_memcpy (p, q, 49);
> }
> we emit the 2 overlapping loads/stores for -mavx512f and 4 non-overlapping
> loads/stores with say -mavx2.

I execute both code sequence 10 times on ICX and znver3 machines.

For ICX: 2 overlapping loads/stores are 3.5x faster than 4 non-overlapping
loads/stores.
For Znver3: 2 overlapping loads/stores are 1.39x faster than 4 non-overlapping
loads/stores.


vmovdqu ymm0, YMMWORD PTR [rsi]
vmovdqu YMMWORD PTR [rdi], ymm0
vmovdqu ymm1, YMMWORD PTR [rsi+17]
vmovdqu YMMWORD PTR [rdi+17], ymm1


vmovdqu xmm0, XMMWORD PTR [rsi]
vmovdqu XMMWORD PTR [rdi], xmm0
vmovdqu xmm1, XMMWORD PTR [rsi+16]
vmovdqu XMMWORD PTR [rdi+16], xmm1
vmovdqu xmm2, XMMWORD PTR [rsi+32]
vmovdqu XMMWORD PTR [rdi+32], xmm2
movzx   eax, BYTE PTR [rsi+48]
mov BYTE PTR [rdi+48], al
---

Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

[Tsukasa OI via Gcc-patches]

Hello,

> Neither K nor J is an extension that exists,

That is correct.

> and so it doesn't make
> sense to mandate any particular ordering.

No. It affects Z* extension ordering...


On 2022/04/24 14:36, Andrew Waterman wrote:
> Neither K nor J is an extension that exists, and so it doesn't make
> sense to mandate any particular ordering.  The better change would be
> to delete the letters `k' and `j' from that string, so that we aren't
> enforcing constraints that don't serve a useful purpose.
> 
> cf. 
> https://github.com/riscv/riscv-isa-manual/commit/f5f9c27010b69a015958ffebe1ac5a34f8776dff

Wait... so, you make constraints for existing single-letters (Zi -> Zv)
but not for non-existing single-letters? (Zk -> Zj, Zj -> Zk) anymore?

That's completely unexpected move but also makes sense.

Let me check your intentions and details: do we need to place Z[CH]*
extensions without single-letter extension [CH] after all existing ones
(like Zv*)? Or, Z[CH]* extensions without single-letter extension [CH]
have no constraints as long as all Z* extensions are grouped together?

> 
> On Sat, Apr 23, 2022 at 10:26 PM Tsukasa OI via Gcc-patches
>  wrote:
>>
>> This commit fixes canonical extension order to follow the RISC-V ISA
>> Manual draft-20210402-1271737 or later.
>>
>> gcc/ChangeLog:
>>
>> * common/config/riscv/riscv-common.cc (riscv_supported_std_ext):
>> Fix "K" extension prefix to be placed before "J".
>> ---
>>  gcc/common/config/riscv/riscv-common.cc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/common/config/riscv/riscv-common.cc 
>> b/gcc/common/config/riscv/riscv-common.cc
>> index 1501242e296..0b0ec2c4ec5 100644
>> --- a/gcc/common/config/riscv/riscv-common.cc
>> +++ b/gcc/common/config/riscv/riscv-common.cc
>> @@ -594,7 +594,7 @@ riscv_subset_list::lookup (const char *subset, int 
>> major_version,
>>  static const char *
>>  riscv_supported_std_ext (void)
>>  {
>> -  return "mafdqlcbjktpvn";
>> +  return "mafdqlcbkjtpvn";
>>  }
>>
>>  /* Parsing subset version.
>> --
>> 2.32.0
>>
>