[Bug c/105134] tree-vectorize produces error code

[piliu at redhat dot com via Gcc-bugs]

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

--- Comment #2 from piliu at redhat dot com ---
More specific, the following directive beats out the bug.

diff --git a/util_lib/sha256.c b/util_lib/sha256.c
index 2e61a31..3b3e533 100644
--- a/util_lib/sha256.c
+++ b/util_lib/sha256.c
@@ -38,6 +38,7 @@
(b)[(i) + 3] = (uint8_t) ( (n)   ); \
 }

+ __attribute__((optimize("no-tree-vectorize")))
 void sha256_starts( sha256_context *ctx )

[Bug c/105134] tree-vectorize produces error code

[piliu at redhat dot com via Gcc-bugs]

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

--- Comment #1 from piliu at redhat dot com ---
More description about the background.

There is a built file kexec-tools/purgatory/purgatory.ro, which is a tiny
bootload, compare and verify the sha256, if ok, then jump to the 2nd kernel.

The original sha256 value comes from
update_purgatory()
{
..
elf_rel_set_symbol(>rhdr, "sha256_regions", ,
   sizeof(region));
elf_rel_set_symbol(>rhdr, "sha256_digest", ,
   sizeof(digest));

}

They are based on the loaded linux kernel image.

Now, "kexec -e" and purgatory.ro runs, and in
void purgatory(void)
{
printf("I'm in purgatory\n");
setup_arch();
if (!skip_checks && verify_sha256_digest()) {
for(;;) {
/* loop forever */   --> stuck here
}
}
post_verification_setup_arch();
}

[Bug c/105134] New: tree-vectorize produces error code

[piliu at redhat dot com via Gcc-bugs]

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

Bug ID: 105134
   Summary: tree-vectorize produces error code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piliu at redhat dot com
  Target Milestone: ---

On x86_64, kexec-tools built with gcc-12 can not boot the 2nd kernel
successfully.

After debugging, it turns out to be related with "tree-vectorize" option.
As kexec-tools commit 1b03cf7 purgatory: do not enable vectorization
automatically for purgatory compiling.

I have no idea about what happens, but it seems to be related with the
generation of the code piece

void sha256_starts( sha256_context *ctx )
{
ctx->total[0] = 0;
ctx->total[1] = 0;

ctx->state[0] = 0x6A09E667;
ctx->state[1] = 0xBB67AE85;
ctx->state[2] = 0x3C6EF372;
ctx->state[3] = 0xA54FF53A;
ctx->state[4] = 0x510E527F;
ctx->state[5] = 0x9B05688C;
ctx->state[6] = 0x1F83D9AB;
ctx->state[7] = 0x5BE0CD19;
}

[Bug lto/105133] New: lto/gold: lto failed to link --start-lib/--end-lib in gold

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

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

Bug ID: 105133
   Summary: lto/gold: lto failed to link --start-lib/--end-lib in
gold
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luoxhu at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi, linker gold supports --start-lib and --end-lib to "mimics the
semantics of static libraries, but without needing to actually create
the archive file."(https://reviews.llvm.org/D66848).  Sometimes large
application may introduce multiple libraries from different repositories with
same source code, they would be linked into one binary finally, recently I
suffered from a link error with gold as linker and reduced an example as below:

cat hello.c
extern int hello(int a);
int main(void)
{
  return 0; /* hello(10); */
}

cat ./B/libhello.c
#include 
int hello(int a)
{
   puts("Hello");
   return 0;
}

cat ./C/libhello.c
#include 
int hello(int a)
{
   puts("Hello");
   return 0;
}


(1) NON lto link with gold is OK:

gcc -O2 -o ./B/libhello.c.o   -c ./B/libhello.c
gcc-ar qc ./B/libhello.a  ./B/libhello.c.o
gcc-ranlib ./B/libhello.a
gcc -O2 -o ./C/libhello.c.o   -c ./C/libhello.c
gcc-ar qc ./C/libhello.a  ./C/libhello.c.o
gcc-ranlib ./C/libhello.a
gcc hello.c -o hello.o -c -O2
gcc -o hellow hello.o -Wl,--start-lib ./B/libhello.c.o  -Wl,--end-lib
-Wl,--start-lib ./C/libhello.c.o -Wl,--end-lib -O2 -fuse-ld=gold


(2) lto link with gold fails with redefinition:
gcc -O2 -flto  -o ./B/libhello.c.o   -c ./B/libhello.c
gcc-ar qc ./B/libhello.a  ./B/libhello.c.o
gcc-ranlib ./B/libhello.a
gcc -O2 -flto  -o ./C/libhello.c.o   -c ./C/libhello.c
gcc-ar qc ./C/libhello.a  ./C/libhello.c.o
gcc-ranlib ./C/libhello.a
gcc hello.c -o hello.o -c -O2 -flto
gcc -o hellow hello.o -Wl,--start-lib ./B/libhello.c.o  -Wl,--end-lib
-Wl,--start-lib ./C/libhello.c.o -Wl,--end-lib -O2 -flto -fuse-ld=gold


./B/libhello.c:5:5: error: 'hello' has already been defined
5 | int hello(int a)
  | ^
./B/libhello.c:5:5: note: previously defined here
lto1: fatal error: errors during merging of translation units
compilation terminated.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld.gold: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

This error happens at function gcc/lto/lto-symtab.c:lto_symtab_resolve_symbols,
simply remove the error_at line could work, but this may be not a reasonable
fix.  

  /* Find the single non-replaceable prevailing symbol and
 diagnose ODR violations.  */
  for (e = first; e; e = e->next_sharing_asm_name)
{
  if (!lto_symtab_resolve_can_prevail_p (e))
continue;

  /* If we have a non-replaceable definition it prevails.  */
  if (!lto_symtab_resolve_replaceable_p (e))
{
  if (prevailing)
{
  error_at (DECL_SOURCE_LOCATION (e->decl),
"%qD has already been defined", e->decl);
  inform (DECL_SOURCE_LOCATION (prevailing->decl),
  "previously defined here");
}
  prevailing = e;
}
}


cat hellow.res
3
hello.o 2
192 ccb9165e03755470 PREVAILING_DEF main
197 ccb9165e03755470 PREVAILING_DEF_IRONLY s
./B/libhello.c.o 1
205 68e0b97e93a52d7a PREEMPTED_REG hello
./C/libhello.c.o 1
205 18fe2d3482bfb511 PREEMPTED_REG hello


Secondly, If call hello(10) in hello.c , there will be NO error reported out.
The difference is the resolution type is changed from PREEMPTED_REG to
RESOLVED_IR/PREVAILING_DEF_IRONLY.  

3
hello.o 3
192 19ef867d12f62129 PREVAILING_DEF main
197 19ef867d12f62129 PREVAILING_DEF_IRONLY s
201 19ef867d12f62129 RESOLVED_IR hello
./B/libhello.c.o 1
205 23c5c855935478ce PREVAILING_DEF_IRONLY hello
./C/libhello.c.o 1
205 abbf050f5c23b448 PREEMPTED_REG hello


Is this a valid bug? Thanks.

[Bug fortran/65347] [F03] Final subroutine not called for function result

[damian at archaeologic dot codes via Gcc-bugs]

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

Damian Rouson  changed:

   What|Removed |Added

 CC||damian at archaeologic dot 
codes

--- Comment #3 from Damian Rouson  ---
I suspect the code below is a simpler reproducer (25 lines) of this bug

% cat missing-finalization.f90 
module object_m
  implicit none

  type object_t
  contains
final :: count_finalizations
  end type

contains
  subroutine count_finalizations(self)
type(object_t) self
print *,"finalization"
  end subroutine

  function new_object() 
type(object_t) new_object
  end function
end module

  use object_m
  implicit none
  type(object_t) object

 object = new_object()
end

% gfortran missing-finalization.f90 

% ./a.out

% gfortran --version
GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0

[Bug target/102024] [12 Regression] zero width bitfields and ABIs

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

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

--- Comment #38 from Segher Boessenkool  ---
+ cat test.c

struct foo
{
  int : 0;
  double a;
  int : 0;
  double b;
  int : 0;
};

extern void func(struct foo);

void
pass_foo(void)
{
  struct foo test;
  test.a = 114;
  test.b = 514;
  func(test);
}
+ cc -version
MIPSpro Compilers: Version 7.30
+ cc -64 -ansi -c test.c -o test.o
Cannot find license file (-1,73:2) No such file or directory

 This product (cc) requires a license password. 
 For license installation and trouble shooting 
 information visit the web page: 

 http://www.sgi.com/Support/Licensing/install_docs.html 

 To obtain a Permanent license (proof of purchase
 required) or an Evaluation license please
 visit our license request web page: 

 http://www.sgi.com/Products/license.html 

 or send a blank email message to: 

 lice...@sgi.com 

 In North America, Silicon Graphics' customers may request 
 Permanent licenses by sending a facsimile to: 

 (650) 390-0537 

 or by calling our technical support hotline 

 1-800-800-4SGI 

 If you are Outside of North America or you are not a Silicon 
 Graphics support customer then contact your local support provider. 

qemu: Unsupported syscall: sgisys(107)
qemu: Unsupported syscall: sgisys(111)
qemu: Unsupported syscall: sgisys(107)
qemu: Unsupported syscall: sgisys(111)

### Assertion failure at line 137 of ../../be/cg/MIPS/exp_loadstore.cxx:
### Compiler Error in file test.c during Code_Expansion phase:
### unexpected mtypes in Pick_Load_Instruction
cc INTERNAL ERROR:  /usr/lib32/cmplrs/be returned non-zero status 1

Re: [committed] jit: further doc fixes

[David Malcolm via Gcc-patches]

On Fri, 2022-04-01 at 12:26 -0400, Eric Gallager wrote:
> On Fri, Apr 1, 2022 at 9:28 AM David Malcolm via Gcc-patches
>  wrote:
> > 
> > Further jit doc fixes, which fix links to
> > gcc_jit_function_type_get_param_type and gcc_jit_struct_get_field.
> > 
> > I also regenerated libgccjit.texi (not included in the diff below).
> > 
> > Tested with "make html" and with a bootstrap.
> 
>  Could you test with `make pdf` and `make dvi` too, to see if this
> fixes 102824?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824

FWIW it doesn't fix that, but I've added some notes to that bug with a
possible fix.

Dave

[Bug jit/102824] building pdf/dvi documentation for libgccjit fails

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

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

--- Comment #2 from David Malcolm  ---
make pdf is looking for the images in:
  gcc/jit/docs/_build/texinfo/libgccjit-figures
but they're in the source tree in:
  gcc/jit/docs/_build/texinfo

I just tried:
  git mv gcc/jit/docs/_build/texinfo/*.png
gcc/jit/docs/_build/texinfo/libgccjit-figures

and it seems to fix the "make pdf" for me.

Will test a bit more.

gcc-10-20220401 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-10-20220401.tar.xz   Complete GCC

  SHA256=6b8992577a8e2aa05551000b78aebff77a308580b7295649028de1f4e6a50b0c
  SHA1=01456f8be7be4ebf5a2f491a7420376ebf59bb84

Diffs from 10-20220325 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [PATCH] rs6000: Adjust mov optabs for opaque modes [PR103353]

[Peter Bergner via Gcc-patches]

On 4/1/22 3:50 PM, will schmidt wrote:
> Is there a testcase, new or existing, that illustrates this error path?

Well, the already existsing test case pr101849.c is where the issue was seen,
but only when compiled by hand outside of the test harness and using only the
-maltivec option and not the -mcpu=power10 that the test case uses.

That said, I agree, pr101849.c should probably be copied into another test case
file (pr103353.c) that uses options that trigger the issue so we can be sure the
fix won't regress.

Peter

[Bug c++/101894] [11/12 Regression] ICE with multiple friend declarations

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

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 CC||jason at gcc dot gnu.org
 Status|NEW |ASSIGNED

Various errors encountered while compiling gcj.

[Zopolis0 via Gcc]

While attempting to compile gcc with gcj re-added, the compilation fails on
a varying number of errors. I have solved most of the errors, but these are
the remaining ones I am stuck on. The code I am building from is available
here: https://github.com/Zopolis4/gcj/tree/gcjmainbuild . My apologies for
log dumping.

../.././gcc/java/jcf-depend.cc: In function ‘void jcf_dependency_reset()’:
../.././gcc/java/jcf-depend.cc:66:18: error: cannot convert ‘deps*’ to
‘mkdeps*’
   66 |   deps_free (dependencies);
  |  ^~~~
  |  |
  |  deps*
In file included from ../.././gcc/java/jcf-depend.cc:30:
../.././gcc/../libcpp/include/mkdeps.h:37:24: note:   initializing argument
1 of ‘void deps_free(mkdeps*)’
   37 | extern void deps_free (class mkdeps *);
  |^~
../.././gcc/java/jcf-depend.cc:37:7: note: class type ‘deps’ is incomplete
   37 | class deps *dependencies;
  |   ^~~~
../.././gcc/java/jcf-depend.cc: In function ‘void
jcf_dependency_set_target(const char*)’:
../.././gcc/java/jcf-depend.cc:76:22: error: cannot convert ‘deps*’ to
‘mkdeps*’
   76 | deps_add_target (dependencies, name, 1);
  |  ^~~~
  |  |
  |  deps*
../.././gcc/../libcpp/include/mkdeps.h:48:30: note:   initializing argument
1 of ‘void deps_add_target(mkdeps*, const char*, int)’
   48 | extern void deps_add_target (class mkdeps *, const char *, int);
  |  ^~
../.././gcc/java/jcf-depend.cc:37:7: note: class type ‘deps’ is incomplete
   37 | class deps *dependencies;
  |   ^~~~
../.././gcc/java/jcf-depend.cc: In function ‘void
jcf_dependency_add_target(const char*)’:
../.././gcc/java/jcf-depend.cc:83:22: error: cannot convert ‘deps*’ to
‘mkdeps*’
   83 | deps_add_target (dependencies, name, 1);
  |  ^~~~
  |  |
  |  deps*
../.././gcc/../libcpp/include/mkdeps.h:48:30: note:   initializing argument
1 of ‘void deps_add_target(mkdeps*, const char*, int)’
   48 | extern void deps_add_target (class mkdeps *, const char *, int);
  |  ^~
../.././gcc/java/jcf-depend.cc:37:7: note: class type ‘deps’ is incomplete
   37 | class deps *dependencies;
  |   ^~~~
../.././gcc/java/jcf-depend.cc: In function ‘void jcf_dependency_init(int)’:
../.././gcc/java/jcf-depend.cc:119:28: error: cannot convert ‘mkdeps*’ to
‘deps*’ in assignment
  119 |   dependencies = deps_init ();
  |  ~~^~
  ||
  |mkdeps*
In file included from ../.././gcc/../libcpp/include/mkdeps.h:26:
../.././gcc/../libcpp/include/cpplib.h:1043:14: note: class type ‘mkdeps’
is incomplete
 1043 | extern class mkdeps *cpp_get_deps (cpp_reader *) ATTRIBUTE_PURE;
  |  ^~
../.././gcc/java/jcf-depend.cc: In function ‘void jcf_dependency_write()’:
../.././gcc/java/jcf-depend.cc:138:47: error: expected primary-expression
before ‘.’ token
  138 | CPP_OPTION (dependencies, deps.phony_targets) 72);
  |   ^
../.././gcc/java/jcf-depend.cc:138:17: error: ‘CPP_OPTION’ was not declared
in this scope
  138 | CPP_OPTION (dependencies, deps.phony_targets) 72);
  | ^~
../.././gcc/java/jcf-depend.cc:140:17: error: cannot convert ‘deps*’ to
‘const cpp_reader*’
  140 | deps_write (dependencies, dep_out, 72);
  | ^~~~
  | |
  | deps*
../.././gcc/../libcpp/include/mkdeps.h:69:25: note:   initializing argument
1 of ‘void deps_write(const cpp_reader*, FILE*, unsigned int)’
   69 | extern void deps_write (const cpp_reader *, FILE *, unsigned int);
  | ^~
../.././gcc/java/jcf-depend.cc:37:7: note: class type ‘deps’ is incomplete
   37 | class deps *dependencies;
  |   ^~~~
make[3]: *** [Makefile:1143: java/jcf-depend.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from ../.././gcc/java/jvspec.cc:29:
../.././gcc/gcc.h:61:3: error: ‘option_proposer’ does not name a type
   61 |   option_proposer m_option_proposer;
  |   ^~~
make[3]: *** [Makefile:1143: java/jvspec.o] Error 1
../.././gcc/java/expr.cc: In function ‘void expand_java_return(tree)’:
../.././gcc/java/expr.cc:1303:15: error: no match for ‘operator<’ (operand
types are ‘poly_uint16’ {aka ‘poly_int<1, short unsigned int>’} and
‘poly_uint16’ {aka ‘poly_int<1, short unsigned int>’})
 1302 |   && (GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (res)))
  |   ~~~
  | |
  | poly_int<[...],[...]>
 1303 | 

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

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

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

--- Comment #39 from Eric Botcazou  ---
> If SEH is the problem, can alignment be accounted for in cases where SEH is
> not in use (if there are any such cases)? I'm thinking of -fno-exceptions,
> and dwarf (on x86) or setjump/longjump exceptions.

The hitch is that Setjmp/Longjmp is implemented on top of SEH on 64-bit
Windows, which means that SEH information must always be generated, even in
plain C.

[Bug c/105131] Warning for mismatched declaration/definition with enum

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

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

--- Comment #2 from Marek Polacek  ---
Maybe something like the attached patch would work (but needs a new option,
maybe -Wenum-int-mismatch, possibly enabled by -Wall?).  With it, the following
test

enum E { l = -1, z = 0, g = 1 };
int foo(void);
enum E foo(void) { return z; }

void bar(int);
void bar(enum E);

extern enum E arr[10];
extern int arr[10];

is diagnosed like this:

105131.c:3:8: warning: conflicting types for ‘foo’ due to enum/integer
mismatch; have ‘enum E(void)’
3 | enum E foo(void) { return z; }
  |^~~
105131.c:2:5: note: previous declaration of ‘foo’ with type ‘int(void)’
2 | int foo(void);
  | ^~~
105131.c:6:6: warning: conflicting types for ‘bar’ due to enum/integer
mismatch; have ‘void(enum E)’
6 | void bar(enum E);
  |  ^~~
105131.c:5:6: note: previous declaration of ‘bar’ with type ‘void(int)’
5 | void bar(int);
  |  ^~~
105131.c:9:12: warning: conflicting types for ‘arr’ due to enum/integer
mismatch; have ‘int[10]’
9 | extern int arr[10];
  |^~~
105131.c:8:15: note: previous declaration of ‘arr’ with type ‘enum E[10]’
8 | extern enum E arr[10];
  |   ^~~



diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index c701f07befe..60a0bb3ea36 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -1995,9 +1995,12 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,

   bool pedwarned = false;
   bool warned = false;
+  bool enum_and_int_p = false;
   auto_diagnostic_group d;

-  if (!comptypes (oldtype, newtype))
+  int comptypes_result = comptypes_check_enum_int (oldtype, newtype,
+  _and_int_p);
+  if (!comptypes_result)
 {
   if (TREE_CODE (olddecl) == FUNCTION_DECL
  && fndecl_built_in_p (olddecl, BUILT_IN_NORMAL)
@@ -2139,6 +2142,14 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
  return false;
}
 }
+  else if (enum_and_int_p && TREE_CODE (newdecl) != TYPE_DECL)
+{
+  location_t newloc = DECL_SOURCE_LOCATION (newdecl);
+  auto_diagnostic_group d;
+  warned = warning_at (newloc, 0, "conflicting types for %q+D due to "
+  "enum/integer mismatch; have %qT", newdecl,
+  newtype);
+}

   /* Redeclaration of a type is a constraint violation (6.7.2.3p1),
  but silently ignore the redeclaration if either is in a system
@@ -2148,7 +2159,6 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
   if (TREE_CODE (newdecl) == TYPE_DECL)
 {
   bool types_different = false;
-  int comptypes_result;

   comptypes_result
= comptypes_check_different_types (oldtype, newtype, _different);
diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h
index c70f0ba5ab6..2bcb9662620 100644
--- a/gcc/c/c-tree.h
+++ b/gcc/c/c-tree.h
@@ -685,6 +685,7 @@ extern tree require_complete_type (location_t, tree);
 extern bool same_translation_unit_p (const_tree, const_tree);
 extern int comptypes (tree, tree);
 extern int comptypes_check_different_types (tree, tree, bool *);
+extern int comptypes_check_enum_int (tree, tree, bool *);
 extern bool c_vla_type_p (const_tree);
 extern bool c_mark_addressable (tree, bool = false);
 extern void c_incomplete_type_error (location_t, const_tree, const_tree);
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 6c4af5e4cde..b6a45fd9836 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -1055,7 +1055,7 @@ comptypes (tree type1, tree type2)
 /* Like comptypes, but if it returns non-zero because enum and int are
compatible, it sets *ENUM_AND_INT_P to true.  */

-static int
+int
 comptypes_check_enum_int (tree type1, tree type2, bool *enum_and_int_p)
 {
   const struct tagged_tu_seen_cache * tagged_tu_seen_base1 =
tagged_tu_seen_base;

[Bug tree-optimization/105132] New: ICE in in operator[], at vec.h:889 with -march=skylake-avx512 -O3

[vsevolod.livinskiy at gmail dot com via Gcc-bugs]

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

Bug ID: 105132
   Summary: ICE in in operator[], at vec.h:889 with
-march=skylake-avx512 -O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskiy at gmail dot com
  Target Milestone: ---

Link to the Compiler Explorer: https://godbolt.org/z/xedcfP338

Reproducer:
short a;
extern int b[];
int c;
void d(long f[][5][5][17], int g[][5][5][17]) {
  for (short e = 0; e < 17; e++) {
a = g[19][2][3][e];
b[e] = c & (f[3][2][3][e] && g[19][2][3][e]);
  }
}

Error:
>$ g++ -march=skylake-avx512 -c -O3 func.cpp
during GIMPLE pass: slp
func.cpp: In function 'void d(long int (*)[5][5][17], int (*)[5][5][17])':
func.cpp:4:6: internal compiler error: in operator[], at vec.h:889
4 | void d(long f[][5][5][17], int g[][5][5][17]) {
  |  ^
0x99508e vec::operator[](unsigned int)
/testing/gcc/gcc_src_master/gcc/vec.h:889
0x996d5b vec::operator[](unsigned int)
/testing/gcc/gcc_src_master/gcc/tree-vect-stmts.cc:6108
0x996d5b vec::operator[](unsigned int)
/testing/gcc/gcc_src_master/gcc/vec.h:1495
0x996d5b vectorizable_operation
/testing/gcc/gcc_src_master/gcc/tree-vect-stmts.cc:6375
0x2123ab8 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/testing/gcc/gcc_src_master/gcc/tree-vect-stmts.cc:11245
0x14c4fc7 vect_schedule_slp_node
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7320
0x14d6346 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7515
0x14d60d9 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7496
0x14d60d9 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7496
0x14d60d9 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7496
0x14d699f vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7632
0x14d8163 vect_slp_region
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:5994
0x14d9113 vect_slp_bbs
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:6106
0x14d950c vect_slp_function(function*)
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:6194
0x14e13e2 execute
/testing/gcc/gcc_src_master/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.

GCC version:
gcc version 12.0.1 20220401 (git://gcc.gnu.org/git/gcc.git:master
15d683d4f0b390b27c54a7c92c6e4f33195bdc93) (GCC)

Re: [PATCH] rs6000: Adjust mov optabs for opaque modes [PR103353]

[will schmidt via Gcc-patches]

On Thu, 2022-03-03 at 16:38 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
> 

Hi

> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions.  As shown in
> that PR, without one explicit mov optab on OOmode provided, it would
> call emit_move_insn recursively.
> 
> So this patch is to allow the mov pattern to be generated when we are
> expanding to RTL and have seen errors even without MMA supported, it's
> expected that the generated pattern would not cause further ICEs as the
> compilation would stop soon after expanding.

Is there a testcase, new or existing, that illustrates this error path?

> 
> Bootstrapped and regtested on powerpc64-linux-gnu P8 and
> powerpc64le-linux-gnu P9 and P10.
> 
> Is it ok for trunk?
> 
> BR,
> Kewen
> --
> 
>   PR target/103353
> 
> gcc/ChangeLog:
> 
>   * config/rs6000/mma.md (define_expand movoo): Move TARGET_MMA condition
>   check to preparation statements and add handlings for !TARGET_MMA.
>   (define_expand movxo): Likewise.

> > ---
> >  gcc/config/rs6000/mma.md | 42 ++--
> >  1 file changed, 36 insertions(+), 6 deletions(-)
> > 
> > diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md
> > index 907c9d6d516..f76a87b4a21 100644
> > --- a/gcc/config/rs6000/mma.md
> > +++ b/gcc/config/rs6000/mma.md
> > @@ -268,10 +268,25 @@ (define_int_attr avvi4i4i4
> > [(UNSPEC_MMA_PMXVI8GER4PP   "pmxvi8ger4pp")
> >  (define_expand "movoo"
> >[(set (match_operand:OO 0 "nonimmediate_operand")
> > (match_operand:OO 1 "input_operand"))]
> > -  "TARGET_MMA"
> > +  ""
> >  {
> > -  rs6000_emit_move (operands[0], operands[1], OOmode);
> > -  DONE;
> > +  if (TARGET_MMA) {
> > +rs6000_emit_move (operands[0], operands[1], OOmode);
> > +DONE;
> > +  }
> > +  /* Opaque modes are only expected to be available when MMA is supported,
> > + but PR103353 shows we may want to continue to expand a MMA built-in
> > + function like a normal function, even if we have already emitted
> > + error messages about some missing required conditions.

perhaps drop "like a normal function".  


> > + As shown in that PR, without one explicit mov optab on OOmode 
> > provided,
> > + it would call emit_move_insn recursively.  So we allow this pattern to
> > + be generated when we are expanding to RTL and have seen errors, even
> > + though there is no MMA support.  It would not cause further ICEs as
> > + the compilation would stop soon after expanding.  */

Testcase would be particularly helpful to illustrate this, i think.  

TH
anks,
-Will

> > +  else if (currently_expanding_to_rtl && seen_error ())
> > +;
> > +  else
> > +gcc_unreachable ();
> >  })
> >  
> >  (define_insn_and_split "*movoo"
> > @@ -300,10 +315,25 @@ (define_insn_and_split "*movoo"
> >  (define_expand "movxo"
> >[(set (match_operand:XO 0 "nonimmediate_operand")
> > (match_operand:XO 1 "input_operand"))]
> > -  "TARGET_MMA"
> > +  ""
> >  {
> > -  rs6000_emit_move (operands[0], operands[1], XOmode);
> > -  DONE;
> > +  if (TARGET_MMA) {
> > +rs6000_emit_move (operands[0], operands[1], XOmode);
> > +DONE;
> > +  }
> > +  /* Opaque modes are only expected to be available when MMA is supported,
> > + but PR103353 shows we may want to continue to expand a MMA built-in
> > + function like a normal function, even if we have already emitted
> > + error messages about some missing required conditions.
> > + As shown in that PR, without one explicit mov optab on OOmode 
> > provided,
> > + it would call emit_move_insn recursively.  So we allow this pattern to
> > + be generated when we are expanding to RTL and have seen errors, even
> > + though there is no MMA support.  It would not cause further ICEs as
> > + the compilation would stop soon after expanding.  */
> > +  else if (currently_expanding_to_rtl && seen_error ())
> > +;
> > +  else
> > +gcc_unreachable ();
> >  })
> >  
> >  (define_insn_and_split "*movxo"
> > -- 
> > 2.25.1
> > 

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[rcopley at gmail dot com via Gcc-bugs]

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

--- Comment #38 from R Copley  ---
(A patch to emit unaligned instructions should probably resolve bug 49001
instead of this one, 54412.)

Could dynamic alignment be achieved, not for automatic variables and function
parameters, but for registers spilled to the stack (due to register exhaustion,
or because they may be clobbered)? So that users can write code that stores
over-aligned objects on the heap only.

If SEH is the problem, can alignment be accounted for in cases where SEH is not
in use (if there are any such cases)? I'm thinking of -fno-exceptions, and
dwarf (on x86) or setjump/longjump exceptions.

Sorry if those are stupid questions.

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

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

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

--- Comment #37 from Eric Botcazou  ---
> If the Windows ABI doesn't align stack or not as much as gcc assumes, then a
> fix would ensure only automatic vars on Windows are accessed always using
> unaligned vector instructions provided dynamic stack realignment is not an
> option.

It's classical double-word alignment, i.e. 16 bytes, and AVX requires 32 bytes.
The implementation of dynamic stack realignment is too much of a kludge to be
safely used on Windows IMO so, yes, the way out is probably unaligned vector
instructions.

[Bug c/105131] Warning for mismatched declaration/definition with enum

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-04-01
 Ever confirmed|0   |1
   Keywords||diagnostic
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed.

Re: -Wformat-overflow handling for %b and %B directives in C2X standard

[Marek Polacek via Gcc-patches]

On Sat, Apr 02, 2022 at 12:19:47AM +0500, Frolov Daniil via Gcc-patches wrote:
> Hello, I've noticed that -Wformat-overflow doesn't handle %b and %B
> directives in the sprintf function. I've added a relevant issue in bugzilla
> (bug #105129).
> I attach a patch with a possible solution to the letter.

Thanks for the patch.  Support for C2X %b, %B formats is relatively new
(Oct 2021) so it looks like gimple-ssa-sprintf.cc hasn't caught up.

This is not a regression, so should probably wait till GCC 13.  Anyway...

> From 2051344e9500651f6e94c44cbc7820715382b957 Mon Sep 17 00:00:00 2001
> From: Frolov Daniil 
> Date: Fri, 1 Apr 2022 00:47:03 +0500
> Subject: [PATCH] Support %b, %B for -Wformat-overflow (sprintf, snprintf)
> 
> testsuite: add tests to check -Wformat-overflow on %b.
> Wformat-overflow1.c is compiled using -std=c2x so warning has to
> be throwed
> 
> Wformat-overflow2.c doesn't throw warnings cause c2x std isn't
> used
> 
> gcc/ChangeLog:
> 
>   * gimple-ssa-sprintf.cc
> (check_std_c2x): New function
>   (fmtresult::type_max_digits): add base == 2 handling
>   (tree_digits): add handle for base == 2
>   (format_integer): now handle %b and %B using base = 2
>   (parse_directive): add cases to handle %b and %B directives
>   (compute_format_length): add handling for base = 2

The descriptions should start with a capital letter and end with a period,
like "Handle base == 2."
 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/Wformat-overflow1.c: New test. (using -std=c2x)
>   * gcc.dg/Wformat-overflow2.c: New test. (-std=c11 no warning)

You can just say "New test."

> ---
>  gcc/gimple-ssa-sprintf.cc| 42 
>  gcc/testsuite/gcc.dg/Wformat-overflow1.c | 28 
>  gcc/testsuite/gcc.dg/Wformat-overflow2.c | 16 +
>  3 files changed, 79 insertions(+), 7 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/Wformat-overflow1.c
>  create mode 100644 gcc/testsuite/gcc.dg/Wformat-overflow2.c
> 
> diff --git a/gcc/gimple-ssa-sprintf.cc b/gcc/gimple-ssa-sprintf.cc
> index c93f12f90b5..7f68c2b6e51 100644
> --- a/gcc/gimple-ssa-sprintf.cc
> +++ b/gcc/gimple-ssa-sprintf.cc
> @@ -107,6 +107,15 @@ namespace {
>  
>  static int warn_level;
>  
> +/* b_overflow_flag depends on the current standart when using gcc */

"standard"

/* Comments should be formatted like this.  */

> +static bool b_overflow_flag;
> +
> +/* check is current standart version equals C2X*/
> +static bool check_std_c2x () 
> +{
> +  return !strcmp (lang_hooks.name, "GNU C2X");
> +}

Is this really needed?  ISTM that this new checking shouldn't depend on
-std=c2x.  If not using C2X, you only get a warning if -Wpedantic.  So
I think you should remove b_overflow_flag.

>  /* The minimum, maximum, likely, and unlikely maximum number of bytes
> of output either a formatting function or an individual directive
> can result in.  */
> @@ -535,6 +544,8 @@ fmtresult::type_max_digits (tree type, int base)
>unsigned prec = TYPE_PRECISION (type);
>switch (base)
>  {
> +case 2:
> +  return prec;
>  case 8:
>return (prec + 2) / 3;
>  case 10:
> @@ -857,11 +868,11 @@ tree_digits (tree x, int base, HOST_WIDE_INT prec, bool 
> plus, bool prefix)
>  
>/* Adjust a non-zero value for the base prefix, either hexadecimal,
>   or, unless precision has resulted in a leading zero, also octal.  */
> -  if (prefix && absval && (base == 16 || prec <= ndigs))
> +  if (prefix && absval && (base == 2 || base == 16 || prec <= ndigs))
>  {
>if (base == 8)
>   res += 1;
> -  else if (base == 16)
> +  else if (base == 16 || base == 2) /*0x...(0X...) and 0b...(0B...)*/
>   res += 2;
>  }
>  
> @@ -1229,6 +1240,10 @@ format_integer (const directive , tree arg, 
> pointer_query _qry)
>  case 'u':
>base = 10;
>break;
> +case 'b':
> +case 'B':
> +  base = 2;
> +  break;
>  case 'o':
>base = 8;
>break;
> @@ -1351,10 +1366,10 @@ format_integer (const directive , tree arg, 
> pointer_query _qry)
>  
>/* Bump up the counters if WIDTH is greater than LEN.  */
>res.adjust_for_width_or_precision (dir.width, dirtype, base,
> -  (sign | maybebase) + (base == 16));
> +  (sign | maybebase) + (base == 2 || 
> base == 16));
>/* Bump up the counters again if PRECision is greater still.  */
>res.adjust_for_width_or_precision (dir.prec, dirtype, base,
> -  (sign | maybebase) + (base == 16));
> +  (sign | maybebase) + (base == 2 || 
> base == 16));
>  
>return res;
>  }
> @@ -1503,7 +1518,7 @@ format_integer (const directive , tree arg, 
> pointer_query _qry)
> if (res.range.min == 1)
>   res.range.likely += base == 8 ? 1 : 2;
> else if (res.range.min == 2
> -

[Bug c++/105130] gcc does not warn about unused return value of last expression of statement expr

[dani at danielbertalan dot dev via Gcc-bugs]

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

--- Comment #1 from Daniel Bertalan  ---
Created attachment 52740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52740=edit
Proposed patch #2

Actually, my proposed patch was definitely incorrect. It didn't allow me to
circumvent the warning by explicitly casting to void. This new version fixes
that issue.

[Bug c/105131] New: Warning for mismatched declaration/definition with enum

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

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

Bug ID: 105131
   Summary: Warning for mismatched declaration/definition with
enum
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

For a testcase such as

enum E { l = -1, z = 0, g = 1 };
int foo(void);
enum E foo(void) { return z; }

If the implementation type of 'enum E' is not 'int',
we will correctly emit an error (e.g. -fshort-enums).

It would be desirable to emit a warning in this case,
because it is probably a mistake and definitely a
portability error.

[Bug c++/105130] New: gcc does not warn about unused return value of last expression of statement expr

[dani at danielbertalan dot dev via Gcc-bugs]

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

Bug ID: 105130
   Summary: gcc does not warn about unused return value of last
expression of statement expr
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
  Target Milestone: ---

Created attachment 52739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52739=edit
Proposed patch

The following code does not cause a warning about the return value of the foo()
function being ignored:

$ cat unused.cc
[[nodiscard]] int foo();

int main() {
({ foo(); });
}

$ g++ -Wunused-value -std=c++20 unused.cc
[no warnings]

The issue seems to be that CLEANUP_POINT_EXPR and STATEMENT_LIST -- which are
what statement expressions are turned into -- are not handled in
convert_to_void() (cp/cvt.cc).

The attached patch resolves the issue, but as a newbie to hacking on gcc, I
can't evaluate if it has any unintended consequences.

[Bug c++/103852] [10/11/12 Regression] Alias template argument deduction is available in C++17 mode

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

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org

[PATCH 7/8] Output BTF DECL_TAG and TYPE_TAG types

[David Faust via Gcc-patches]

This patch updates btfout.cc to be aware of the DECL_TAG and TYPE_TAG
kinds and output them appropriately.

gcc/

* btfout.cc (get_btf_kind): Handle TYPE_TAG and DECL_TAG kinds.
(btf_calc_num_vbytes): Likewise.
(btf_asm_type): Likewise.
(output_asm_btf_vlen_bytes): Likewise.
---
 gcc/btfout.cc | 28 
 1 file changed, 28 insertions(+)

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 31af50521da..f291cd925be 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -136,6 +136,8 @@ get_btf_kind (uint32_t ctf_kind)
 case CTF_K_VOLATILE: return BTF_KIND_VOLATILE;
 case CTF_K_CONST:return BTF_KIND_CONST;
 case CTF_K_RESTRICT: return BTF_KIND_RESTRICT;
+case CTF_K_TYPE_TAG: return BTF_KIND_TYPE_TAG;
+case CTF_K_DECL_TAG: return BTF_KIND_DECL_TAG;
 default:;
 }
   return BTF_KIND_UNKN;
@@ -201,6 +203,7 @@ btf_calc_num_vbytes (ctf_dtdef_ref dtd)
 case BTF_KIND_CONST:
 case BTF_KIND_RESTRICT:
 case BTF_KIND_FUNC:
+case BTF_KIND_TYPE_TAG:
 /* These kinds have no vlen data.  */
   break;
 
@@ -238,6 +241,10 @@ btf_calc_num_vbytes (ctf_dtdef_ref dtd)
   vlen_bytes += vlen * sizeof (struct btf_var_secinfo);
   break;
 
+case BTF_KIND_DECL_TAG:
+  vlen_bytes += sizeof (struct btf_decl_tag);
+  break;
+
 default:
   break;
 }
@@ -636,6 +643,22 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
   dw2_asm_output_data (4, dtd->dtd_data.ctti_size, "btt_size: %uB",
   dtd->dtd_data.ctti_size);
   return;
+case BTF_KIND_DECL_TAG:
+  {
+   /* A decl tag might refer to (be the child DIE of) a variable. Try to
+  lookup the parent DIE's CTF variable, and if it exists point to the
+  corresponding BTF variable. This is an odd construction - we have a
+  'type' which refers to a variable, rather than the reverse.  */
+   dw_die_ref parent = dw_get_die_parent (dtd->dtd_key);
+   ctf_dvdef_ref dvd = ctf_dvd_lookup (ctfc, parent);
+   if (dvd)
+ {
+   unsigned int var_id =
+ *(btf_var_ids->get (dvd)) + num_types_added + 1;
+   dw2_asm_output_data (4, var_id, "btt_type");
+   return;
+ }
+  }
 default:
   break;
 }
@@ -949,6 +972,11 @@ output_asm_btf_vlen_bytes (ctf_container_ref ctfc, 
ctf_dtdef_ref dtd)
 at this point.  */
   gcc_unreachable ();
 
+case BTF_KIND_DECL_TAG:
+  dw2_asm_output_data (4, dtd->dtd_u.dtu_btfnote.component_idx,
+  "decltag_compidx");
+  break;
+
 default:
   /* All other BTF type kinds have no variable length data.  */
   break;
-- 
2.35.1

[PATCH 8/8] testsuite: Add tests for BTF tags

[David Faust via Gcc-patches]

This commit adds tests for the tags, in BTF and in DWARF.

gcc/teststuite/

* gcc.dg/debug/btf/btf-decltag-func.c: New test.
* gcc.dg/debug/btf/btf-decltag-sou.c: Likewise.
* gcc.dg/debug/btf/btf-decltag-typedef.c: Likewise.
* gcc.dg/debug/btf/btf-typetag-1.c: Likewise.
* gcc.dg/debug/dwarf2/annotation-1.c: Likewise.
---
 .../gcc.dg/debug/btf/btf-decltag-func.c   | 18 ++
 .../gcc.dg/debug/btf/btf-decltag-sou.c| 34 +++
 .../gcc.dg/debug/btf/btf-decltag-typedef.c| 15 
 .../gcc.dg/debug/btf/btf-typetag-1.c  | 20 +++
 .../gcc.dg/debug/dwarf2/annotation-1.c| 29 
 5 files changed, 116 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-decltag-func.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-decltag-sou.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-decltag-typedef.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-typetag-1.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/annotation-1.c

diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-decltag-func.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-decltag-func.c
new file mode 100644
index 000..aa2c31aaa32
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-decltag-func.c
@@ -0,0 +1,18 @@
+
+/* { dg-do compile )  */
+/* { dg-options "-O0 -gbtf -dA" } */
+
+/* { dg-final { scan-assembler-times "\[\t \]0x1100\[\t 
\]+\[^\n\]*btt_info" 4 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x\[\t 
\]+\[^\n\]*decltag_compidx" 3 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x1\[\t 
\]+\[^\n\]*decltag_compidx" 1 } } */
+
+#define __tag1 __attribute__((btf_decl_tag("decl-tag-1")))
+#define __tag2 __attribute__((btf_decl_tag("decl-tag-2")))
+#define __tag3 __attribute__((btf_decl_tag("decl-tag-3")))
+
+extern int bar (int __tag1, int __tag2) __tag3;
+
+int __tag1 __tag2 foo (int arg1, int *arg2 __tag2)
+  {
+return bar (arg1 + 1, *arg2 + 2);
+  }
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-decltag-sou.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-decltag-sou.c
new file mode 100644
index 000..be89d0d32de
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-decltag-sou.c
@@ -0,0 +1,34 @@
+
+/* { dg-do compile )  */
+/* { dg-options "-O0 -gbtf -dA" } */
+
+/* { dg-final { scan-assembler-times "\[\t \]0x1100\[\t 
\]+\[^\n\]*btt_info" 16 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*decltag_compidx" 
2 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x1\[\t 
\]+\[^\n\]*decltag_compidx" 1 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x2\[\t 
\]+\[^\n\]*decltag_compidx" 3 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x3\[\t 
\]+\[^\n\]*decltag_compidx" 3 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x4\[\t 
\]+\[^\n\]*decltag_compidx" 1 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x\[\t 
\]+\[^\n\]*decltag_compidx" 6 } } */
+
+#define __tag1 __attribute__((btf_decl_tag("decl-tag-1")))
+#define __tag2 __attribute__((btf_decl_tag("decl-tag-2")))
+#define __tag3 __attribute__((btf_decl_tag("decl-tag-3")))
+
+struct t {
+  int a;
+  long b __tag3;
+  char c __tag2 __tag3;
+} __tag1 __tag2;
+
+struct t my_t __tag1 __tag3;
+
+
+union u {
+  char one __tag1 __tag2;
+  short two;
+  int three __tag1;
+  long four __tag1 __tag2 __tag3;
+  long long five __tag2;
+} __tag3;
+
+union u my_u __tag2;
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-decltag-typedef.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-decltag-typedef.c
new file mode 100644
index 000..75be876f949
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-decltag-typedef.c
@@ -0,0 +1,15 @@
+/* { dg-do compile )  */
+/* { dg-options "-O0 -gbtf -dA" } */
+
+/* { dg-final { scan-assembler-times "\[\t \]0x1100\[\t 
\]+\[^\n\]*btt_info" 3 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x\[\t 
\]+\[^\n\]*decltag_compidx" 3 } } */
+
+#define __tag1 __attribute__((btf_decl_tag("decl-tag-1")))
+#define __tag2 __attribute__((btf_decl_tag("decl-tag-2")))
+#define __tag3 __attribute__((btf_decl_tag("decl-tag-3")))
+
+struct s { int a; } __tag1;
+
+typedef struct s * sptr __tag2;
+
+sptr my_sptr __tag3;
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-typetag-1.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-typetag-1.c
new file mode 100644
index 000..4b05663385f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-typetag-1.c
@@ -0,0 +1,20 @@
+/* { dg-do compile )  */
+/* { dg-options "-O0 -gbtf -dA" } */
+
+/* { dg-final { scan-assembler-times "\[\t \]0x1200\[\t 
\]+\[^\n\]*btt_info" 4 } } */
+
+#define __tag1 __attribute__((btf_type_tag("tag1")))
+#define __tag2 __attribute__((btf_type_tag("tag2")))
+#define __tag3 __attribute__((btf_type_tag("tag3")))
+
+int __tag1 * x;
+const int __tag2 * y;
+
+struct a;
+
+struct b
+{
+  struct a __tag2 __tag3 * inner_a;
+};
+
+struct b my_b;
diff --git 

[PATCH 6/8] dwarf2ctf: convert tag DIEs to CTF types

[David Faust via Gcc-patches]

This patch makes the DWARF-to-CTF conversion process aware of the new
DW_TAG_GNU_annotation DIEs. The DIEs are converted to CTF_K_DECL_TAG or
CTF_K_TYPE_TAG types as approprate and added to the compilation unit CTF
container.

gcc/

* dwarf2ctf.cc (handle_btf_tags): New function.
(gen_ctf_sou_type): Call it here, if appropriate. Don't try to
create member types for children that are not DW_TAG_member.
(gen_ctf_function_type): Call handle_btf_tags if appropriate.
(gen_ctf_variable): Likewise.
(gen_ctf_function): Likewise.
(gen_ctf_type): Likewise.
---
 gcc/dwarf2ctf.cc | 113 ++-
 1 file changed, 112 insertions(+), 1 deletion(-)

diff --git a/gcc/dwarf2ctf.cc b/gcc/dwarf2ctf.cc
index 32495cf4307..8811ec3e878 100644
--- a/gcc/dwarf2ctf.cc
+++ b/gcc/dwarf2ctf.cc
@@ -32,6 +32,12 @@ along with GCC; see the file COPYING3.  If not see
 static ctf_id_t
 gen_ctf_type (ctf_container_ref, dw_die_ref);
 
+static void
+gen_ctf_variable (ctf_container_ref, dw_die_ref);
+
+static void
+handle_btf_tags (ctf_container_ref, dw_die_ref, ctf_id_t, int);
+
 /* All the DIE structures we handle come from the DWARF information
generated by GCC.  However, there are three situations where we need
to create our own created DIE structures because GCC doesn't
@@ -547,6 +553,7 @@ gen_ctf_sou_type (ctf_container_ref ctfc, dw_die_ref sou, 
uint32_t kind)
   /* Now process the struct members.  */
   {
 dw_die_ref c;
+int idx = 0;
 
 c = dw_get_die_child (sou);
 if (c)
@@ -559,6 +566,12 @@ gen_ctf_sou_type (ctf_container_ref ctfc, dw_die_ref sou, 
uint32_t kind)
 
  c = dw_get_die_sib (c);
 
+ if (dw_get_die_tag (c) != DW_TAG_member)
+   continue;
+
+ if (c == dw_get_die_child (sou))
+   idx = 0;
+
  field_name = get_AT_string (c, DW_AT_name);
  field_type = ctf_get_AT_type (c);
  field_location = ctf_get_AT_data_member_location (c);
@@ -626,6 +639,12 @@ gen_ctf_sou_type (ctf_container_ref ctfc, dw_die_ref sou, 
uint32_t kind)
 field_name,
 field_type_id,
 field_location);
+
+ /* Handle BTF tags on the member.  */
+ if (btf_debuginfo_p ())
+   handle_btf_tags (ctfc, c, sou_type_id, idx);
+
+ idx++;
}
   while (c != dw_get_die_child (sou));
   }
@@ -716,6 +735,9 @@ gen_ctf_function_type (ctf_container_ref ctfc, dw_die_ref 
function,
  arg_type = gen_ctf_type (ctfc, ctf_get_AT_type (c));
  /* Add the argument to the existing CTF function type.  */
  ctf_add_function_arg (ctfc, function, arg_name, arg_type);
+
+ if (btf_debuginfo_p ())
+   handle_btf_tags (ctfc, c, function_type_id, i - 1);
}
  else
/* This is a local variable.  Ignore.  */
@@ -814,6 +836,11 @@ gen_ctf_variable (ctf_container_ref ctfc, dw_die_ref die)
   /* Generate the new CTF variable and update global counter.  */
   (void) ctf_add_variable (ctfc, var_name, var_type_id, die, external_vis);
   ctfc->ctfc_num_global_objts += 1;
+
+  /* Handle any BTF tags on the variable.  */
+  if (btf_debuginfo_p ())
+handle_btf_tags (ctfc, die, CTF_NULL_TYPEID, -1);
+
 }
 
 /* Add a CTF function record for the given input DWARF DIE.  */
@@ -831,8 +858,12 @@ gen_ctf_function (ctf_container_ref ctfc, dw_die_ref die)
  counter.  Note that DWARF encodes function types in both
  DW_TAG_subroutine_type and DW_TAG_subprogram in exactly the same
  way.  */
-  (void) gen_ctf_function_type (ctfc, die, true /* from_global_func */);
+  function_type_id = gen_ctf_function_type (ctfc, die, true /* 
from_global_func */);
   ctfc->ctfc_num_global_funcs += 1;
+
+  /* Handle any BTF tags on the function itself.  */
+  if (btf_debuginfo_p ())
+handle_btf_tags (ctfc, die, function_type_id, -1);
 }
 
 /* Add CTF type record(s) for the given input DWARF DIE and return its type id.
@@ -909,6 +940,10 @@ gen_ctf_type (ctf_container_ref ctfc, dw_die_ref die)
   break;
 }
 
+  /* Handle any BTF tags on the type.  */
+  if (btf_debuginfo_p () && !unrecog_die)
+handle_btf_tags (ctfc, die, type_id, -1);
+
   /* For all types unrepresented in CTF, use an explicit CTF type of kind
  CTF_K_UNKNOWN.  */
   if ((type_id == CTF_NULL_TYPEID) && (!unrecog_die))
@@ -917,6 +952,82 @@ gen_ctf_type (ctf_container_ref ctfc, dw_die_ref die)
   return type_id;
 }
 
+/* BTF support. Handle any BTF tags attached to a given DIE, and generate
+   intermediate CTF types for them. Type tags are inserted into the type chain
+   at this point. The return value is the CTF type ID of the last type tag
+   created (for type chaining), or the same as the argument TYPE_ID if there 
are
+   no type tags.
+   Note that despite the name, the BTF spec seems to allow decl tags on types
+   as well as 

[PATCH 5/8] ctfc: Add support to pass through BTF annotations

[David Faust via Gcc-patches]

BTF generation currently relies on the internal CTF representation to
convert debug info from DWARF dies. This patch adds a new internal
header, "ctf-int.h", which defines CTF kinds to be used internally to
represent BTF tags which must pass through the CTF container. It also
adds a new type for representing information specific to those tags, and
a member for that type in ctf_dtdef.

This patch also updates ctf_add_reftype to accept a const char * name,
and add it for the newly added type.

gcc/

* ctf-int.h: New file.
* ctfc.cc (ctf_add_reftype): Add NAME parameter. Pass it to
ctf_add_generic call.
(ctf_add_pointer): Update ctf_add_reftype call accordingly.
* ctfc.h (ctf_add_reftype): Analogous change.
(ctf_btf_annotation): New.
(ctf_dtdef): Add member for it.
(enum ctf_dtu_d_union_enum): Likewise.
* dwarf2ctf.cc (gen_ctf_modifier_type): Update call to
ctf_add_reftype accordingly.
---
 gcc/ctf-int.h| 29 +
 gcc/ctfc.cc  | 11 +++
 gcc/ctfc.h   | 17 ++---
 gcc/dwarf2ctf.cc |  2 +-
 4 files changed, 51 insertions(+), 8 deletions(-)
 create mode 100644 gcc/ctf-int.h

diff --git a/gcc/ctf-int.h b/gcc/ctf-int.h
new file mode 100644
index 000..fb5f4aacad6
--- /dev/null
+++ b/gcc/ctf-int.h
@@ -0,0 +1,29 @@
+/* ctf-int.h - GCC internal definitions used for CTF debug info.
+   Copyright (C) 2022 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#ifndef GCC_CTF_INT_H
+#define GCC_CTF_INT_H 1
+
+/* These CTF kinds only exist as a bridge to generating BTF types for
+   BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG. They do not correspond to any
+   representable type kind in CTF.  */
+#define CTF_K_DECL_TAG  62
+#define CTF_K_TYPE_TAG  63
+
+#endif /* GCC_CTF_INT_H */
diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc
index 6fe44d2e8d4..031a6fff65d 100644
--- a/gcc/ctfc.cc
+++ b/gcc/ctfc.cc
@@ -107,6 +107,9 @@ ctf_dtu_d_union_selector (ctf_dtdef_ref ctftype)
   return CTF_DTU_D_ARGUMENTS;
 case CTF_K_SLICE:
   return CTF_DTU_D_SLICE;
+case CTF_K_DECL_TAG:
+case CTF_K_TYPE_TAG:
+  return CTF_DTU_D_BTFNOTE;
 default:
   /* The largest member as default.  */
   return CTF_DTU_D_ARRAY;
@@ -394,15 +397,15 @@ ctf_add_encoded (ctf_container_ref ctfc, uint32_t flag, 
const char * name,
 }
 
 ctf_id_t
-ctf_add_reftype (ctf_container_ref ctfc, uint32_t flag, ctf_id_t ref,
-uint32_t kind, dw_die_ref die)
+ctf_add_reftype (ctf_container_ref ctfc, uint32_t flag, const char * name,
+ctf_id_t ref, uint32_t kind, dw_die_ref die)
 {
   ctf_dtdef_ref dtd;
   ctf_id_t type;
 
   gcc_assert (ref <= CTF_MAX_TYPE);
 
-  type = ctf_add_generic (ctfc, flag, NULL, , die);
+  type = ctf_add_generic (ctfc, flag, name, , die);
   dtd->dtd_data.ctti_info = CTF_TYPE_INFO (kind, flag, 0);
   /* Caller of this API must guarantee that a CTF type with id = ref already
  exists.  This will also be validated for us at link-time.  */
@@ -514,7 +517,7 @@ ctf_id_t
 ctf_add_pointer (ctf_container_ref ctfc, uint32_t flag, ctf_id_t ref,
 dw_die_ref die)
 {
-  return (ctf_add_reftype (ctfc, flag, ref, CTF_K_POINTER, die));
+  return (ctf_add_reftype (ctfc, flag, NULL, ref, CTF_K_POINTER, die));
 }
 
 ctf_id_t
diff --git a/gcc/ctfc.h b/gcc/ctfc.h
index 18c93c802a0..51f43cd01cb 100644
--- a/gcc/ctfc.h
+++ b/gcc/ctfc.h
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "dwarf2ctf.h"
 #include "ctf.h"
 #include "btf.h"
+#include "ctf-int.h"
 
 /* Invalid CTF type ID definition.  */
 
@@ -151,6 +152,13 @@ typedef struct GTY (()) ctf_func_arg
 
 #define ctf_farg_list_next(elem) ((ctf_func_arg_t *)((elem)->farg_next))
 
+/* BTF support: a BTF type tag or decl tag.  */
+
+typedef struct GTY (()) ctf_btf_annotation
+{
+  uint32_t component_idx;
+} ctf_btf_annotation_t;
+
 /* Type definition for CTF generation.  */
 
 struct GTY ((for_user)) ctf_dtdef
@@ -173,6 +181,8 @@ struct GTY ((for_user)) ctf_dtdef
 ctf_func_arg_t * GTY ((tag ("CTF_DTU_D_ARGUMENTS"))) dtu_argv;
 /* slice.  */
 ctf_sliceinfo_t GTY ((tag ("CTF_DTU_D_SLICE"))) dtu_slice;
+/* btf annotation.  */
+ctf_btf_annotation_t GTY ((tag ("CTF_DTU_D_BTFNOTE"))) dtu_btfnote;
   } dtd_u;
 };
 
@@ -212,7 +222,8 @@ enum ctf_dtu_d_union_enum {

[PATCH 4/8] dwarf: create BTF decl and type tag DIEs

[David Faust via Gcc-patches]

The "btf_decl_tag" and "btf_type_tag" attributes are handled by
constructing DW_TAG_LLVM_annotation DIEs. The DIEs are children of the
declarations or types which they annotate, and convey the annotation via
a string constant.

Currently, all generation of these DIEs is gated behind
btf_debuginfo_p (). That is, they will not be generated nor output
unless BTF debug information is generated. The DIEs will be output in
DWARF if both -gbtf and -gdwarf are supplied by the user.

gcc/

* dwarf2out.cc (gen_btf_decl_tag_dies): New function.
(gen_btf_type_tag_dies): Likewise.
(modified_type_die): Call them here, if appropriate.
(gen_formal_parameter_die): Likewise.
(gen_typedef_die): Likewise.
(gen_type_die): Likewise.
(gen_decl_die): Likewise.
---
 gcc/dwarf2out.cc | 102 +++
 1 file changed, 102 insertions(+)

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 35322fb5f6e..8f59213f96e 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -13612,6 +13612,78 @@ long_double_as_float128 (tree type)
   return NULL_TREE;
 }
 
+/* BTF support. Given a tree T, which may be a decl or a type, process any
+   "btf_decl_tag" attributes on T, provided in ATTR. Construct
+   DW_TAG_GNU_annotation DIEs appropriately as children of TARGET, usually
+   the DIE for T.  */
+
+static void
+gen_btf_decl_tag_dies (tree t, dw_die_ref target)
+{
+  dw_die_ref die;
+  tree attr;
+
+  if (t == NULL_TREE || !target)
+return;
+
+  if (TYPE_P (t))
+attr = lookup_attribute ("btf_decl_tag", TYPE_ATTRIBUTES (t));
+  else if (DECL_P (t))
+attr = lookup_attribute ("btf_decl_tag", DECL_ATTRIBUTES (t));
+  else
+/* This is an error.  */
+gcc_unreachable ();
+
+  while (attr != NULL_TREE)
+{
+  die = new_die (DW_TAG_GNU_annotation, target, t);
+  add_name_attribute (die, IDENTIFIER_POINTER (get_attribute_name (attr)));
+  add_AT_string (die, DW_AT_const_value,
+TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
+  attr = TREE_CHAIN (attr);
+}
+
+  /* Strip the decl tag attribute to avoid creating multiple copies if we hit
+ this tree node again in some recursive call.  */
+  if (TYPE_P (t))
+TYPE_ATTRIBUTES (t) =
+  remove_attribute ("btf_decl_tag", TYPE_ATTRIBUTES (t));
+  else if (DECL_P (t))
+DECL_ATTRIBUTES (t) =
+  remove_attribute ("btf_decl_tag", DECL_ATTRIBUTES (t));
+}
+
+/* BTF support. Given a tree TYPE, process any "btf_type_tag" attributes on
+   TYPE. Construct DW_TAG_GNU_annotation DIEs appropriately as children of
+   TARGET, usually the DIE for TYPE.  */
+
+static void
+gen_btf_type_tag_dies (tree type, dw_die_ref target)
+{
+  dw_die_ref die;
+  tree attr;
+
+  if (type == NULL_TREE || !target)
+return;
+
+  gcc_assert (TYPE_P (type));
+
+  attr = lookup_attribute ("btf_type_tag", TYPE_ATTRIBUTES (type));
+  while (attr != NULL_TREE)
+{
+  die = new_die (DW_TAG_GNU_annotation, target, type);
+  add_name_attribute (die, IDENTIFIER_POINTER (get_attribute_name (attr)));
+  add_AT_string (die, DW_AT_const_value,
+TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
+  attr = TREE_CHAIN (attr);
+}
+
+  /* Strip the type tag attribute to avoid creating multiple copies if we hit
+ this type again in some recursive call.  */
+  TYPE_ATTRIBUTES (type) =
+remove_attribute ("btf_type_tag", TYPE_ATTRIBUTES (type));
+}
+
 /* Given a pointer to an arbitrary ..._TYPE tree node, return a debugging
entry that chains the modifiers specified by CV_QUALS in front of the
given type.  REVERSE is true if the type is to be interpreted in the
@@ -14010,6 +14082,10 @@ modified_type_die (tree type, int cv_quals, bool 
reverse,
   if (TYPE_ARTIFICIAL (type))
 add_AT_flag (mod_type_die, DW_AT_artificial, 1);
 
+  /* BTF support. Handle any "btf_type_tag" attributes on the type.  */
+  if (btf_debuginfo_p ())
+gen_btf_type_tag_dies (type, mod_type_die);
+
   return mod_type_die;
 }
 
@@ -22986,6 +23062,10 @@ gen_formal_parameter_die (tree node, tree origin, bool 
emit_name_p,
   gcc_unreachable ();
 }
 
+  /* BTF Support */
+  if (btf_debuginfo_p ())
+gen_btf_decl_tag_dies (node, parm_die);
+
   return parm_die;
 }
 
@@ -26060,6 +26140,10 @@ gen_typedef_die (tree decl, dw_die_ref context_die)
 
   if (get_AT (type_die, DW_AT_name))
 add_pubtype (decl, type_die);
+
+  /* BTF: handle attribute btf_decl_tag which may appear on the typedef.  */
+  if (btf_debuginfo_p ())
+gen_btf_decl_tag_dies (decl, type_die);
 }
 
 /* Generate a DIE for a struct, class, enum or union type.  */
@@ -26373,6 +26457,20 @@ gen_type_die (tree type, dw_die_ref context_die)
  if (die)
check_die (die);
}
+
+  /* BTF support. Handle any "btf_type_tag" or "btf_decl_tag" attributes
+on the type, constructing annotation DIEs as appropriate.  */
+  if 

[PATCH 3/8] c-family: Add BTF tag attribute handlers

[David Faust via Gcc-patches]

This patch adds attribute handlers in GCC for two attributes already
supported in LLVM: "btf_decl_tag" and "btf_type_tag". Both attributes
accept a single string constant argument, and are used to add arbitrary
annotations to debug information generated for the types/decls to which
they apply.

gcc/c-family/

* c-attribs.cc (c_common_attribute_table): Add new attributes
btf_decl_tag and btf_type_tag.
(handle_btf_decl_tag_attribute): New.
(handle_btf_type_tag_attribute): Likewise.
---
 gcc/c-family/c-attribs.cc | 45 +++
 1 file changed, 45 insertions(+)

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 111a33f405a..ec52f6defb4 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -174,6 +174,9 @@ static tree handle_signed_bool_precision_attribute (tree *, 
tree, tree, int,
bool *);
 static tree handle_retain_attribute (tree *, tree, tree, int, bool *);
 
+static tree handle_btf_decl_tag_attribute (tree *, tree, tree, int, bool *);
+static tree handle_btf_type_tag_attribute (tree *, tree, tree, int, bool *);
+
 /* Helper to define attribute exclusions.  */
 #define ATTR_EXCL(name, function, type, variable)  \
   { name, function, type, variable }
@@ -555,6 +558,12 @@ const struct attribute_spec c_common_attribute_table[] =
  handle_dealloc_attribute, NULL },
   { "tainted_args",  0, 0, true,  false, false, false,
  handle_tainted_args_attribute, NULL },
+
+  { "btf_type_tag",   1, 1, false, true, false, false,
+ handle_btf_type_tag_attribute, NULL },
+  { "btf_decl_tag",   1, 1, false, false, false, false,
+ handle_btf_decl_tag_attribute, NULL },
+
   { NULL, 0, 0, false, false, false, false, NULL, NULL }
 };
 
@@ -5854,6 +5863,42 @@ handle_tainted_args_attribute (tree *node, tree name, 
tree, int,
   return NULL_TREE;
 }
 
+/* Handle a "btf_decl_tag" attribute; arguments as in
+   struct attribute_spec.handler.   */
+
+static tree
+handle_btf_decl_tag_attribute (tree *, tree name, tree args, int,
+  bool *no_add_attrs)
+{
+  if (!args)
+*no_add_attrs = true;
+  else if (TREE_CODE (TREE_VALUE (args)) != STRING_CST)
+{
+  error ("%qE attribute requires a string", name);
+  *no_add_attrs = true;
+}
+
+  return NULL_TREE;
+}
+
+/* Handle a "btf_type_tag" attribute; arguments as in
+   struct attribute_spec.handler.   */
+
+static tree
+handle_btf_type_tag_attribute (tree *, tree name, tree args, int,
+  bool *no_add_attrs)
+{
+  if (!args)
+*no_add_attrs = true;
+  else if (TREE_CODE (TREE_VALUE (args)) != STRING_CST)
+{
+  error ("%qE attribute requires a string", name);
+  *no_add_attrs = true;
+}
+
+  return NULL_TREE;
+}
+
 /* Attempt to partially validate a single attribute ATTR as if
it were to be applied to an entity OPER.  */
 
-- 
2.35.1

[PATCH 2/8] include: Add BTF tag defines to dwarf2 and btf

[David Faust via Gcc-patches]

include/

* btf.h: Add BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG defines. Update
comments.
(struct btf_decl_tag): New.
* dwarf2.def: Add new DWARF extension DW_TAG_GNU_annotation.
---
 include/btf.h  | 17 +++--
 include/dwarf2.def |  4 
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/include/btf.h b/include/btf.h
index 78b551ced23..37deaef8b48 100644
--- a/include/btf.h
+++ b/include/btf.h
@@ -69,7 +69,7 @@ struct btf_type
 
   /* SIZE is used by INT, ENUM, STRUCT, UNION, DATASEC kinds.
  TYPE is used by PTR, TYPEDEF, VOLATILE, CONST, RESTRICT, FUNC,
- FUNC_PROTO and VAR kinds.  */
+ FUNC_PROTO, VAR and DECL_TAG kinds.  */
   union
   {
 uint32_t size; /* Size of the entire type, in bytes.  */
@@ -109,7 +109,9 @@ struct btf_type
 #define BTF_KIND_VAR   14  /* Variable.  */
 #define BTF_KIND_DATASEC   15  /* Section such as .bss or .data.  */
 #define BTF_KIND_FLOAT 16  /* Floating point.  */
-#define BTF_KIND_MAX   BTF_KIND_FLOAT
+#define BTF_KIND_DECL_TAG  17  /* Decl Tag.  */
+#define BTF_KIND_TYPE_TAG  18  /* Type Tag.  */
+#define BTF_KIND_MAX   BTF_KIND_TYPE_TAG
 #define NR_BTF_KINDS   (BTF_KIND_MAX + 1)
 
 /* For some BTF_KINDs, struct btf_type is immediately followed by
@@ -190,6 +192,17 @@ struct btf_var_secinfo
   uint32_t size;   /* Size (in bytes) of variable.  */
 };
 
+/* BTF_KIND_DECL_TAG is followed by a single struct btf_decl_tag, which
+   describes the tag location:
+   - If component_idx == -1, then the tag is applied to a struct, union,
+ variable or function.
+   - Otherwise it is applied to a struct/union member or function argument
+ with the given given index numbered 0..vlen-1.  */
+struct btf_decl_tag
+{
+  int32_t component_idx;
+};
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/include/dwarf2.def b/include/dwarf2.def
index 4214c80907a..e054890130a 100644
--- a/include/dwarf2.def
+++ b/include/dwarf2.def
@@ -174,6 +174,10 @@ DW_TAG (DW_TAG_GNU_formal_parameter_pack, 0x4108)
are properly part of DWARF 5.  */
 DW_TAG (DW_TAG_GNU_call_site, 0x4109)
 DW_TAG (DW_TAG_GNU_call_site_parameter, 0x410a)
+
+/* Extension for BTF annotations.  */
+DW_TAG (DW_TAG_GNU_annotation, 0x6000)
+
 /* Extensions for UPC.  See: http://dwarfstd.org/doc/DWARF4.pdf.  */
 DW_TAG (DW_TAG_upc_shared_type, 0x8765)
 DW_TAG (DW_TAG_upc_strict_type, 0x8766)
-- 
2.35.1

[PATCH 1/8] dwarf: Add dw_get_die_parent function

[David Faust via Gcc-patches]

gcc/

* dwarf2out.cc (dw_get_die_parent): New function.
* dwarf2out.h (dw_get_die_parent): Declare it here.
---
 gcc/dwarf2out.cc | 8 
 gcc/dwarf2out.h  | 1 +
 2 files changed, 9 insertions(+)

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 5681b01749a..35322fb5f6e 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -5235,6 +5235,14 @@ dw_get_die_sib (dw_die_ref die)
   return die->die_sib;
 }
 
+/* Return a reference to the parent of a given DIE.  */
+
+dw_die_ref
+dw_get_die_parent (dw_die_ref die)
+{
+  return die->die_parent;
+}
+
 /* Add an address constant attribute value to a DIE.  When using
dwarf_split_debug_info, address attributes in dies destined for the
final executable should be direct references--setting the parameter
diff --git a/gcc/dwarf2out.h b/gcc/dwarf2out.h
index 656ef94afde..e6962fb4848 100644
--- a/gcc/dwarf2out.h
+++ b/gcc/dwarf2out.h
@@ -455,6 +455,7 @@ extern dw_die_ref lookup_type_die (tree);
 
 extern dw_die_ref dw_get_die_child (dw_die_ref);
 extern dw_die_ref dw_get_die_sib (dw_die_ref);
+extern dw_die_ref dw_get_die_parent (dw_die_ref);
 extern enum dwarf_tag dw_get_die_tag (dw_die_ref);
 
 /* Data about a single source file.  */
-- 
2.35.1

[PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations

[David Faust via Gcc-patches]

Hello,

This patch series is a first attempt at adding support for:

- Two new C-language-level attributes that allow to associate (to "tag")
  particular declarations and types with arbitrary strings. As explained below,
  this is intended to be used to, for example, characterize certain pointer
  types.

- The conveyance of that information in the DWARF output in the form of a new
  DIE: DW_TAG_GNU_annotation.

- The conveyance of that information in the BTF output in the form of two new
  kinds of BTF objects: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG.

All of these facilities are being added to the eBPF ecosystem, and support for
them exists in some form in LLVM. However, as we shall see, we have found some
problems implementing them so some discussion is in order.

Purpose
===

1)  Addition of C-family language constructs (attributes) to specify free-text
tags on certain language elements, such as struct fields.

The purpose of these annotations is to provide additional information about
types, variables, and function paratemeters of interest to the kernel. A
driving use case is to tag pointer types within the linux kernel and eBPF
programs with additional semantic information, such as '__user' or '__rcu'.

For example, consider the linux kernel function do_execve with the
following declaration:

  static int do_execve(struct filename *filename,
 const char __user *const __user *__argv,
 const char __user *const __user *__envp);

Here, __user could be defined with these annotations to record semantic
information about the pointer parameters (e.g., they are user-provided) in
DWARF and BTF information. Other kernel facilites such as the eBPF verifier
can read the tags and make use of the information.

2)  Conveying the tags in the generated DWARF debug info.

The main motivation for emitting the tags in DWARF is that the Linux kernel
generates its BTF information via pahole, using DWARF as a source:

++  BTF  BTF   +--+
| pahole |---> vmlinux.btf --->| verifier |
++ +--+
^^
||
  DWARF |BTF |
||
 vmlinux  +-+
 module1.ko   | BPF program |
 module2.ko   +-+
   ...

This is because:

a)  Unlike GCC, LLVM will only generate BTF for BPF programs.

b)  GCC can generate BTF for whatever target with -gbtf, but there is no
support for linking/deduplicating BTF in the linker.

In the scenario above, the verifier needs access to the pointer tags of
both the kernel types/declarations (conveyed in the DWARF and translated
to BTF by pahole) and those of the BPF program (available directly in BTF).

Another motivation for having the tag information in DWARF, unrelated to
BPF and BTF, is that the drgn project (another DWARF consumer) also wants
to benefit from these tags in order to differentiate between different
kinds of pointers in the kernel.

3)  Conveying the tags in the generated BTF debug info.

This is easy: the main purpose of having this info in BTF is for the
compiled eBPF programs. The kernel verifier can then access the tags
of pointers used by the eBPF programs.


For more information about these tags and the motivation behind them, please
refer to the following linux kernel discussions:

  https://lore.kernel.org/bpf/20210914223004.244411-1-...@fb.com/
  https://lore.kernel.org/bpf/20211012164838.3345699-1-...@fb.com/
  https://lore.kernel.org/bpf/2022012604.1504583-1-...@fb.com/


What is in this patch series


This patch series adds support for these annotations in GCC. The implementation
is largely complete. However, in some cases the produced debug info (both DWARF
and BTF) differs significantly from that produced by LLVM. This issue is
discussed in detail below, along with a few specific questions for both GCC and
LLVM. Any input would be much appreciated.


Implementation Overview
===

To enable these annotations, two new C language attributes are added:
__attribute__((btf_decl_tag("foo")) and __attribute__((btf_type_tag("bar"))).
Both attributes accept a single arbitrary string constant argument, which will
be recorded in the generated DWARF and/or BTF debugging information. They have
no effect on code generation.

Note that we are using the same attribute names as LLVM, which include "btf"
in the name. This may be controversial, as these tags are not really
BTF-specific. A different name may be more appropriate. There was much
discussion about naming in the proposal for the 

[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

-Wformat-overflow handling for %b and %B directives in C2X standard

[Frolov Daniil via Gcc-patches]

Hello, I've noticed that -Wformat-overflow doesn't handle %b and %B
directives in the sprintf function. I've added a relevant issue in bugzilla
(bug #105129).
I attach a patch with a possible solution to the letter.
From 2051344e9500651f6e94c44cbc7820715382b957 Mon Sep 17 00:00:00 2001
From: Frolov Daniil 
Date: Fri, 1 Apr 2022 00:47:03 +0500
Subject: [PATCH] Support %b, %B for -Wformat-overflow (sprintf, snprintf)

testsuite: add tests to check -Wformat-overflow on %b.
Wformat-overflow1.c is compiled using -std=c2x so warning has to
be throwed

Wformat-overflow2.c doesn't throw warnings cause c2x std isn't
used

gcc/ChangeLog:

	* gimple-ssa-sprintf.cc
(check_std_c2x): New function
	(fmtresult::type_max_digits): add base == 2 handling
	(tree_digits): add handle for base == 2
	(format_integer): now handle %b and %B using base = 2
	(parse_directive): add cases to handle %b and %B directives
	(compute_format_length): add handling for base = 2

gcc/testsuite/ChangeLog:

	* gcc.dg/Wformat-overflow1.c: New test. (using -std=c2x)
	* gcc.dg/Wformat-overflow2.c: New test. (-std=c11 no warning)
---
 gcc/gimple-ssa-sprintf.cc| 42 
 gcc/testsuite/gcc.dg/Wformat-overflow1.c | 28 
 gcc/testsuite/gcc.dg/Wformat-overflow2.c | 16 +
 3 files changed, 79 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/Wformat-overflow1.c
 create mode 100644 gcc/testsuite/gcc.dg/Wformat-overflow2.c

diff --git a/gcc/gimple-ssa-sprintf.cc b/gcc/gimple-ssa-sprintf.cc
index c93f12f90b5..7f68c2b6e51 100644
--- a/gcc/gimple-ssa-sprintf.cc
+++ b/gcc/gimple-ssa-sprintf.cc
@@ -107,6 +107,15 @@ namespace {
 
 static int warn_level;
 
+/* b_overflow_flag depends on the current standart when using gcc */
+static bool b_overflow_flag;
+
+/* check is current standart version equals C2X*/
+static bool check_std_c2x () 
+{
+  return !strcmp (lang_hooks.name, "GNU C2X");
+}
+
 /* The minimum, maximum, likely, and unlikely maximum number of bytes
of output either a formatting function or an individual directive
can result in.  */
@@ -535,6 +544,8 @@ fmtresult::type_max_digits (tree type, int base)
   unsigned prec = TYPE_PRECISION (type);
   switch (base)
 {
+case 2:
+  return prec;
 case 8:
   return (prec + 2) / 3;
 case 10:
@@ -857,11 +868,11 @@ tree_digits (tree x, int base, HOST_WIDE_INT prec, bool plus, bool prefix)
 
   /* Adjust a non-zero value for the base prefix, either hexadecimal,
  or, unless precision has resulted in a leading zero, also octal.  */
-  if (prefix && absval && (base == 16 || prec <= ndigs))
+  if (prefix && absval && (base == 2 || base == 16 || prec <= ndigs))
 {
   if (base == 8)
 	res += 1;
-  else if (base == 16)
+  else if (base == 16 || base == 2) /*0x...(0X...) and 0b...(0B...)*/
 	res += 2;
 }
 
@@ -1229,6 +1240,10 @@ format_integer (const directive , tree arg, pointer_query _qry)
 case 'u':
   base = 10;
   break;
+case 'b':
+case 'B':
+  base = 2;
+  break;
 case 'o':
   base = 8;
   break;
@@ -1351,10 +1366,10 @@ format_integer (const directive , tree arg, pointer_query _qry)
 
   /* Bump up the counters if WIDTH is greater than LEN.  */
   res.adjust_for_width_or_precision (dir.width, dirtype, base,
-	 (sign | maybebase) + (base == 16));
+	 (sign | maybebase) + (base == 2 || base == 16));
   /* Bump up the counters again if PRECision is greater still.  */
   res.adjust_for_width_or_precision (dir.prec, dirtype, base,
-	 (sign | maybebase) + (base == 16));
+	 (sign | maybebase) + (base == 2 || base == 16));
 
   return res;
 }
@@ -1503,7 +1518,7 @@ format_integer (const directive , tree arg, pointer_query _qry)
 	  if (res.range.min == 1)
 	res.range.likely += base == 8 ? 1 : 2;
 	  else if (res.range.min == 2
-		   && base == 16
+		   && (base == 16 || base == 2)
 		   && (dir.width[0] == 2 || dir.prec[0] == 2))
 	++res.range.likely;
 	}
@@ -1511,9 +1526,9 @@ format_integer (const directive , tree arg, pointer_query _qry)
 
   res.range.unlikely = res.range.max;
   res.adjust_for_width_or_precision (dir.width, dirtype, base,
- (sign | maybebase) + (base == 16));
+ (sign | maybebase) + (base == 2 || base == 16));
   res.adjust_for_width_or_precision (dir.prec, dirtype, base,
- (sign | maybebase) + (base == 16));
+ (sign | maybebase) + (base == 2 || base == 16));
 
   return res;
 }
@@ -3680,6 +3695,8 @@ parse_directive (call_info ,
   ++pf;
   break;
 }
+  
+  
 
   switch (target_to_host (*pf))
 {
@@ -3713,6 +3730,14 @@ parse_directive (call_info ,
 case 'X':
   dir.fmtfunc = format_integer;
   break;
+
+case 'b':
+case 'B':
+  if (b_overflow_flag) {
+dir.fmtfunc = format_integer;
+break;
+  }
+  return 0;
 
 case 'p':
   /* The %p output is implementation-defined.  It's possible

[PATCH] c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]

[Marek Polacek via Gcc-patches]

Attribute format takes three arguments: archetype, string-index, and
first-to-check.  The last two specify the position in the function
parameter list.  r63030 clarified that "Since non-static C++ methods have
an implicit this argument, the arguments of such methods should be counted
from two, not one, when giving values for string-index and first-to-check."
Therefore one has to write

  struct D {
D(const char *, ...) __attribute__((format(printf, 2, 3)));
  };

However -- and this is the problem in this PR -- ctors with virtual
bases also get two additional parameters: the in-charge parameter and
the VTT parameter (added in maybe_retrofit_in_chrg).  In fact we'll end up
with two clones of the ctor: an in-charge and a not-in-charge version (see
build_cdtor_clones).  That means that the argument position the user
specified in the attribute argument will refer to different arguments,
depending on which constructor we're currently dealing with.  This can
cause a range of problems: wrong errors, confusing warnings, or crashes.

This patch corrects that; for C we don't have to do anything, and in C++
we can use num_artificial_parms_for.  It would be wrong to rewrite the
attributes the user supplied, so I've added an extra parameter called
adjust_pos.

Attribute format_arg is not affected, because it requires that the
function returns "const char *" which will never be the case for cdtors.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/101833
PR c++/47634

gcc/c-family/ChangeLog:

* c-attribs.cc (positional_argument): Add new argument adjust_pos,
use it.
* c-common.cc (check_function_arguments): Pass fndecl to
check_function_format.
* c-common.h (check_function_format): Adjust declaration.
(maybe_adjust_arg_pos_for_attribute): Add.
(positional_argument): Adjust declaration.
* c-format.cc (decode_format_attr): Add fndecl argument.  Pass it to
maybe_adjust_arg_pos_for_attribute.  Adjust calls to get_constant.
(handle_format_arg_attribute): Pass 0 to get_constant.
(get_constant): Add new argument adjust_pos, use it.
(check_function_format): Add fndecl argument.  Pass it to
decode_format_attr.
(handle_format_attribute): Get the fndecl from node[2].  Pass it to
decode_format_attr.

gcc/c/ChangeLog:

* c-objc-common.cc (maybe_adjust_arg_pos_for_attribute): New.

gcc/cp/ChangeLog:

* tree.cc (maybe_adjust_arg_pos_for_attribute): New.

gcc/testsuite/ChangeLog:

* g++.dg/ext/attr-format-arg1.C: New test.
* g++.dg/ext/attr-format1.C: New test.
* g++.dg/ext/attr-format2.C: New test.
* g++.dg/ext/attr-format3.C: New test.
---
 gcc/c-family/c-attribs.cc   | 14 ---
 gcc/c-family/c-common.cc|  4 +-
 gcc/c-family/c-common.h |  5 ++-
 gcc/c-family/c-format.cc| 46 +
 gcc/c/c-objc-common.cc  |  9 
 gcc/cp/tree.cc  | 19 +
 gcc/testsuite/g++.dg/ext/attr-format-arg1.C | 26 
 gcc/testsuite/g++.dg/ext/attr-format1.C | 32 ++
 gcc/testsuite/g++.dg/ext/attr-format2.C | 38 +
 gcc/testsuite/g++.dg/ext/attr-format3.C | 15 +++
 10 files changed, 182 insertions(+), 26 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ext/attr-format-arg1.C
 create mode 100644 gcc/testsuite/g++.dg/ext/attr-format1.C
 create mode 100644 gcc/testsuite/g++.dg/ext/attr-format2.C
 create mode 100644 gcc/testsuite/g++.dg/ext/attr-format3.C

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 111a33f405a..6e17847ec9e 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -599,12 +599,15 @@ attribute_takes_identifier_p (const_tree attr_id)
matching all C integral types except bool.  If successful, return
POS after default conversions, if any.  Otherwise, issue appropriate
warnings and return null.  A non-zero 1-based ARGNO should be passed
-   in by callers only for attributes with more than one argument.  */
+   in by callers only for attributes with more than one argument.
+   ADJUST_POS is used and non-zero in C++ when the function type has
+   invisible parameters generated by the compiler, such as the in-charge
+   or VTT parameters.  */
 
 tree
 positional_argument (const_tree fntype, const_tree atname, tree pos,
 tree_code code, int argno /* = 0 */,
-int flags /* = posargflags () */)
+int flags /* = posargflags () */, int adjust_pos /* = 0 */)
 {
   if (pos && TREE_CODE (pos) != IDENTIFIER_NODE
   && TREE_CODE (pos) != FUNCTION_DECL)
@@ -690,7 +693,7 @@ positional_argument (const_tree fntype, const_tree atname, 
tree pos,
   if (!nargs
   || !tree_fits_uhwi_p (pos)
   || ((flags & POSARG_ELLIPSIS) == 0
- && 

[Bug c++/105110] NTTP type deduction fails when dependent of previous NTTPs

[j.galecki11 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Jakub Gałecki  ---
Awesome! Happy to be of use.

Re: [PATCH] c++: Fix ICE due to shared BLOCK node in coroutine generation [PR103328]

[Jason Merrill via Gcc-patches]

On 3/30/22 09:06, Benno Evers via Gcc-patches wrote:

From: Benno Evers 

When finishing a function that is a coroutine, the function is
transformed into a "ramp" function, and the original user-provided
function body gets moved into a newly created "actor" function.

In this case `current_function_decl` points to the ramp function,
but `current_binding_level->blocks` would still point to the
scope block of the user-provided function body in the actor function,
so when the ramp function was finished during `poplevel()` in decl.cc,
we could end up with that block being reused as the `DECL_INITIAL()` of
the ramp function:

 subblocks = functionbody >= 0 ? current_binding_level->blocks : 0;
 // [...]
 DECL_INITIAL (current_function_decl) = block ? block : subblocks;

This block would then be independently modified by subsequent passes
touching either the ramp or the actor function, potentially causing
an ICE depending on the order and function of these passes.

gcc/cp/ChangeLog:

 PR c++/103328
 * coroutines.cc (morph_fn_to_coro): Reset
   current_binding_level->blocks.

gcc/testsuite/ChangeLog:

 PR c++/103328
 * g++.dg/coroutines/pr103328.C: New test.

Co-Authored-By: Iain Sandoe 


Looks like you also need a DCO sign-off; see

https://gcc.gnu.org/contribute.html#legal

for more information.


---
  gcc/cp/coroutines.cc   |  3 ++
  gcc/testsuite/g++.dg/coroutines/pr103328.C | 32 ++
  2 files changed, 35 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/coroutines/pr103328.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 23dc28271a4..ece30c905e8 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -4541,6 +4541,9 @@ morph_fn_to_coro (tree orig, tree *resumer, tree
*destroyer)


gmail is breaking your patch with word wrap; see

https://www.kernel.org/doc/html/v4.17/process/email-clients.html

for information about ways to work around this, or just use an attachment.


BLOCK_VARS (top_block) = BIND_EXPR_VARS (ramp_bind);
BLOCK_SUBBLOCKS (top_block) = NULL_TREE;

+  /* Reset the current binding level to the ramp function */
+  current_binding_level->blocks = top_block;
+
/* The decl_expr for the coro frame pointer, initialize to zero so that we
   can pass it to the IFN_CO_FRAME (since there's no way to pass a type,
   directly apparently).  This avoids a "used uninitialized" warning.  */
diff --git a/gcc/testsuite/g++.dg/coroutines/pr103328.C
b/gcc/testsuite/g++.dg/coroutines/pr103328.C
new file mode 100644
index 000..56fb54ab316
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr103328.C
@@ -0,0 +1,32 @@
+// { dg-additional-options "-g" }
+
+#include 
+
+struct task {
+  struct promise_type {
+task get_return_object() { return {}; }
+std::suspend_never initial_suspend() { return {}; }
+std::suspend_never final_suspend() noexcept { return {}; }
+void unhandled_exception() {}
+  };
+  bool await_ready() { return false; }
+  void await_suspend(std::coroutine_handle<> h) {}
+  void await_resume() {}
+};
+
+template 
+void call(Func func) { func(); }
+
+class foo {
+  void f();
+  task g();
+};
+
+void foo::f() {
+  auto lambda = [this]() noexcept -> task {
+  co_await g();
+  };
+  (void)call;
+}
+
+int main() {}

[Bug c++/105110] NTTP type deduction fails when dependent of previous NTTPs

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |12.0
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 12, thanks for the bug report.

[Bug c++/105110] NTTP type deduction fails when dependent of previous NTTPs

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:95533fe4f014c10dd18de649927668aba6117daf

commit r12-7966-g95533fe4f014c10dd18de649927668aba6117daf
Author: Patrick Palka 
Date:   Fri Apr 1 14:56:20 2022 -0400

c++: deducing from class type of NTTP [PR105110]

Here when attempting to deduce T in the NTTP type A from the argument
type 'const A', we give up due to the const:

  types âAâ and âconst Aâ have incompatible cv-qualifiers

But since the type of an NTTP cannot be cv-qualified, it seems natural
to ignore cv-qualifiers on the argument type before attempting to unify
the two types.

PR c++/105110

gcc/cp/ChangeLog:

* pt.cc (unify) : Drop cv-quals from
the argument type of an NTTP before deducing from it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-class52.C: New test.

Re: [patch]update the documentation for TARGET_ZERO_CALL_USED_REGS hook and add an assertion

[Qing Zhao via Gcc-patches]

FYI. 

I have committed the change to upstream as:

31933f4f788b6cd64cbb7ee42076997f6d0fe212

Qing
> On Mar 31, 2022, at 8:10 AM, Richard Sandiford  
> wrote:
> 
> Qing Zhao  writes:
>> Hi, 
>> 
>> Per our discussion on: 
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592002.html
>> 
>> I come up with the following patch to:
>> 
>> 1. Update the documentation for TARGET_ZERO_CALL_USED_REGS hook;
>> 2. Add an assertion in function.cc to make sure the actually zeroed_regs is 
>> a subset of all call used regs;
>>   (The reason I didn’t add a new parameter to TARGET_ZERO_CALL_USED_REGS is, 
>> I think adding the 
>>assertion in the common place function.cc is simpler to be implemented).
> 
> Yeah, that's fair.  I guess in theory, passing the parameter would allow
> targets to choose between two versions of zeroing the register, one with
> a temporary and one without.  But that's a purely hypothetical situation
> and we could always add a parameter later if that turns out to be useful.
> 
> Perhaps more realistically, there might be other uses of the hook in
> future that want to zero registers for different reasons, with their
> own rules about which registers can be zeroed.  In other words, the
> hook is providing a general facility that happens to be useful for
> -fzero-call-used-regs.  But again, we can deal with that if it ever
> happens.
> 
> So I agree this is the right call, especially for stage 4.
> 
>> 3. This new assertion identified a bug in i386 implementation. Fix this bug 
>> in i386.
>> 
>> This patch is bootstrapped on both x86 and aarch64, no regression.
>> 
>> Okay for commit?
> 
> OK for the non-x86 bits.
> 
> Thanks,
> Richard
> 
>> thanks.
>> 
>> Qing
>> 
>> ===
>> From 2e5bc1b25a707c6a17afbf03da2a8bec5b03454d Mon Sep 17 00:00:00 2001
>> From: Qing Zhao 
>> Date: Fri, 18 Mar 2022 20:49:56 +
>> Subject: [PATCH] Add an assertion: the zeroed_hardregs set is a subset of all
>> call used regs.
>> 
>> We should make sure that the hard register set that is actually cleared by
>> the target hook zero_call_used_regs should be a subset of all call used
>> registers.
>> 
>> At the same time, update documentation for the target hook
>> TARGET_ZERO_CALL_USED_REGS.
>> 
>> This new assertion identified a bug in the i386 implemenation, which
>> incorrectly set the zeroed_hardregs for stack registers. Fixed this bug
>> in i386 implementation.
>> 
>> gcc/ChangeLog:
>> 
>> 2022-03-21  Qing Zhao  
>> 
>>  * config/i386/i386.cc (zero_all_st_registers): Return the value of
>>  num_of_st.
>>  (ix86_zero_call_used_regs): Update zeroed_hardregs set according to
>>  the return value of zero_all_st_registers.
>>  * doc/tm.texi: Update the documentation of TARGET_ZERO_CALL_USED_REGS.
>>  * function.cc (gen_call_used_regs_seq): Add an assertion.
>>  * target.def: Update the documentation of TARGET_ZERO_CALL_USED_REGS.
>> ---
>> gcc/config/i386/i386.cc | 27 ++-
>> gcc/doc/tm.texi |  7 +++
>> gcc/function.cc | 22 ++
>> gcc/target.def  |  7 +++
>> 4 files changed, 50 insertions(+), 13 deletions(-)
>> 
>> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
>> index 5a561966eb44..d84047a4bc1b 100644
>> --- a/gcc/config/i386/i386.cc
>> +++ b/gcc/config/i386/i386.cc
>> @@ -3753,16 +3753,17 @@ zero_all_vector_registers (HARD_REG_SET 
>> need_zeroed_hardregs)
>>needs to be cleared, the whole stack should be cleared.  However,
>>x87 stack registers that hold the return value should be excluded.
>>x87 returns in the top (two for complex values) register, so
>> -   num_of_st should be 7/6 when x87 returns, otherwise it will be 8.  */
>> +   num_of_st should be 7/6 when x87 returns, otherwise it will be 8.
>> +   return the value of num_of_st.  */
>> 
>> 
>> -static bool
>> +static int
>> zero_all_st_registers (HARD_REG_SET need_zeroed_hardregs)
>> {
>> 
>>   /* If the FPU is disabled, no need to zero all st registers.  */
>>   if (! (TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387))
>> -return false;
>> +return 0;
>> 
>>   unsigned int num_of_st = 0;
>>   for (unsigned int regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
>> @@ -3774,7 +3775,7 @@ zero_all_st_registers (HARD_REG_SET 
>> need_zeroed_hardregs)
>>   }
>> 
>>   if (num_of_st == 0)
>> -return false;
>> +return 0;
>> 
>>   bool return_with_x87 = false;
>>   return_with_x87 = (crtl->return_rtx
>> @@ -3802,7 +3803,7 @@ zero_all_st_registers (HARD_REG_SET 
>> need_zeroed_hardregs)
>>   insn = emit_insn (gen_rtx_SET (st_reg, st_reg));
>>   add_reg_note (insn, REG_DEAD, st_reg);
>> }
>> -  return true;
>> +  return num_of_st;
>> }
>> 
>> 
>> @@ -3851,7 +3852,7 @@ ix86_zero_call_used_regs (HARD_REG_SET 
>> need_zeroed_hardregs)
>> {
>>   HARD_REG_SET zeroed_hardregs;
>>   bool all_sse_zeroed = false;
>> -  bool all_st_zeroed = false;
>> +  int all_st_zeroed_num = 0;
>>   

[Bug tree-optimization/105129] New: missing -Wformat-overflow for %b and %B directives in C2X standard

[frolov.da at phystech dot edu via Gcc-bugs]

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

Bug ID: 105129
   Summary: missing -Wformat-overflow for %b and %B directives in
C2X standard
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frolov.da at phystech dot edu
  Target Milestone: ---

[Bug rtl-optimization/104771] '-fcompare-debug' failure w/ -mno-vsx -O1 -frename-registers

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #1 from Peter Bergner  ---
I am unable to recreate this, but I'm guessing it is the same bug as PR105041.

Re: [PATCH] c++: deduction for dependent class type of NTTP [PR105110]

[Jason Merrill via Gcc-patches]

On 3/30/22 17:51, Patrick Palka wrote:

Here deduction for the P/A pair V/a spuriously fails with

   types ‘A’ and ‘const A’ have incompatible cv-qualifiers

because the argument type is const, whereas the parameter type is
non-const.

Since the type of an NTTP is always cv-unqualified, it seems natural to
ignore cv-qualifiers on the argument type before attempting to unify the
two types.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?


OK.


PR c++/105110

gcc/cp/ChangeLog:

* pt.cc (unify) : Ignore cv-quals on
on the argument type of an NTTP before deducing from it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-class52.C: New test.
---
  gcc/cp/pt.cc |  5 +++--
  gcc/testsuite/g++.dg/cpp2a/nontype-class52.C | 13 +
  2 files changed, 16 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class52.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 1acb5990c5c..cdd75d3b6ac 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -24271,8 +24271,9 @@ unify (tree tparms, tree targs, tree parm, tree arg, 
int strict,
  && !(strict & UNIFY_ALLOW_INTEGER)
  && TEMPLATE_PARM_LEVEL (parm) <= TMPL_ARGS_DEPTH (targs))
{
- /* Deduce it from the non-type argument.  */
- tree atype = TREE_TYPE (arg);
+ /* Deduce it from the non-type argument.  As above, ignore
+top-level quals here too.  */
+ tree atype = cv_unqualified (TREE_TYPE (arg));
  RECUR_AND_CHECK_FAILURE (tparms, targs,
   tparm, atype,
   UNIFY_ALLOW_NONE, explain_p);
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class52.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class52.C
new file mode 100644
index 000..56163376afb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class52.C
@@ -0,0 +1,13 @@
+// PR c++/105110
+// { dg-do compile { target c++20 } }
+
+template struct A { };
+
+template struct B { };
+
+template V> void f(B);
+
+int main() {
+  constexpr A a;
+  f(B{});
+}

[Bug libstdc++/105128] source_location compile error for latest clang 15

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 52738 [details]
> gcc12-pr105128.patch
> 
> So like this untested patch?
> Can test it with gcc, but don't have a new enough clang around.

yes, it should work on clang.

Re: [PATCH] c-family: Tweak -Woverflow diagnostic

[Jason Merrill via Gcc-patches]

On 3/30/22 18:28, Marek Polacek wrote:

When g++ emits

warning: overflow in conversion from 'int' to 'char' changes value from '300' 
to '',''

for code like "char c = 300;" it might raise a few eyebrows.  With this
warning we're not interested in the ASCII representation of the char, only
the numerical value, so convert constants of type char to int.  It looks
like this conversion only needs to be done for char_type_node.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?  I'm also happy
to defer this to GCC 13.


OK for stage 1.


gcc/c-family/ChangeLog:

* c-warn.cc (warnings_for_convert_and_check): Convert constants of type
char to int.

gcc/testsuite/ChangeLog:

* c-c++-common/Wconversion-1.c: New test.
---
  gcc/c-family/c-warn.cc | 16 +++-
  gcc/testsuite/c-c++-common/Wconversion-1.c | 14 ++
  2 files changed, 25 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/c-c++-common/Wconversion-1.c

diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
index f24ac5d0539..cae89294aea 100644
--- a/gcc/c-family/c-warn.cc
+++ b/gcc/c-family/c-warn.cc
@@ -1404,8 +1404,14 @@ warnings_for_convert_and_check (location_t loc, tree 
type, tree expr,
  result = TREE_OPERAND (result, 1);
  
bool cst = TREE_CODE_CLASS (TREE_CODE (result)) == tcc_constant;

-
tree exprtype = TREE_TYPE (expr);
+  tree result_diag;
+  /* We're interested in the actual numerical value here, not its ASCII
+ representation.  */
+  if (cst && TYPE_MAIN_VARIANT (TREE_TYPE (result)) == char_type_node)
+result_diag = fold_convert (integer_type_node, result);
+  else
+result_diag = result;
  
if (TREE_CODE (expr) == INTEGER_CST

&& (TREE_CODE (type) == INTEGER_TYPE
@@ -1430,7 +1436,7 @@ warnings_for_convert_and_check (location_t loc, tree 
type, tree expr,
  "changes value from %qE to %qE")
 : G_("unsigned conversion from %qT to %qT "
  "changes value from %qE to %qE")),
-   exprtype, type, expr, result);
+   exprtype, type, expr, result_diag);
  else
warning_at (loc, OPT_Woverflow,
(TYPE_UNSIGNED (exprtype)
@@ -1449,7 +1455,7 @@ warnings_for_convert_and_check (location_t loc, tree 
type, tree expr,
warning_at (loc, OPT_Woverflow,
"overflow in conversion from %qT to %qT "
"changes value from %qE to %qE",
-   exprtype, type, expr, result);
+   exprtype, type, expr, result_diag);
  else
warning_at (loc, OPT_Woverflow,
"overflow in conversion from %qT to %qT "
@@ -1466,7 +1472,7 @@ warnings_for_convert_and_check (location_t loc, tree 
type, tree expr,
warning_at (loc, OPT_Woverflow,
"overflow in conversion from %qT to %qT "
"changes value from %qE to %qE",
-   exprtype, type, expr, result);
+   exprtype, type, expr, result_diag);
  else
warning_at (loc, OPT_Woverflow,
"overflow in conversion from %qT to %qT "
@@ -1483,7 +1489,7 @@ warnings_for_convert_and_check (location_t loc, tree 
type, tree expr,
warning_at (loc, OPT_Woverflow,
"overflow in conversion from %qT to %qT "
"changes value from %qE to %qE",
-   exprtype, type, expr, result);
+   exprtype, type, expr, result_diag);
else
warning_at (loc, OPT_Woverflow,
"overflow in conversion from %qT to %qT "
diff --git a/gcc/testsuite/c-c++-common/Wconversion-1.c 
b/gcc/testsuite/c-c++-common/Wconversion-1.c
new file mode 100644
index 000..ed65918c70f
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Wconversion-1.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-Wconversion" } */
+
+typedef char T;
+
+void g()
+{
+  char c = 300; /* { dg-warning "conversion from .int. to .char. changes value from 
.300. to .44." } */
+  T t = 300; /* { dg-warning "conversion from .int. to .T. {aka .char.} changes 
value from .300. to .44." } */
+  signed char sc = 300; /* { dg-warning "conversion from .int. to .signed char. 
changes value from .300. to .44." } */
+  unsigned char uc = 300; /* { dg-warning "conversion from .int. to .unsigned char. 
changes value from .300. to .44." } */
+  unsigned char uc2 = 300u; /* { dg-warning "conversion from .unsigned int. to 
.unsigned char. changes value from .300. to .44." } */
+  char c2 = (double)1.0 + 200; /* { dg-warning "overflow in conversion from 
.double. to .char. changes value from .2.01e\\+2. to .127." } */
+}

base-commit: b4e4b35f4ebe561826489bed971324efc99c5423

Re: [PATCH] c++: implicit guides should inherit class constraints [PR104873]

[Jason Merrill via Gcc-patches]

On 4/1/22 11:17, Patrick Palka wrote:

An implicit guide already inherits the (rewritten) constraints of the
constructor.  Thus it seems natural that the guide must also inherit
the constraints of the class template, since a constructor's constraints
might assume the class's constraints are satisfied, and therefore
checking these two sets of constraints "out of order" may result in hard
errors as in the first testcase below.



This patch makes implicit guides inherit the constraints of the class
template (even for unconstrained constructors, and even for the copy
deduction candidate).

In passing, this patch gives implicit guides a trailing return type
since that's how they're depicted in the standard (e.g.
[over.match.class.deduct]/6); this changes the order of substitution
into implicit guides in a probably negligible way, especially now that
they inherit the class constraints.

The parameter_mapping_equivalent_p change is to avoid an ICE in the last
testcase below (described within), reduced from a cmcstl2 testsuite ICE.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
the right approach?


I don't think so, given the testcases below.

Maybe fn_type_unification should check formation of the return type of a 
deduction guide before constraints?  In general, whichever order you do 
things in, it'll be wrong for some testcase or other.


The broader subject of constraints and deduction guides should be raised 
with CWG in general (https://github.com/cplusplus/CWG/issues/new/choose)



PR c++/104873

gcc/cp/ChangeLog:

* constraint.cc (parameter_mapping_equivalent_p): Relax assert
to expect equivalence not identity of template parameters.
* pt.cc (build_deduction_guide): Propagate the class's
constraints to the deduction guide.  Set TYPE_HAS_LATE_RETURN_TYPE
on the function type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-ctad5.C: New test.
* g++.dg/cpp2a/concepts-ctad6.C: New test.
* g++.dg/cpp2a/concepts-ctad6a.C: New test.
* g++.dg/cpp2a/concepts-ctad7.C: New test.
---
  gcc/cp/constraint.cc |  2 +-
  gcc/cp/pt.cc | 26 ++
  gcc/testsuite/g++.dg/cpp2a/concepts-ctad5.C  | 29 
  gcc/testsuite/g++.dg/cpp2a/concepts-ctad6.C  | 19 +
  gcc/testsuite/g++.dg/cpp2a/concepts-ctad6a.C | 19 +
  gcc/testsuite/g++.dg/cpp2a/concepts-ctad7.C  | 26 ++
  6 files changed, 120 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-ctad5.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-ctad6.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-ctad6a.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-ctad7.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 94f6222b436..6cbb182dda2 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -604,7 +604,7 @@ parameter_mapping_equivalent_p (tree t1, tree t2)
tree map2 = ATOMIC_CONSTR_MAP (t2);
while (map1 && map2)
  {
-  gcc_checking_assert (TREE_VALUE (map1) == TREE_VALUE (map2));
+  gcc_checking_assert (cp_tree_equal (TREE_VALUE (map1), TREE_VALUE 
(map2)));
tree arg1 = TREE_PURPOSE (map1);
tree arg2 = TREE_PURPOSE (map2);
if (!template_args_equal (arg1, arg2))
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 75ed9a34018..966e6d90d3a 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -29261,6 +29261,10 @@ build_deduction_guide (tree type, tree ctor, tree 
outer_args, tsubst_flags_t com
/* Discard the 'this' parameter.  */
fparms = FUNCTION_ARG_CHAIN (ctor);
fargs = TREE_CHAIN (DECL_ARGUMENTS (ctor));
+  /* The guide's constraints consist of the class template's constraints
+followed by the constructor's rewritten constraints.  We start
+with the constructor's constraints (since we need to rewrite them),
+and prepend the class template's constraints later.  */
ci = get_constraints (ctor);
loc = DECL_SOURCE_LOCATION (ctor);
explicit_p = DECL_NONCONVERTING_P (ctor);
@@ -29362,6 +29366,27 @@ build_deduction_guide (tree type, tree ctor, tree 
outer_args, tsubst_flags_t com
return error_mark_node;
  }
  
+  /* Prepend the class template's constraints to the constructor's rewritten

+ constraints (if any).  */
+  if (tree class_ci = get_constraints (CLASSTYPE_TI_TEMPLATE (type)))
+{
+  if (outer_args)
+   {
+ /* FIXME: As above.  */
+ ++processing_template_decl;
+ class_ci = tsubst_constraint_info (class_ci, outer_args,
+complain, ctor);
+ --processing_template_decl;
+   }
+  if (ci)
+   ci = build_constraints (combine_constraint_expressions
+   (CI_TEMPLATE_REQS (class_ci),
+

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #36 from Jakub Jelinek  ---
That patch is certainly unacceptable, not only because it affects non-Windows
too, but even on Windows it will unnecessarily pessimize e.g. accesses to data
sections or heap that can be aligned.
If the Windows ABI doesn't align stack or not as much as gcc assumes, then a
fix would ensure only automatic vars on Windows are accessed always using
unaligned vector instructions provided dynamic stack realignment is not an
option.

[Bug libstdc++/105128] source_location compile error for latest clang 15

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 52738
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52738=edit
gcc12-pr105128.patch

So like this untested patch?
Can test it with gcc, but don't have a new enough clang around.

Re: [PATCH 2/4] Make vsx_splat__reg use correct insn attributes, PR target/99293

[Segher Boessenkool]

On Wed, Mar 30, 2022 at 06:41:59PM -0400, Michael Meissner wrote:
> On Mon, Mar 28, 2022 at 03:28:39PM -0500, Segher Boessenkool wrote:
> > On Mon, Mar 28, 2022 at 12:27:05PM -0400, Michael Meissner wrote:
> > > In looking at PR target/99293, I noticed that the code in the insn
> > > vsx_splat__reg used "vecmove" as the "type" insn attribute when the
> > > "mtvsrdd" is generated.  It should use "mfvsr".  I also added a "p9v" isa
> > > attribute for that alternative.
> > 
> > s/mfvsr/mtvsr/
> > 
> > But, mtvsrd and mtvsrdd have very different scheduling properties (like,
> > on p10 it is 1 cycle vs. 3 cycles).
> 
> I must admit, I assumed vecmove was a stand-in for XXMR (i.e. XXLOR).

That is "veclogical".  I don't think there is any core where this is
optimised specially?

> Since
> its use is used for other cases (mtvsrdd, xxsel/vsel, x{s,v}abs*, x{s,v}nabs*,
> xsiexpq*), it is probably better to just let things lie, and perhaps relook at
> it in the GCC 13 time frame.

Yes, we need to make better categories.  The problem is to come up with
something that is close enough to what the relevant cores actually do,
but in such a way that we do not end up with gazillions of nonsensical
separate instruction types.

What we care about most for p9 and p10 vector insns is whether something
is a 3-cycle op or not.  But this differs per core, and in ways that
are a little ad-hoc (looked at from far away anyway).

For the integer insns we ended up with extra attributes (not just
"type"), which is both compact and expressive.  We should try to do
something like that for vector ops as well.  We now have both p9 an
p10, with two implementations it should be clearer what a good direction
to take will be here.

> > Also, there are two insn patterns for mtvsrdd, and you are only touching
> > one here.
> 
> I think you meant that comment about the third patch (to vsx_extract_)
> and not to this patch (to vsx_splat__reg) where there are only two
> alternatives (the first being xxpermdi and the second being mtvsrdd).

I mean vsx_concat_ and vsx_splat__reg.  Both have mtvsrdd
(both as alternative 1), but you only update the "type" of the latter
here.

> > > --- a/gcc/config/rs6000/vsx.md
> > > +++ b/gcc/config/rs6000/vsx.md
> > > @@ -4580,7 +4580,8 @@ (define_insn "vsx_splat__reg"
> > >"@
> > > xxpermdi %x0,%x1,%x1,0
> > > mtvsrdd %x0,%1,%1"
> > > -  [(set_attr "type" "vecperm,vecmove")])
> > > +  [(set_attr "type" "vecperm,mtvsr")
> > > +   (set_attr "isa" "*,p9v")])
> > 
> > "we" requires "p9v".  Please do a full conversion when getting rid of
> > this?  That includes requiring TARGET_POWERPC64 for it (not -m64 as its
> > documentation says; the existing implementation of "we" is correct).
> 
> That is more complex, and likely it should be a GCC 13 thing.

Yes.

> Off the top of
> my head, we would need a new "isa" variant (p9v64) that combines p9v and
> 64-bit.

Not at all no.  Things that *use* the "isa" attribute can use other
attributes as well, if they want.  The reason we have "p9v" is because
it is so common that a shorthand helps (and *all* p9 vector insns need
either it or separate stuff).

> Originally, I had changed the "we" to "wa", but then I realized it
> wouldn't work for 32-bit, but I left in setting the alternative.

Yeah, when I got rid of many of the w* things I left mostly the harder
ones for later.  Sorry!


Segher

Re: [PATCH] arm64/io: Remind compiler that there is a memory side effect

[Mark Rutland via Gcc]

Hi Jeremy,

Thanks for raising this.

On Fri, Apr 01, 2022 at 11:44:06AM -0500, Jeremy Linton wrote:
> The relaxed variants of read/write macros are only declared
> as `asm volatile()` which forces the compiler to generate the
> instruction in the code path as intended. The only problem
> is that it doesn't also tell the compiler that there may
> be memory side effects. Meaning that if a function is comprised
> entirely of relaxed io operations, the compiler may think that
> it only has register side effects and doesn't need to be called.

As I mentioned on a private mail, I don't think that reasoning above is
correct, and I think this is a miscompilation (i.e. a compiler bug).

The important thing is that any `asm volatile` may have a side effects
generally outside of memory or GPRs, and whether the assembly contains a memory
load/store is immaterial. We should not need to add a memory clobber in order
to retain the volatile semantic.

See:

  https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile

... and consider the x86 example that reads rdtsc, or an arm64 sequence like:

| void do_sysreg_thing(void)
| {
|   unsigned long tmp;
|   
|   tmp = read_sysreg(some_reg);
|   tmp |= SOME_BIT;
|   write_sysreg(some_reg);
| }

... where there's no memory that we should need to hazard against.

This patch might workaround the issue, but I don't believe it is a correct fix.

> For an example function look at bcmgenet_enable_dma(), before the
> relaxed variants were removed. When built with gcc12 the code
> contains the asm blocks as expected, but then the function is
> never called.

So it sounds like this is a regression in GCC 12, which IIUC isn't released yet
per:

  https://gcc.gnu.org/gcc-12/changes.html

... which says:

| Note: GCC 12 has not been released yet

Surely we can fix it prior to release?

Thanks,
Mark.

> 
> Signed-off-by: Jeremy Linton 
> ---
>  arch/arm64/include/asm/io.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 7fd836bea7eb..3cceda7948a0 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -24,25 +24,25 @@
>  #define __raw_writeb __raw_writeb
>  static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
>  {
> - asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
> + asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
>  }
>  
>  #define __raw_writew __raw_writew
>  static inline void __raw_writew(u16 val, volatile void __iomem *addr)
>  {
> - asm volatile("strh %w0, [%1]" : : "rZ" (val), "r" (addr));
> + asm volatile("strh %w0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
>  }
>  
>  #define __raw_writel __raw_writel
>  static __always_inline void __raw_writel(u32 val, volatile void __iomem 
> *addr)
>  {
> - asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr));
> + asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
>  }
>  
>  #define __raw_writeq __raw_writeq
>  static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
>  {
> - asm volatile("str %x0, [%1]" : : "rZ" (val), "r" (addr));
> + asm volatile("str %x0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
>  }
>  
>  #define __raw_readb __raw_readb
> -- 
> 2.35.1
> 

[PATCH] Replace UNSPEC with RTL code for extendditi2.

[Michael Meissner via Gcc-patches]

eplace UNSPEC with RTL code for extendditi2.

When I submitted my patch on March 12th for extendditi2, Segher wished I
had removed the use of the UNSPEC for the vextsd2q instruction.  This
patch rewrites extendditi2_vector to use VEC_SELECT rather than UNSPEC.

I have built a power10 little endian toolchain, power9 little endian toolchain,
and a power8 big endian toolchain.  There were no regressions with this
change.  Is it ok to commit to the master branch?  I don't see the need to back
port the change, but I can certainly do so if desired.

2022-03-31   Michael Meissner  

gcc/
* config/rs6000/vsx.md (UNSPEC_EXTENDDITI2): Delete.
(extendditi2_vector): Rewrite to use VEC_SELECT as a
define_expand.
(extendditi2_vector2): New insn.
---
 gcc/config/rs6000/vsx.md | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index a1a1ce95195..c091e5e2f47 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -358,7 +358,6 @@ (define_c_enum "unspec"
UNSPEC_VSX_FIRST_MISMATCH_EOS_INDEX
UNSPEC_XXGENPCV
UNSPEC_MTVSBM
-   UNSPEC_EXTENDDITI2
UNSPEC_VCNTMB
UNSPEC_VEXPAND
UNSPEC_VEXTRACT
@@ -5083,10 +5082,25 @@ (define_insn_and_split "extendditi2"
(set_attr "type" "shift,load,vecmove,vecperm,load")])
 
 ;; Sign extend 64-bit value in TI reg, word 1, to 128-bit value in TI reg
-(define_insn "extendditi2_vector"
+(define_expand "extendditi2_vector"
+  [(use (match_operand:TI 0 "gpc_reg_operand"))
+   (use (match_operand:TI 1 "gpc_reg_operand"))]
+  "TARGET_POWER10"
+{
+  rtx dest = operands[0];
+  rtx src_v2di = gen_lowpart (V2DImode, operands[1]);
+  rtx element = GEN_INT (VECTOR_ELEMENT_SCALAR_64BIT);
+
+  emit_insn (gen_extendditi2_vector2 (dest, src_v2di, element));
+  DONE;
+})
+
+(define_insn "extendditi2_vector2"
   [(set (match_operand:TI 0 "gpc_reg_operand" "=v")
-   (unspec:TI [(match_operand:TI 1 "gpc_reg_operand" "v")]
-UNSPEC_EXTENDDITI2))]
+   (sign_extend:TI
+(vec_select:DI
+ (match_operand:V2DI 1 "gpc_reg_operand" "v")
+ (parallel [(match_operand 2 "vsx_scalar_64bit" "wD")]]
   "TARGET_POWER10"
   "vextsd2q %0,%1"
   [(set_attr "type" "vecexts")])
-- 
2.35.1


-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

[PATCH] arm64/io: Remind compiler that there is a memory side effect

[Jeremy Linton via Gcc]

The relaxed variants of read/write macros are only declared
as `asm volatile()` which forces the compiler to generate the
instruction in the code path as intended. The only problem
is that it doesn't also tell the compiler that there may
be memory side effects. Meaning that if a function is comprised
entirely of relaxed io operations, the compiler may think that
it only has register side effects and doesn't need to be called.

For an example function look at bcmgenet_enable_dma(), before the
relaxed variants were removed. When built with gcc12 the code
contains the asm blocks as expected, but then the function is
never called.

Signed-off-by: Jeremy Linton 
---
 arch/arm64/include/asm/io.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 7fd836bea7eb..3cceda7948a0 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -24,25 +24,25 @@
 #define __raw_writeb __raw_writeb
 static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
 {
-   asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
+   asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
 }
 
 #define __raw_writew __raw_writew
 static inline void __raw_writew(u16 val, volatile void __iomem *addr)
 {
-   asm volatile("strh %w0, [%1]" : : "rZ" (val), "r" (addr));
+   asm volatile("strh %w0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
 }
 
 #define __raw_writel __raw_writel
 static __always_inline void __raw_writel(u32 val, volatile void __iomem *addr)
 {
-   asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr));
+   asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
 }
 
 #define __raw_writeq __raw_writeq
 static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
 {
-   asm volatile("str %x0, [%1]" : : "rZ" (val), "r" (addr));
+   asm volatile("str %x0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
 }
 
 #define __raw_readb __raw_readb
-- 
2.35.1

[wwwdocs PATCH] document zero-width field ABI changes on MIPS

[Xi Ruoyao via Gcc-patches]

Document PR102024 change (r12-7961 and 7962) for MIPS.  Ok for wwwdocs?

--

 htdocs/gcc-12/changes.html | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 4e1f6b0f..a2d8156f 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -50,6 +50,10 @@ a work-in-progress.
 (so there is a C++ ABI incompatibility, GCC 4.4 and earlier compatible
 with GCC 12 or later, incompatible with GCC 4.5 through GCC 11).
 RISC-V has changed the handling of these already starting with GCC 10.
+As the ABI requires, MIPS takes them into account handling function
+return values so there is a C++ ABI incompatibility with GCC 4.5
+through 11.  For function arguments on MIPS, refer to
+the MIPS specific entry.
 GCC 12 on the above targets will report such incompatibilities as
 warnings or other diagnostics unless -Wno-psabi is used.
   
@@ -549,7 +553,18 @@ a work-in-progress.
   
 
 
-
+MIPS
+
+  The ABI passing arguments
+  containing zero-width fields (for example, C/C++ zero-width
+  bit-fields, GNU C/C++ zero-length arrays, and GNU C empty structs)
+  has changed.  Now a zero-width field will not prevent an aligned
+  64-bit floating-point field next to it from being passed through
+  FPR.  This is compatible with LLVM, but incompatible with previous
+  GCC releases. GCC 12 on MIPS will report such incompatibilities as
+  an inform unless -Wno-psabi is used.
+  
+
 
 
 
-- 
2.35.1

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[steve at sk2 dot org via Gcc-bugs]

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

Stephen Kitt  changed:

   What|Removed |Added

 CC||steve at sk2 dot org

--- Comment #35 from Stephen Kitt  ---
Created attachment 52737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52737=edit
Use unaligned VMOV instructions (for Windows targets)

The reason I didn't submit the Debian patch is that it unconditionally replaces
V...{U,A} with V...U instructions. That's fine when we know the target needs
something like that, which is the case when we're building a Windows
cross-compiler; but I don't think it's suitable for general use as-is. It would
need a build-time conditional at the very least.

Anyway, I'll add it as an attachment here; I'll try to find time to make it
generally applicable. I haven't filed copyright assignment paperwork for me
personally; if the patch needs it, consider it submitted by sk...@redhat.com
under the corporate copyright assignment agreement.

Re: [committed] jit: further doc fixes

[Eric Gallager via Gcc-patches]

On Fri, Apr 1, 2022 at 9:28 AM David Malcolm via Gcc-patches
 wrote:
>
> Further jit doc fixes, which fix links to
> gcc_jit_function_type_get_param_type and gcc_jit_struct_get_field.
>
> I also regenerated libgccjit.texi (not included in the diff below).
>
> Tested with "make html" and with a bootstrap.

 Could you test with `make pdf` and `make dvi` too, to see if this fixes 102824?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824

> Committed to trunk as r12-7959-g1a172da8a3f362.
>
> gcc/jit/ChangeLog:
> * docs/topics/expressions.rst: Fix formatting.
> * docs/topics/types.rst: Likewise.
> * docs/_build/texinfo/libgccjit.texi: Regenerate
>
> Signed-off-by: David Malcolm 
> ---
>  gcc/jit/docs/topics/expressions.rst | 8 
>  gcc/jit/docs/topics/types.rst   | 6 +++---
>  2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/gcc/jit/docs/topics/expressions.rst 
> b/gcc/jit/docs/topics/expressions.rst
> index 9267b6d2ad6..d51264af73f 100644
> --- a/gcc/jit/docs/topics/expressions.rst
> +++ b/gcc/jit/docs/topics/expressions.rst
> @@ -24,7 +24,7 @@ Rvalues
>  ---
>  .. type:: gcc_jit_rvalue
>
> -A :c:type:`gcc_jit_rvalue *` is an expression that can be computed.
> +A :c:type:`gcc_jit_rvalue` is an expression that can be computed.
>
>  It can be simple, e.g.:
>
> @@ -602,7 +602,7 @@ Function calls
>gcc_jit_rvalue_set_bool_require_tail_call (gcc_jit_rvalue 
> *call,\
>   int 
> require_tail_call)
>
> -   Given an :c:type:`gcc_jit_rvalue *` for a call created through
> +   Given an :c:type:`gcc_jit_rvalue` for a call created through
> :c:func:`gcc_jit_context_new_call` or
> :c:func:`gcc_jit_context_new_call_through_ptr`, mark/clear the
> call as needing tail-call optimization.  The optimizer will
> @@ -721,8 +721,8 @@ where the rvalue is computed by reading from the storage 
> area.
>
>#ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_tls_model
>
> -.. function:: void
> -  gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,
> +.. function:: void\
> +  gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,\
> const char *section_name)
>
> Set the link section of a variable.
> diff --git a/gcc/jit/docs/topics/types.rst b/gcc/jit/docs/topics/types.rst
> index 9779ad26b6f..c2082c0ef3e 100644
> --- a/gcc/jit/docs/topics/types.rst
> +++ b/gcc/jit/docs/topics/types.rst
> @@ -192,7 +192,7 @@ A compound type analagous to a C `struct`.
>
>  A field within a :c:type:`gcc_jit_struct`.
>
> -You can model C `struct` types by creating :c:type:`gcc_jit_struct *` and
> +You can model C `struct` types by creating :c:type:`gcc_jit_struct` and
>  :c:type:`gcc_jit_field` instances, in either order:
>
>  * by creating the fields, then the structure.  For example, to model:
> @@ -375,7 +375,7 @@ Reflection API
>   Given a function type, return its number of parameters.
>
>  .. function::  gcc_jit_type *\
> -   gcc_jit_function_type_get_param_type (gcc_jit_function_type 
> *function_type,
> +   gcc_jit_function_type_get_param_type (gcc_jit_function_type 
> *function_type,\
>   size_t index)
>
>   Given a function type, return the type of the specified parameter.
> @@ -417,7 +417,7 @@ Reflection API
>   alignment qualifiers.
>
>  .. function::  gcc_jit_field *\
> -   gcc_jit_struct_get_field (gcc_jit_struct *struct_type,
> +   gcc_jit_struct_get_field (gcc_jit_struct *struct_type,\
>   size_t index)
>
>   Get a struct field by index.
> --
> 2.26.3
>

Re: [PATCH][libgomp, testsuite, nvptx] Limit recursion in declare_target-{1,2}.f90

[Tom de Vries via Gcc-patches]

On 4/1/22 17:38, Jakub Jelinek wrote:

On Fri, Apr 01, 2022 at 05:34:50PM +0200, Tom de Vries wrote:

Do you perhaps have an idea why it's failing?


Because you call on_device_arch_nvptx () outside of
!$omp target region, so unless the host device is NVPTX,
it will not be true.



That bit does works because on_device_arch_nvptx calls on_device_arch 
which contains the omp target bit:

...
static int
on_device_arch (int d)
{
  int d_cur;
  #pragma omp target map(from:d_cur)
  d_cur = device_arch ();

  return d_cur == d;
}

int
on_device_arch_nvptx ()
{
  return on_device_arch (GOMP_DEVICE_NVIDIA_PTX);
}
...

So I realized that I didn't do a good job of specifying the problem I 
encountered, and went looking at it, at which point I realized the error 
message had changed, and knew how to fix it ... So, my apologies, some 
confusion on my part.


Anyway, attached patch avoids any nvptx-related tcl directives (just for 
once test-case for now).  To me, this seems the most robust solution.


It this approach acceptable?

Thanks,
- Tom
[libgomp/testsuite] Fix libgomp.fortran/examples-4/declare_target-1.f90

---
 .../examples-4/declare_target-1.f90| 31 +-
 .../libgomp.fortran/examples-4/on_device_arch.c|  3 +++
 2 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90 b/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90
index 03c5c53ed67..acded20f756 100644
--- a/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90
+++ b/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90
@@ -1,16 +1,6 @@
 ! { dg-do run }
-! { dg-additional-options "-cpp" }
-! Reduced from 25 to 23, otherwise execution runs out of thread stack on
-! Nvidia Titan V.
-! Reduced from 23 to 22, otherwise execution runs out of thread stack on
-! Nvidia T400 (2GB variant), when run with GOMP_NVPTX_JIT=-O0.
-! Reduced from 22 to 20, otherwise execution runs out of thread stack on
-! Nvidia RTX A2000 (6GB variant), when run with GOMP_NVPTX_JIT=-O0.
-! { dg-additional-options "-DREC_DEPTH=20" { target { offload_target_nvptx } } } */
-
-#ifndef REC_DEPTH
-#define REC_DEPTH 25
-#endif
+! { dg-additional-sources on_device_arch.c }
+! { dg-prune-output "command-line option '-fintrinsic-modules-path=.*' is valid for Fortran but not for C" }
 
 module e_53_1_mod
   integer :: THRESHOLD = 20
@@ -38,6 +28,23 @@ end module
 
 program e_53_1
   use e_53_1_mod, only : fib, fib_wrapper
+  integer :: REC_DEPTH = 25
+
+  interface
+integer function on_device_arch_nvptx() bind(C)
+end function on_device_arch_nvptx
+  end interface
+
+  if (on_device_arch_nvptx () /= 0) then
+ ! Reduced from 25 to 23, otherwise execution runs out of thread stack on
+ ! Nvidia Titan V.
+ ! Reduced from 23 to 22, otherwise execution runs out of thread stack on
+ ! Nvidia T400 (2GB variant), when run with GOMP_NVPTX_JIT=-O0.
+ ! Reduced from 22 to 20, otherwise execution runs out of thread stack on
+ ! Nvidia RTX A2000 (6GB variant), when run with GOMP_NVPTX_JIT=-O0.
+ REC_DEPTH = 20
+  end if
+
   if (fib (15) /= fib_wrapper (15)) stop 1
   if (fib (REC_DEPTH) /= fib_wrapper (REC_DEPTH)) stop 2
 end program
diff --git a/libgomp/testsuite/libgomp.fortran/examples-4/on_device_arch.c b/libgomp/testsuite/libgomp.fortran/examples-4/on_device_arch.c
new file mode 100644
index 000..f8bef19e021
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/examples-4/on_device_arch.c
@@ -0,0 +1,3 @@
+/* Auxiliar file.  */
+/* { dg-do compile  { target skip-all-targets } } */
+#include "../../libgomp.c-c++-common/on_device_arch.h"

Re: MC/DC support for gcov?

[Martin Liška]

On 3/31/22 16:55, Sebastian Huber wrote:

Hello,

gcov supports currently branch coverage. Some projects require modified 
condition/decision coverage (MC/DC):

https://en.wikipedia.org/wiki/Modified_condition/decision_coverage

In general, 100% branch coverage does not imply 100% MC/DC coverage:

https://www.adacore.com/uploads_gems/Couverture_ERTS-2012.pdf

The paper contains a criterion under which 100% branch coverage implies 100% 
MC/DC coverage:

"Theorem 1 If the BDD of a decision D is a tree (with
only one path from the root to any condition node),
then BDD edge coverage implies MCDC"

The BDD is the Binary Decision Diagram. I have no idea how the compiler and the 
coverage supports works in GCC. Is this BDD available for the coverage support 
and could the coverage support check for this property and then for example add 
it to the gcov information? If the BDD of a decision is not a tree, then we 
would have to record which paths through the BDD are covered to get the MC/DC 
coverage. This would require extra storage and instrumentation. According to 
the paper, the BDD is usually a tree in real world applications. Does this 
sound like feasible feature for GCC? Could it be even a GSoC project?

Kind regards,
 Sebastian



Hi.

There's a patch review for the feature:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592065.html

Martin

[Bug libstdc++/105128] source_location compile error for latest clang 15

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
Created attachment 52736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52736=edit
Modified source_location header that works on both gcc and clang

It looks like clang requires __impl to be defined before
__builtin_source_location() call. Just change the location for where it should
be defined and it works.

Can we fix it?

[Bug regression/105126] Optimization regression gcc inserts not needed movsx when using switch statement

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-01
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with my r8-2897-g02e637d86f9ecb6d, will take a look.

Re: [PATCH][libgomp, testsuite, nvptx] Limit recursion in declare_target-{1,2}.f90

[Jakub Jelinek via Gcc-patches]

On Fri, Apr 01, 2022 at 05:34:50PM +0200, Tom de Vries wrote:
> Do you perhaps have an idea why it's failing?

Because you call on_device_arch_nvptx () outside of
!$omp target region, so unless the host device is NVPTX,
it will not be true.

> +program e_53_1
> +  use e_53_1_mod, only : fib, fib_wrapper
> +  integer :: REC_DEPTH = 25
> +
> +  interface
> +integer function on_device_arch_nvptx() bind(C)
> +end function on_device_arch_nvptx
> +  end interface
> +
> +  if (on_device_arch_nvptx () /= 0) then
> + ! Reduced from 25 to 23, otherwise execution runs out of thread stack on
> + ! Nvidia Titan V.
> + ! Reduced from 23 to 22, otherwise execution runs out of thread stack on
> + ! Nvidia T400 (2GB variant), when run with GOMP_NVPTX_JIT=-O0.
> + ! Reduced from 22 to 20, otherwise execution runs out of thread stack on
> + ! Nvidia RTX A2000 (6GB variant), when run with GOMP_NVPTX_JIT=-O0.
> + REC_DEPTH = 20
> +  end if
> +
> +  if (fib (15) /= fib_wrapper (15)) stop 1
> +  if (fib (REC_DEPTH) /= fib_wrapper (REC_DEPTH)) stop 2
> +end program

Jakub

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

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

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

--- Comment #34 from Eric Botcazou  ---
> It's unfortunate that the best and most common advice for using avx2 with
> gcc/mingw is to use a patched compiler. Might it be possible to accept
> Debian's patch upstream?

Sure, but they need to submit it first, we cannot do it for them.

Re: [PATCH][libgomp, testsuite, nvptx] Limit recursion in declare_target-{1,2}.f90

[Tom de Vries via Gcc-patches]

On 4/1/22 14:28, Thomas Schwinge wrote:

Hi Tom!

On 2022-04-01T13:24:40+0200, Tom de Vries  wrote:

When running testcases libgomp.fortran/examples-4/declare_target-{1,2}.f90 on
an RTX A2000 (sm_86) with driver 510.60.02 and with GOMP_NVPTX_JIT=-O0 I run
into:
...
FAIL: libgomp.fortran/examples-4/declare_target-1.f90 -O0 \
   -DGOMP_NVPTX_JIT=-O0 execution test
FAIL: libgomp.fortran/examples-4/declare_target-2.f90 -O0 \
   -DGOMP_NVPTX_JIT=-O0 execution test
...

Fix this by further limiting recursion depth in the test-cases for nvptx.

Furthermore, make the recursion depth limiting nvptx-specific.


Careful:


--- a/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90
+++ b/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90
@@ -1,4 +1,16 @@
  ! { dg-do run }
+! { dg-additional-options "-cpp" }
+! Reduced from 25 to 23, otherwise execution runs out of thread stack on
+! Nvidia Titan V.
+! Reduced from 23 to 22, otherwise execution runs out of thread stack on
+! Nvidia T400 (2GB variant), when run with GOMP_NVPTX_JIT=-O0.
+! Reduced from 22 to 20, otherwise execution runs out of thread stack on
+! Nvidia RTX A2000 (6GB variant), when run with GOMP_NVPTX_JIT=-O0.
+! { dg-additional-options "-DREC_DEPTH=20" { target { offload_target_nvptx } } 
} */


'offload_target_nvptx' doesn't mean that offloading execution is done on
nvptx, but rather that we're "*compiling* for offload target nvptx"
(emphasis mine).  That means, with such a change we're now getting
different behavior in a system with an AMD GPU, when using a toolchain
that only has GCN offloading configured vs. a toolchain that has GCN and
nvptx offloading configured.  This isn't going to cause any real
problems, of course, but it's confusing, and a bad example of
'offload_target_nvptx'.

'offload_device_nvptx' ought to work: "using nvptx offload device".



Thanks for pointing that out.

I tried to understand this multiple offloading configuration a bit, and 
came up with the following mental model: it's possible to have a host 
with say an nvptx and amd offloading device, and then configure and 
build a toolchain that can generate a single executable that can offload 
to either device, depending on the value of appropriate openacc/openmp 
environment variables.


So, in principle the libgomp testsuite could have a mode in which it 
does that: run the same executable twice, once for each offloading 
device.  In that case, even using offload_device_nvptx would not be 
accurate enough, and we'd need to test for offload device type at 
runtime, as used to be done in 
libgomp/testsuite/libgomp.fortran/task-detach-6.f90.


I've tried to copy that setup to 
libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90, but 
that doesn't seem to work anymore.  I've also tried copying that 
test-case to 
libgomp/testsuite/libgomp.fortran/copy-of-declare_target-1.f90 to rule 
out any subdir-related problems, but no luck there either.


Attached is that copy approach, could you try it out and see if it works 
for you?


Do you perhaps have an idea why it's failing?

I can make a patch using offload_device_nvptx, but I'd prefer to 
understand first why the approach above isn't working.


Thanks,
- Tom[libgomp/testsuite] Add libgomp.fortran/copy-of-declare_target-1.f90

---
 .../libgomp.fortran/copy-of-declare_target-1.f90   | 49 ++
 1 file changed, 49 insertions(+)

diff --git a/libgomp/testsuite/libgomp.fortran/copy-of-declare_target-1.f90 b/libgomp/testsuite/libgomp.fortran/copy-of-declare_target-1.f90
new file mode 100644
index 000..6dcf5312070
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/copy-of-declare_target-1.f90
@@ -0,0 +1,49 @@
+! { dg-do run }
+! { dg-additional-sources on_device_arch.c }
+
+module e_53_1_mod
+  integer :: THRESHOLD = 20
+contains
+  integer recursive function fib (n) result (f)
+!$omp declare target
+integer :: n
+if (n <= 0) then
+  f = 0
+else if (n == 1) then
+  f = 1
+else
+  f = fib (n - 1) + fib (n - 2)
+end if
+  end function
+
+  integer function fib_wrapper (n)
+integer :: x
+!$omp target map(to: n) map(from: x) if(n > THRESHOLD)
+  x = fib (n)
+!$omp end target
+fib_wrapper = x
+  end function
+end module
+
+program e_53_1
+  use e_53_1_mod, only : fib, fib_wrapper
+  integer :: REC_DEPTH = 25
+
+  interface
+integer function on_device_arch_nvptx() bind(C)
+end function on_device_arch_nvptx
+  end interface
+
+  if (on_device_arch_nvptx () /= 0) then
+ ! Reduced from 25 to 23, otherwise execution runs out of thread stack on
+ ! Nvidia Titan V.
+ ! Reduced from 23 to 22, otherwise execution runs out of thread stack on
+ ! Nvidia T400 (2GB variant), when run with GOMP_NVPTX_JIT=-O0.
+ ! Reduced from 22 to 20, otherwise execution runs out of thread stack on
+ ! Nvidia RTX A2000 (6GB variant), when run with GOMP_NVPTX_JIT=-O0.
+ REC_DEPTH = 20
+  end if
+
+  if (fib 

[Bug libstdc++/105128] New: source_location compile error for clang

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 105128
   Summary: source_location compile error for clang
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

It looks like clang just added source_location implementation but the built-in
looks different. Unfortunately, libcxx does not implement this either at this
point. However, the testsuite probably tells how clang implements this.

https://github.com/llvm/llvm-project/blob/d61487490022aaacc34249475fac3e208c7d767e/clang/test/CodeGenCXX/builtin-source-location.cpp

#include

int main()
{
std::source_location::current();
}

clang++ -o sourcelocation sourcelocation.cc -Ofast -std=c++2b -s -flto=thin
-fuse-ld=lld
In file included from sourcelocation.cc:1:
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../include/c++/12.0.1/source_location:46:41:
error: 'std::source_location::__impl' was not found; it must be defined before
'__builtin_source_location' is called
using __builtin_ret_type = decltype(__builtin_source_location());
^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../include/c++/12.0.1/source_location:52:13:
error: unknown type name '__builtin_ret_type'
current(__builtin_ret_type __p = __builtin_source_location()) noexcept
^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../include/c++/12.0.1/source_location:52:32:
error: cannot initialize a parameter of type 'int' with an rvalue of type
'const std::source_location::__impl *'
current(__builtin_ret_type __p = __builtin_source_location()) noexcept
   ^ ~~~
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../include/c++/12.0.1/source_location:52:32:
note: passing argument to parameter '__p' here
3 errors generated.

[Bug c++/105127] New: Search Path not working on Cygwin

[samuel.d.darwin at gmail dot com via Gcc-bugs]

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

Bug ID: 105127
   Summary: Search Path not working on Cygwin
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: samuel.d.darwin at gmail dot com
  Target Milestone: ---

Hi,

It appears that "Search Path" is not working as expected on the Cygwin
platform. Your feedback would be appreciated.

Notice on this page https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html it
says: By default, the preprocessor looks for header files included by the quote
form of the directive #include "file" first relative to the directory of the
current file, and then in a preconfigured list of standard system directories. 

However, during testing, g++ fails to include a file in the same directory. An
error such as this occurs:

"fatal error: zutil.h: No such file or directory | #include "zutil.h"
compilation terminated."

How can it be replicated?

The problem was discovered when running CI tests
https://github.com/boostorg/boost-ci . Notice the .appveyor.yml file contained
there. To run more Cygwin tests I forked that repository to
https://github.com/samd2/boost-ci/tree/feature/searchpath and added Visual
Studio 2019 and Visual Studio 2022 images. Appveyor's Visual Studio 2017 image
was ok. The problem appears on 2019 and 2022.

CI output at
https://ci.appveyor.com/project/sam-original/boost-ci/builds/43100905

> Which version of gcc? 

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/11/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.2.0/configure
--srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.2.0 --prefix=/usr
--exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--with-gcc-major-version-only --enable-shared --enable-shared-libgcc
--enable-static --enable-version-specific-runtime-libs --enable-bootstrap
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic --disable-bootstrap
--enable-languages=c,c++,fortran,lto,objc,obj-c++,jit --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath
--enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers
--with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
--enable-libstdcxx-filesystem-ts
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC) 
b2 --abbreviate-paths libs/boost-ci/test toolset=gcc cxxstd=11,14,1z   
address-model=64 link=shared,static variant=release -j3 

> What command failed?

Actually, g++ was called by another tools, b2 :
b2 --abbreviate-paths libs/boost-ci/test toolset=gcc cxxstd=11,14,1z   
address-model=64 link=shared,static variant=release -j3 

By adding the -d2 debugging flag to b2 it can be seen that the g++ command was:

g++ -std=c++14 -fvisibility-inlines-hidden -m64 -mthreads -O3
-finline-functions -Wno-inline -Wall -fvisibility=hidden  -DBOOST_ALL_NO_LIB=1
-DNDEBUG  -I"."  -c -o
"bin.v2\libs\boost-ci\test\gcc-11\rls\cxstd-14-iso\trgt-os-cygwn\thrd-mlt\vsblt-hdn\test.o"
"libs\boost-ci\test\test.cpp"

> What was the C++ source file contents? 

In this case the file test.cpp. It can be seen here:
https://github.com/boostorg/boost-ci/blob/master/test/test.cpp
It has the line "#include "test2.hpp"

> What was the exact error?

libs\boost-ci\test\test.cpp:18:10: fatal error: test2.hpp: No such file or
directory
   18 | #include "test2.hpp"
  |  ^

View the entire build here: 

https://ci.appveyor.com/project/sam-original/boost-ci/builds/43100905

Let me know if you need more info.  Thanks.

[PATCH 2/2] avr: Removed errant control characters

[Joel Holdsworth via Gcc-patches]

Signed-off-by: Joel Holdsworth 
---
 gcc/config/avr/avr-devices.cc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gcc/config/avr/avr-devices.cc b/gcc/config/avr/avr-devices.cc
index aa284217f50..ff6a5441b77 100644
--- a/gcc/config/avr/avr-devices.cc
+++ b/gcc/config/avr/avr-devices.cc
@@ -126,8 +126,6 @@ avr_mcu_types[] =
 };
 
 
-
-
 #ifndef IN_GEN_AVR_MMCU_TEXI
 
 static char*
-- 
2.35.GIT

[PATCH 1/2] avr: Added AVR-DA and DB MCU series

[Joel Holdsworth via Gcc-patches]

gcc/
* config/avr/avr-mcus.def: Add device definitions.
* doc/avr-mmcu.texi: Corresponding changes.
* gcc/config/avr/gen-avr-mmcu-texi.c: Added support for avr
  device prefix.
* gcc/config/avr/gen-avr-mmcu-specs.c: Prevent -mmcu=avr* flags
  from leaking into cc1.

Signed-off-by: Joel Holdsworth 
---
 gcc/config/avr/avr-mcus.def  | 22 ++
 gcc/config/avr/gen-avr-mmcu-specs.cc |  2 +-
 gcc/config/avr/gen-avr-mmcu-texi.cc  |  2 +-
 gcc/doc/avr-mmcu.texi|  6 +++---
 4 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/gcc/config/avr/avr-mcus.def b/gcc/config/avr/avr-mcus.def
index 1e12ab30170..fa5e6685227 100644
--- a/gcc/config/avr/avr-mcus.def
+++ b/gcc/config/avr/avr-mcus.def
@@ -306,6 +306,14 @@ AVR_MCU ("atxmega16c4",  ARCH_AVRXMEGA2, AVR_ISA_RMW,  
"__AVR_ATxmega16C4__"
 AVR_MCU ("atxmega32a4u", ARCH_AVRXMEGA2, AVR_ISA_RMW,  
"__AVR_ATxmega32A4U__", 0x2000, 0x0, 0x9000, 0)
 AVR_MCU ("atxmega32c4",  ARCH_AVRXMEGA2, AVR_ISA_RMW,  
"__AVR_ATxmega32C4__",  0x2000, 0x0, 0x9000, 0)
 AVR_MCU ("atxmega32e5",  ARCH_AVRXMEGA2, AVR_ISA_NONE, 
"__AVR_ATxmega32E5__",  0x2000, 0x0, 0x9000, 0)
+AVR_MCU ("avr64da28",ARCH_AVRXMEGA2, AVR_ISA_NONE, 
"__AVR_AVR64DA28__",0x6000, 0x0, 0x8000, 0x1)
+AVR_MCU ("avr64da32",ARCH_AVRXMEGA2, AVR_ISA_NONE, 
"__AVR_AVR64DA32__",0x6000, 0x0, 0x8000, 0x1)
+AVR_MCU ("avr64da48",ARCH_AVRXMEGA2, AVR_ISA_NONE, 
"__AVR_AVR64DA48__",0x6000, 0x0, 0x8000, 0x1)
+AVR_MCU ("avr64da64",ARCH_AVRXMEGA2, AVR_ISA_NONE, 
"__AVR_AVR64DA64__",0x6000, 0x0, 0x8000, 0x1)
+AVR_MCU ("avr64db28",ARCH_AVRXMEGA2, AVR_ISA_NONE, 
"__AVR_AVR64DB28__",0x6000, 0x0, 0x8000, 0x1)
+AVR_MCU ("avr64db32",ARCH_AVRXMEGA2, AVR_ISA_NONE, 
"__AVR_AVR64DB32__",0x6000, 0x0, 0x8000, 0x1)
+AVR_MCU ("avr64db48",ARCH_AVRXMEGA2, AVR_ISA_NONE, 
"__AVR_AVR64DB48__",0x6000, 0x0, 0x8000, 0x1)
+AVR_MCU ("avr64db64",ARCH_AVRXMEGA2, AVR_ISA_NONE, 
"__AVR_AVR64DB64__",0x6000, 0x0, 0x8000, 0x1)
 /* Xmega, Flash + RAM < 64K, flash visible in RAM address space */
 AVR_MCU ("avrxmega3",ARCH_AVRXMEGA3, AVR_ISA_NONE,  NULL,  
0x3f00, 0x0, 0x8000, 0)
 AVR_MCU ("attiny202",ARCH_AVRXMEGA3, AVR_ISA_RCALL, 
"__AVR_ATtiny202__",   0x3f80, 0x0, 0x800,  0x8000)
@@ -342,6 +350,12 @@ AVR_MCU ("atmega3208",   ARCH_AVRXMEGA3, AVR_ISA_NONE, 
 "__AVR_ATmega3208__"
 AVR_MCU ("atmega3209",   ARCH_AVRXMEGA3, AVR_ISA_NONE,  
"__AVR_ATmega3209__",  0x3800, 0x0, 0x8000, 0x4000)
 AVR_MCU ("atmega4808",   ARCH_AVRXMEGA3, AVR_ISA_NONE,  
"__AVR_ATmega4808__",  0x2800, 0x0, 0xc000, 0x4000)
 AVR_MCU ("atmega4809",   ARCH_AVRXMEGA3, AVR_ISA_NONE,  
"__AVR_ATmega4809__",  0x2800, 0x0, 0xc000, 0x4000)
+AVR_MCU ("avr32da28",ARCH_AVRXMEGA3, AVR_ISA_NONE,  
"__AVR_AVR32DA28__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32da32",ARCH_AVRXMEGA3, AVR_ISA_NONE,  
"__AVR_AVR32DA32__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32da48",ARCH_AVRXMEGA3, AVR_ISA_NONE,  
"__AVR_AVR32DA48__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32db28",ARCH_AVRXMEGA3, AVR_ISA_NONE,  
"__AVR_AVR32DB28__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32db32",ARCH_AVRXMEGA3, AVR_ISA_NONE,  
"__AVR_AVR32DB32__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32db48",ARCH_AVRXMEGA3, AVR_ISA_NONE,  
"__AVR_AVR32DB48__",   0x7000, 0x0, 0x8000, 0x8000)
 /* Xmega, 64K < Flash <= 128K, RAM <= 64K */
 AVR_MCU ("avrxmega4",ARCH_AVRXMEGA4, AVR_ISA_NONE, NULL,   
0x2000, 0x0, 0x11000, 0)
 AVR_MCU ("atxmega64a3",  ARCH_AVRXMEGA4, AVR_ISA_NONE, 
"__AVR_ATxmega64A3__",  0x2000, 0x0, 0x11000, 0)
@@ -352,6 +366,14 @@ AVR_MCU ("atxmega64b1",  ARCH_AVRXMEGA4, AVR_ISA_RMW,  
"__AVR_ATxmega64B1__"
 AVR_MCU ("atxmega64b3",  ARCH_AVRXMEGA4, AVR_ISA_RMW,  
"__AVR_ATxmega64B3__",  0x2000, 0x0, 0x11000, 0)
 AVR_MCU ("atxmega64c3",  ARCH_AVRXMEGA4, AVR_ISA_RMW,  
"__AVR_ATxmega64C3__",  0x2000, 0x0, 0x11000, 0)
 AVR_MCU ("atxmega64d4",  ARCH_AVRXMEGA4, AVR_ISA_NONE, 
"__AVR_ATxmega64D4__",  0x2000, 0x0, 0x11000, 0)
+AVR_MCU ("avr128da28",   ARCH_AVRXMEGA4, AVR_ISA_NONE, 
"__AVR_AVR128DA28__",   0x4000, 0x0, 0x8000,  0x2)
+AVR_MCU ("avr128da32",   ARCH_AVRXMEGA4, AVR_ISA_NONE, 
"__AVR_AVR128DA32__",   0x4000, 0x0, 0x8000,  0x2)
+AVR_MCU ("avr128da48",   ARCH_AVRXMEGA4, AVR_ISA_NONE, 
"__AVR_AVR128DA48__",   0x4000, 0x0, 0x8000,  0x2)
+AVR_MCU ("avr128da64",   ARCH_AVRXMEGA4, AVR_ISA_NONE, 
"__AVR_AVR128DA64__",   0x4000, 0x0, 0x8000,  0x2)
+AVR_MCU ("avr128db28",   ARCH_AVRXMEGA4, AVR_ISA_NONE, 
"__AVR_AVR128DB28__",   0x4000, 0x0, 0x8000,  0x2)
+AVR_MCU ("avr128db32",   ARCH_AVRXMEGA4, AVR_ISA_NONE, 
"__AVR_AVR128DB32__",   0x4000, 0x0, 0x8000,  0x2)
+AVR_MCU ("avr128db48",   ARCH_AVRXMEGA4, 

[PATCH 0/2] avr: Add support AVR-DA and DB series devices

[Joel Holdsworth via Gcc-patches]

In 2021, Microchip launched two new series of AVR microcontrollers:
AVR-DA and AVR-DB. This patch-set contains patches to add support for
the full set of both series of devices, by listing the memory layouts in
avr-mcus.def.

There is an open GitHub Pull Request to add support for these devices to
avr-libc here: https://github.com/avrdudes/avr-libc/pull/881

In addition, this patch-set includes a patch to remove non-printable
characters from avr-devices.cc.

Joel Holdsworth (2):
  avr: Added AVR-DA and DB MCU series
  avr: Removed errant control characters

 gcc/config/avr/avr-devices.cc|  2 --
 gcc/config/avr/avr-mcus.def  | 22 ++
 gcc/config/avr/gen-avr-mmcu-specs.cc |  2 +-
 gcc/config/avr/gen-avr-mmcu-texi.cc  |  2 +-
 gcc/doc/avr-mmcu.texi|  6 +++---
 5 files changed, 27 insertions(+), 7 deletions(-)

-- 
2.35.GIT

[PATCH] c++: implicit guides should inherit class constraints [PR104873]

[Patrick Palka via Gcc-patches]

An implicit guide already inherits the (rewritten) constraints of the
constructor.  Thus it seems natural that the guide must also inherit
the constraints of the class template, since a constructor's constraints
might assume the class's constraints are satisfied, and therefore
checking these two sets of constraints "out of order" may result in hard
errors as in the first testcase below.

This patch makes implicit guides inherit the constraints of the class
template (even for unconstrained constructors, and even for the copy
deduction candidate).

In passing, this patch gives implicit guides a trailing return type
since that's how they're depicted in the standard (e.g.
[over.match.class.deduct]/6); this changes the order of substitution
into implicit guides in a probably negligible way, especially now that
they inherit the class constraints.

The parameter_mapping_equivalent_p change is to avoid an ICE in the last
testcase below (described within), reduced from a cmcstl2 testsuite ICE.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
the right approach?

PR c++/104873

gcc/cp/ChangeLog:

* constraint.cc (parameter_mapping_equivalent_p): Relax assert
to expect equivalence not identity of template parameters.
* pt.cc (build_deduction_guide): Propagate the class's
constraints to the deduction guide.  Set TYPE_HAS_LATE_RETURN_TYPE
on the function type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-ctad5.C: New test.
* g++.dg/cpp2a/concepts-ctad6.C: New test.
* g++.dg/cpp2a/concepts-ctad6a.C: New test.
* g++.dg/cpp2a/concepts-ctad7.C: New test.
---
 gcc/cp/constraint.cc |  2 +-
 gcc/cp/pt.cc | 26 ++
 gcc/testsuite/g++.dg/cpp2a/concepts-ctad5.C  | 29 
 gcc/testsuite/g++.dg/cpp2a/concepts-ctad6.C  | 19 +
 gcc/testsuite/g++.dg/cpp2a/concepts-ctad6a.C | 19 +
 gcc/testsuite/g++.dg/cpp2a/concepts-ctad7.C  | 26 ++
 6 files changed, 120 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-ctad5.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-ctad6.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-ctad6a.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-ctad7.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 94f6222b436..6cbb182dda2 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -604,7 +604,7 @@ parameter_mapping_equivalent_p (tree t1, tree t2)
   tree map2 = ATOMIC_CONSTR_MAP (t2);
   while (map1 && map2)
 {
-  gcc_checking_assert (TREE_VALUE (map1) == TREE_VALUE (map2));
+  gcc_checking_assert (cp_tree_equal (TREE_VALUE (map1), TREE_VALUE 
(map2)));
   tree arg1 = TREE_PURPOSE (map1);
   tree arg2 = TREE_PURPOSE (map2);
   if (!template_args_equal (arg1, arg2))
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 75ed9a34018..966e6d90d3a 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -29261,6 +29261,10 @@ build_deduction_guide (tree type, tree ctor, tree 
outer_args, tsubst_flags_t com
   /* Discard the 'this' parameter.  */
   fparms = FUNCTION_ARG_CHAIN (ctor);
   fargs = TREE_CHAIN (DECL_ARGUMENTS (ctor));
+  /* The guide's constraints consist of the class template's constraints
+followed by the constructor's rewritten constraints.  We start
+with the constructor's constraints (since we need to rewrite them),
+and prepend the class template's constraints later.  */
   ci = get_constraints (ctor);
   loc = DECL_SOURCE_LOCATION (ctor);
   explicit_p = DECL_NONCONVERTING_P (ctor);
@@ -29362,6 +29366,27 @@ build_deduction_guide (tree type, tree ctor, tree 
outer_args, tsubst_flags_t com
return error_mark_node;
 }
 
+  /* Prepend the class template's constraints to the constructor's rewritten
+ constraints (if any).  */
+  if (tree class_ci = get_constraints (CLASSTYPE_TI_TEMPLATE (type)))
+{
+  if (outer_args)
+   {
+ /* FIXME: As above.  */
+ ++processing_template_decl;
+ class_ci = tsubst_constraint_info (class_ci, outer_args,
+complain, ctor);
+ --processing_template_decl;
+   }
+  if (ci)
+   ci = build_constraints (combine_constraint_expressions
+   (CI_TEMPLATE_REQS (class_ci),
+CI_TEMPLATE_REQS (ci)),
+   CI_DECLARATOR_REQS (ci));
+  else
+   ci = copy_node (class_ci);
+}
+
   if (!memtmpl)
 {
   /* Copy the parms so we can set DECL_PRIMARY_TEMPLATE.  */
@@ -29371,6 +29396,7 @@ build_deduction_guide (tree type, tree ctor, tree 
outer_args, tsubst_flags_t com
 }
 
   tree fntype = build_function_type (type, fparms);
+  TYPE_HAS_LATE_RETURN_TYPE (fntype) = true;
   tree ded_fn = 

[Bug target/105123] [9/10/11/12 Regression] wrong code with -m32 -mtune=i686 and __builtin_shuffle()

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 52735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52735=edit
gcc12-pr105123.patch

Untested fix.
The problem was expansion of a (dead) statement
  _1 = {u.0_3, u.0_3, u.0_3, u.0_3};
where the expansion overwrote the pseudo containing u.0_3:
(insn 10 9 11 (parallel [
(set (reg:SI 83 [ u.0_3 ])
(ashift:SI (reg:SI 83 [ u.0_3 ])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "pr105123.c":6:31 -1
 (nil))

(insn 11 10 12 (parallel [
(set (reg:SI 83 [ u.0_3 ])
(ior:SI (reg:SI 83 [ u.0_3 ])
(reg:SI 83 [ u.0_3 ])))
(clobber (reg:CC 17 flags))
]) "pr105123.c":6:31 -1
 (nil))

(insn 12 11 13 (parallel [
(set (reg:SI 83 [ u.0_3 ])
(ashift:SI (reg:SI 83 [ u.0_3 ])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "pr105123.c":6:31 -1
 (nil))

(insn 13 12 14 (parallel [
(set (reg:SI 83 [ u.0_3 ])
(ior:SI (reg:SI 83 [ u.0_3 ])
(reg:SI 83 [ u.0_3 ])))
(clobber (reg:CC 17 flags))
]) "pr105123.c":6:31 -1
 (nil))

(insn 14 13 15 (clobber (reg:V4HI 110)) "pr105123.c":6:31 -1
 (nil))

(insn 15 14 16 (set (subreg:SI (reg:V4HI 110) 0)
(reg:SI 83 [ u.0_3 ])) "pr105123.c":6:31 -1
 (nil))

(insn 16 15 17 (set (subreg:SI (reg:V4HI 110) 4)
(reg:SI 83 [ u.0_3 ])) "pr105123.c":6:31 -1
 (nil))

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[lists at coryfields dot com via Gcc-bugs]

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

Cory Fields  changed:

   What|Removed |Added

 CC||lists at coryfields dot com

--- Comment #33 from Cory Fields  ---
Adding another +1. Still present in 10.3.0.

Bitcoin Core's sha2 code uses avx2 when possible. We ran into this bug when
bumping our toolchain:
https://github.com/bitcoin/bitcoin/pull/24736

and opted to take Debian's patch:
https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/-/blob/master/debian/patches/vmov-alignment.patch

It's unfortunate that the best and most common advice for using avx2 with
gcc/mingw is to use a patched compiler. Might it be possible to accept Debian's
patch upstream?

[Bug target/105123] [9/10/11/12 Regression] wrong code with -m32 -mtune=i686 and __builtin_shuffle()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

Re: [PATCH v2] rs6000: Support UN[GL][ET] in rs6000_maybe_emit_maxc_minc [PR105002]

[Segher Boessenkool]

Hi!

On Fri, Apr 01, 2022 at 02:27:14PM +0800, Kewen.Lin wrote:
> Commit r12-7687 exposed one miss optimization chance in function
> rs6000_maybe_emit_maxc_minc, for now it only considers comparison
> codes GE/GT/LE/LT, but it can support more variants with codes
> UNLT/UNLE/UNGT/UNGE by reversing them into the equivalent ones
> with GE/GT/LE/LT.

You may want to add somewhere (in the comment in the code perhaps?)
that if we see e.g. UNLT it guarantees that we have 4-way condition
codes (LT/GT/EQ/UN), so we do not have to check for fast-math or the
like.  This is always true of course, but it doesn't hurt to remind
the reader :-)

The PR marker goes here:

PR target/105002
>   * config/rs6000/rs6000.cc (rs6000_maybe_emit_maxc_minc): Support more
>   comparison codes UNLT/UNLE/UNGT/UNGE.

> -  bool max_p = false;
> +  bool max_p;

Please move this to later, since you touch it anyway:

  bool max_p;
>if (code == GE || code == GT)
>  max_p = true;
>else if (code == LE || code == LT)

Okay for trunk with those finishing touches.  Thanks!


Segher

[Bug target/102024] [12 Regression] zero width bitfields and ABIs

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

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

--- Comment #37 from CVS Commits  ---
The master branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:413187b0b3c87253838e4afbf8463b288b59

commit r12-7962-g413187b0b3c87253838e4afbf8463b288b59
Author: Xi Ruoyao 
Date:   Thu Mar 31 23:40:23 2022 +0800

mips: Ignore zero width fields in arguments and issue -Wpsabi warning about
C zero-width field ABI changes [PR102024]

gcc/
PR target/102024
* config/mips/mips.cc (mips_function_arg): Ignore zero-width
fields, and inform if it causes a psABI change.

gcc/testsuite/
PR target/102024
* gcc.target/mips/pr102024-1.c: New test.
* gcc.target/mips/pr102024-2.c: New test.
* gcc.target/mips/pr102024-3.c: New test.

[Bug target/102024] [12 Regression] zero width bitfields and ABIs

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

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

--- Comment #36 from CVS Commits  ---
The master branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:0d4b97f1ee5213dffce107bc9f260a22fb23b4b1

commit r12-7961-g0d4b97f1ee5213dffce107bc9f260a22fb23b4b1
Author: Xi Ruoyao 
Date:   Wed Mar 30 22:22:45 2022 +0800

mips: Emit psabi diagnostic for return values affected by C++ zero-width
bit-field ABI change [PR 102024]

gcc/
PR target/102024
* config/mips/mips.cc (mips_fpr_return_fields): Detect C++
zero-width bit-fields and set up an indicator.
(mips_return_in_msb): Adapt for mips_fpr_return_fields change.
(mips_function_value_1): Diagnose when the presense of a C++
zero-width bit-field changes function returning in GCC 12.

gcc/testsuite/
PR target/102024
* g++.target/mips/mips.exp: New test supporting file.
* g++.target/mips/pr102024.C: New test.

[wwwdocs] gcc-12: linkify various options

[David Malcolm via Gcc-patches]

I've committed the following patch to the GCC 12 release notes.

---
 htdocs/gcc-12/changes.html | 47 --
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index f1c36258..5619acff 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -172,17 +172,20 @@ a work-in-progress.
   the clang language extension was added.
   New warnings:
 
-  -Wbidi-chars warns about potentially misleading UTF-8
+  https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wbidi-chars;>-Wbidi-chars
+   warns about potentially misleading UTF-8
bidirectional control characters.  The default is
-Wbidi-chars=unpaired
(https://gcc.gnu.org/PR103026;>PR103026)
-  -Warray-compare warns about comparisons between two 
operands of
- array type (https://gcc.gnu.org/PR97573;>PR97573)
+  https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Warray-compare;>-Warray-compare
+   warns about comparisons between two operands of
+   array type (https://gcc.gnu.org/PR97573;>PR97573)
 
   
   Enhancements to existing warnings:
 
-  -Wattributes has been extended so that it's
+  https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wattributes;>-Wattributes
+   has been extended so that it's
possible to use -Wno-attributes=ns::attr or
-Wno-attributes=ns:: to suppress warnings about unknown 
scoped
attributes (in C++11 and C2X).  Similarly,
@@ -208,7 +211,8 @@ a work-in-progress.
 The #elifdef and #elifndef
 preprocessing directives are now supported.
 The printf and scanf format checking
-with -Wformat now supports the %b format
+  with https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat;>-Wformat
+  now supports the %b format
 specified by C2X for binary integers, and the %B
 format recommended by C2X for printf.
   
@@ -263,10 +267,12 @@ a work-in-progress.
   (https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=87c2080b;>git)
   Deduction guides can be declared at class scope
   (https://gcc.gnu.org/PR79501;>PR79501)
-  -Wuninitialized warns about using uninitialized variables in
+  https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wuninitialized;>-Wuninitialized
+warns about using uninitialized variables in
   member initializer lists (https://gcc.gnu.org/PR19808;>PR19808)
   
-  -Wint-in-bool-context is now disabled when instantiating
+  https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wint-in-bool-context;>-Wint-in-bool-context
+is now disabled when instantiating
   a template (https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3a2b12bc;>git)
   Stricter checking of attributes on friend declarations: if a friend
   declaration has an attribute, that declaration must be a definition.
@@ -279,13 +285,15 @@ a work-in-progress.
   and -Wc++23-extensions.  They are enabled by default
   and can be used to control existing pedwarns about occurences of
   new C++ constructs in code using an old C++ standard dialect.
-  New warning -Wmissing-requires warns about missing
-  requires
+  New warning
+  https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmissing-requires;>-Wmissing-requires
+  warns about missing requires
   (https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e18e56c7;>git)
   The existing std::is_constant_evaluated in if
   warning was extended to warn in more cases
   (https://gcc.gnu.org/PR100995;>PR100995)
-  -Waddress has been enhanced so that it now warns about, for
+  https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Waddress;>-Waddress
+  has been enhanced so that it now warns about, for
   instance, comparing the address of a nonstatic member function to null
   (https://gcc.gnu.org/PR102103;>PR102103)
   Errors about narrowing are no longer hidden if they occur in system
@@ -307,7 +315,9 @@ a work-in-progress.
   constinit thread_local variables are optimized better
   (https://gcc.gnu.org/PR101786;>PR101786)
   Support for C++17 
std::hardware_destructive_interference_size
-  was added, along with the -Winterference-size warning
+  was added, along with the
+  https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Winterference-size;>-Winterference-size
+  warning
   (https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=76b75018;>git)
   Many bugs in the CTAD handling have been fixed
   (https://gcc.gnu.org/PR101344;>PR101344,
@@ -618,16 +628,19 @@ a work-in-progress.
 Eliminating uninitialized variables
 
 
-  GCC can now initialize all stack variables implicitly, including
+  GCC can now https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init;>initialize
 all stack variables implicitly, including
   padding. This is intended to eliminate 

Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817, PR104820]

[Maciej W. Rozycki]

On Sat, 12 Mar 2022, Xi Ruoyao via Gcc-patches wrote:

> I'm now thinking: is there always at least one *GPR* which need to be
> cleared?  If it's true, let's say GPR $12, and fcc0 & fcc2 needs to be
> cleared, we can use something like:
> 
> cfc1 $12, $25
> andi $25, 5
> ctc1 $12, $25
> move $12, $0

 There's always $1 ($at) available and we're in a function's epilogue, so 
there should be plenty of dead temporaries available as well.  For legacy 
ISAs you'd need to use the FCSR instead ($31) and two temporaries would be 
required as the condition code bits are located in the upper half.

 FWIW,

  Maciej

[wwwdocs] gcc-12: jit changes

[David Malcolm via Gcc-patches]

I've gone ahead and committed the following change to the GCC 12
release notes.

---
 htdocs/gcc-12/changes.html | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 689feeba..f1c36258 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -380,7 +380,40 @@ a work-in-progress.
 
 
 
-
+libgccjit
+
+
+  The libgccjit API gained 23 new entry points:
+
+  17 new "reflection" entrypoints for querying functions and types (https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html#libgccjit-abi-16;>LIBGCCJIT_ABI_16)
+  
+  
+   https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#c.gcc_jit_lvalue_set_tls_model;>gcc_jit_lvalue_set_tls_model
+   for supporting thread-local variables
+   (https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html#libgccjit-abi-17;>LIBGCCJIT_ABI_17)
+  
+  
+   https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#c.gcc_jit_lvalue_set_link_section;>gcc_jit_lvalue_set_link_section
+   for setting the link section of global variables, analogous to
+   https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-section-variable-attribute;>__attribute__((section(".section")))
+   (https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html#libgccjit-abi-18;>LIBGCCJIT_ABI_18)
+  
+  4 new entrypoints for initializing global variables and creating
+   constructors for rvalues
+   (https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html#libgccjit-abi-19;>LIBGCCJIT_ABI_19)
+  
+
+  
+  libgccjit has gained support for the use of various atomic builtins
+(https://gcc.gnu.org/PR96066;>PR96066,
+https://gcc.gnu.org/PR96067;>PR96067)
+  
+  https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#c.gcc_jit_context_new_cast;>gcc_jit_context_new_cast
+is now able to handle truncation and extension between different
+integer types
+(https://gcc.gnu.org/PR95498;>PR95498)
+  
+
 
 
 New Targets and Target Specific Improvements
-- 
2.30.2

[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Vladimir Makarov
:

https://gcc.gnu.org/g:5f587c81bc558942d2988f5e2965a72471f5c202

commit r11-9754-g5f587c81bc558942d2988f5e2965a72471f5c202
Author: Vladimir N. Makarov 
Date:   Fri Apr 1 09:48:57 2022 -0400

[PR105032] LRA: modify loop condition to find reload insns for hard reg
splitting

When trying to split hard reg live range to assign hard reg to a reload
pseudo, LRA searches for reload insns of the reload pseudo
assuming a specific order of the reload insns.  This order is violated if
reload involved in inheritance transformation. In such case, the loop used
for reload insn searching can become infinite.  The patch fixes this.

gcc/ChangeLog:

PR middle-end/105032
* lra-assigns.c (find_reload_regno_insns): Modify loop condition.

gcc/testsuite/ChangeLog:

PR middle-end/105032
* gcc.target/i386/pr105032.c: New.

[Bug target/105123] [9/10/11/12 Regression] wrong code with -m32 -mtune=i686 and __builtin_shuffle()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
   Target Milestone|--- |9.5
   Priority|P3  |P2
Summary|wrong code with -m32|[9/10/11/12 Regression]
   |-mtune=i686 and |wrong code with -m32
   |__builtin_shuffle() |-mtune=i686 and
   ||__builtin_shuffle()

--- Comment #3 from Jakub Jelinek  ---
Started with r0-127375-gdd908cc5d8ee9e775c45b5a7078e1276f321d134

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

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

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

--- Comment #26 from Jason Merrill  ---
Created attachment 52734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52734=edit
patch for tentative early DMI parsing

This patch series (for GCC 13) adds a mode that tries to parse nested class DMI
at the end of the nested class rather than at the end of all enclosing classes.
 If that fails, we try again at the later point.

The first patch in the series extends our existing name-clash checking to cover
nested classes as well, to catch the case where this can change name lookup
results.

[Bug lto/105121] ice in bp_unpack_string

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

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

--- Comment #4 from Martin Liška  ---
Note that we don't bump LTO bytecode version during the development of a GCC
release (stage1-4). Once we do a release, we keep eye on it.

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

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

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|12.0|13.0
 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |---

--- Comment #25 from Jason Merrill  ---
Reopening.

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

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

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

--- Comment #24 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:86d8e0c0652ef5236a460b75c25e4f7093cc0651

commit r12-7960-g86d8e0c0652ef5236a460b75c25e4f7093cc0651
Author: Jason Merrill 
Date:   Fri Apr 1 09:01:30 2022 -0400

Revert "c++: delayed parse DMI [PR96645]"

The breakage from r12-7804 (in WebKit, particularly) is more of a can of
worms than I think we can address in GCC 12, so let's return to the GCC 11
status quo for now and try again in stage 1.

I think the change was correct for the current standard, but the standard
needs a fix in this area; this is CWG issue 2335.

PR c++/96645

This reverts commits r12-7804 and r12-7929.

[Bug regression/105126] New: Optimization regression gcc inserts not needed movsx when using switch statement

[andre.schackier at gmail dot com via Gcc-bugs]

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

Bug ID: 105126
   Summary: Optimization regression gcc inserts not needed movsx
when using switch statement
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andre.schackier at gmail dot com
  Target Milestone: ---

Given the following source code:

```cpp
bool is_bin_0(const char c) { return (c == '0' || c == '1'); }

bool is_bin_1(const char c) {
switch (c) {
case '0':
case '1':
return true;

default:
return false;
}
}

```

compiling with `-O3` gives the following output:

```asm
is_bin_0(char):
sub edi, 48
cmp dil, 1
setbe   al
ret
is_bin_1(char):
movsx   edi, dil
sub edi, 48
cmp edi, 1
setbe   al
ret
```

The version using a switch generates an extra movsx instruction which, as far
is I understand the x86 CPU registers is not needed since DIL is the lower 8
bits of EDI anyways, but correct me if I'm wrong there.

This also seems to be a regression introduced with GCC-8.1 since GCC-4.5 to
GCC-7.5 generate the same assembly as for the first and second function and all
version after that including trunk produce different outputs.

[link to godbolt](https://godbolt.org/z/r3vhYbK6o)

[Bug c++/105125] Bogus and Misleading Warning: Packed attribute is unnecessary.

[Kimon.Hoffmann at lawo dot com via Gcc-bugs]

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

Kimon.Hoffmann at lawo dot com changed:

   What|Removed |Added

  Known to fail||10.1.0, 11.1.0, 11.2.0,
   ||5.1.0, 6.1.0, 7.1.0, 8.1.0,
   ||9.1.0

--- Comment #1 from Kimon.Hoffmann at lawo dot com ---
I checked the behavior with each major version since version 5, using the x.1.0
version as the representative, and can confirm that the issue is present in all
versions checked.

[Bug c++/105125] New: Bogus and Misleading Warning: Packed attribute is unnecessary.

[Kimon.Hoffmann at lawo dot com via Gcc-bugs]

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

Bug ID: 105125
   Summary: Bogus and Misleading Warning: Packed attribute is
unnecessary.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Kimon.Hoffmann at lawo dot com
  Target Milestone: ---

GCC erroneously declares a packed attribute on a struct member as unnecessary,
while it clearly isn't.

Reproducer:

-- 8< --

#include 

struct A
{
std::uint32_t i;
};

struct B
{
std::uint64_t i;
};

struct C
{
A a;
B b;
};

struct D
{
A a [[gnu::packed]];
B b;
};

struct E
{
A a;
B b [[gnu::packed]];
};

struct F
{
B b [[gnu::packed]];
A a;
};

static_assert((sizeof(A) ==  4) && (alignof(A) == 4));
static_assert((sizeof(B) ==  8) && (alignof(B) == 8));
static_assert((sizeof(C) == 16) && (alignof(C) == 8));
static_assert((sizeof(D) == 16) && (alignof(D) == 8));
static_assert((sizeof(E) == 12) && (alignof(E) == 4));
static_assert((sizeof(F) == 12) && (alignof(F) == 4));

-- >8 --

Invocation: cat test.cpp | x86_64-linux-gnu-g++ -xc++ -std=c++17 -Wpacked -c -o
/dev/null -

Observed behavior:
:21:7: warning: packed attribute is unnecessary for ‘D::a’
[-Wattributes]
:33:7: warning: packed attribute is unnecessary for ‘F::b’
[-Wattributes]

Expected behaviur:
While the warning referring to line 21 is correct, the warning referring to
line 33 isn't, and thus no message is expected.


Please note that this report describes the same behavior as report #59220, but
is more generally applicable, as the aforementioned report uses an explicitly
overaligned type, and might thus give the false impression that overalignment
is a required prerequisite for the issue to.

[Bug debug/105041] '-fcompare-debug' failure w/ -mcpu=power6 -O2 -fharden-compares -frename-registers

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

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

Peter Bergner  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #4 from Peter Bergner  ---
Given this only affects 32-bit BE compiles that use the uncommonly used option
-frename-registers, I'm dropping the importance to P4.

[committed] jit: further doc fixes

[David Malcolm via Gcc-patches]

Further jit doc fixes, which fix links to
gcc_jit_function_type_get_param_type and gcc_jit_struct_get_field.

I also regenerated libgccjit.texi (not included in the diff below).

Tested with "make html" and with a bootstrap.
Committed to trunk as r12-7959-g1a172da8a3f362.

gcc/jit/ChangeLog:
* docs/topics/expressions.rst: Fix formatting.
* docs/topics/types.rst: Likewise.
* docs/_build/texinfo/libgccjit.texi: Regenerate

Signed-off-by: David Malcolm 
---
 gcc/jit/docs/topics/expressions.rst | 8 
 gcc/jit/docs/topics/types.rst   | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/jit/docs/topics/expressions.rst 
b/gcc/jit/docs/topics/expressions.rst
index 9267b6d2ad6..d51264af73f 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -24,7 +24,7 @@ Rvalues
 ---
 .. type:: gcc_jit_rvalue
 
-A :c:type:`gcc_jit_rvalue *` is an expression that can be computed.
+A :c:type:`gcc_jit_rvalue` is an expression that can be computed.
 
 It can be simple, e.g.:
 
@@ -602,7 +602,7 @@ Function calls
   gcc_jit_rvalue_set_bool_require_tail_call (gcc_jit_rvalue *call,\
  int require_tail_call)
 
-   Given an :c:type:`gcc_jit_rvalue *` for a call created through
+   Given an :c:type:`gcc_jit_rvalue` for a call created through
:c:func:`gcc_jit_context_new_call` or
:c:func:`gcc_jit_context_new_call_through_ptr`, mark/clear the
call as needing tail-call optimization.  The optimizer will
@@ -721,8 +721,8 @@ where the rvalue is computed by reading from the storage 
area.
 
   #ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_tls_model
 
-.. function:: void
-  gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,
+.. function:: void\
+  gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,\
const char *section_name)
 
Set the link section of a variable.
diff --git a/gcc/jit/docs/topics/types.rst b/gcc/jit/docs/topics/types.rst
index 9779ad26b6f..c2082c0ef3e 100644
--- a/gcc/jit/docs/topics/types.rst
+++ b/gcc/jit/docs/topics/types.rst
@@ -192,7 +192,7 @@ A compound type analagous to a C `struct`.
 
 A field within a :c:type:`gcc_jit_struct`.
 
-You can model C `struct` types by creating :c:type:`gcc_jit_struct *` and
+You can model C `struct` types by creating :c:type:`gcc_jit_struct` and
 :c:type:`gcc_jit_field` instances, in either order:
 
 * by creating the fields, then the structure.  For example, to model:
@@ -375,7 +375,7 @@ Reflection API
  Given a function type, return its number of parameters.
 
 .. function::  gcc_jit_type *\
-   gcc_jit_function_type_get_param_type (gcc_jit_function_type 
*function_type,
+   gcc_jit_function_type_get_param_type (gcc_jit_function_type 
*function_type,\
  size_t index)
 
  Given a function type, return the type of the specified parameter.
@@ -417,7 +417,7 @@ Reflection API
  alignment qualifiers.
 
 .. function::  gcc_jit_field *\
-   gcc_jit_struct_get_field (gcc_jit_struct *struct_type,
+   gcc_jit_struct_get_field (gcc_jit_struct *struct_type,\
  size_t index)
 
  Get a struct field by index.
-- 
2.26.3

Re: [RFC] ipa-cp: Feed results of IPA-CP into SCCVN

[Martin Jambor]

Hi,

thanks for a very quick reply.

On Fri, Apr 01 2022, Richard Biener wrote:
> On Fri, 1 Apr 2022, Martin Jambor wrote:
>
>> Hi,
>> 
>> PRs 68930 and 92497 show that when IPA-CP figures out constants in
>> aggregate parameters or when passed by reference but the loads happen
>> in an inlined function the information is lost.  This happens even
>> when the inlined function itself was known to have - or even cloned to
>> have - such constants in incoming parameters because the transform
>> phase of IPA passes is not run on them.  See discussion in the bugs
>> for reasons why.
>> 
>> Honza suggested that we can plug the results of IPA-CP analysis into
>> value numbering, so that FRE can figure out that some loads fetch
>> known constants.  This is what this patch attempts to do.
>> 
>> Although I spent quite some time reading tree-sccvn.c, it is complex
>> enough that I am sure I am not aware of various caveats and so I would
>> not be terribly surprised if there were some issues with my approach
>> that I am not aware of.  Nevertheless, it seems to work well for simple
>> cases and even passes bootstrap and testing (and LTO bootstrap) on
>> x86_64-linux.
>> 
>> I have experimented a little with using this approach instead of the
>> function walking parts of the IPA-CP transformation phase.  This would
>> mean that the known-constants would not participate in the passes after
>> IPA but before FRE - which are not many but there is a ccp and fwprop
>> pass among others.  For simple testcases like
>> gcc/testsuite/gcc.dg/ipa/ipcp-agg-*.c, it makes not assembly difference
>> at all.
>> 
>> What do you think?
>
> Comments below
>
>> Martin
>> 
>> 
>> gcc/ChangeLog:
>> 
>> 2022-03-30  Martin Jambor  
>> 
>>  PR ipa/68930
>>  PR ipa/92497
>>  * ipa-prop.cc (ipcp_get_aggregate_const): New function.
>>  (ipcp_transform_function): Do not deallocate transformation info.
>>  * ipa-prop.h (ipcp_get_aggregate_const): Declare.
>>  * tree-ssa-sccvn.cc: Include alloc-pool.h, symbol-summary.h and
>>  ipa-prop.h.
>>  (vn_reference_lookup_2): When hitting default-def vuse, query
>>  IPA-CP transformation info for any known constants.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>> 2022-03-30  Martin Jambor  
>> 
>>  PR ipa/68930
>>  PR ipa/92497
>>  * gcc.dg/ipa/pr92497-1.c: New test.
>>  * gcc.dg/ipa/pr92497-2.c: Likewise.
>> ---
>>  gcc/ipa-prop.cc  | 43 
>>  gcc/ipa-prop.h   |  2 ++
>>  gcc/testsuite/gcc.dg/ipa/pr92497-1.c | 26 +
>>  gcc/testsuite/gcc.dg/ipa/pr92497-2.c | 26 +
>>  gcc/tree-ssa-sccvn.cc| 35 +-
>>  5 files changed, 126 insertions(+), 6 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.dg/ipa/pr92497-1.c
>>  create mode 100644 gcc/testsuite/gcc.dg/ipa/pr92497-2.c
>> 
>> diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
>> index e55fe2776f2..a73a5d9ec1d 100644
>> --- a/gcc/ipa-prop.cc
>> +++ b/gcc/ipa-prop.cc
>> @@ -5748,6 +5748,44 @@ ipcp_modif_dom_walker::before_dom_children 
>> (basic_block bb)
>>return NULL;
>>  }
>>  
>> +/* If IPA-CP discovered a constant in parameter PARM at OFFSET of a given 
>> SIZE
>> +   - whether passed by reference or not is given by BY_REF - return that
>> +   constant.  Otherwise return NULL_TREE.  */
>> +
>> +tree
>> +ipcp_get_aggregate_const (tree parm, bool by_ref,
>> +  HOST_WIDE_INT offset, HOST_WIDE_INT size)
>
> I'd prefer to pass in the function decl or struct function or
> cgraph node.

OK.

>
>> +{
>> +  cgraph_node *cnode = cgraph_node::get (current_function_decl);
>> +
>> +  ipa_agg_replacement_value *aggval = ipa_get_agg_replacements_for_node 
>> (cnode);
>> +  if (!aggval)
>> +return NULL_TREE;
>> +
>> +  int index = 0;
>> +  for (tree p = DECL_ARGUMENTS (current_function_decl);
>> +   p != parm; p = DECL_CHAIN (p))
>> +{
>> +  index++;
>> +  if (!p)
>> +return NULL_TREE;
>> +}
>> +
>> +  ipa_agg_replacement_value *v;
>> +  for (v = aggval; v; v = v->next)
>> +if (v->index == index
>> +&& v->offset == offset)
>> +  break;
>> +  if (!v
>> +  || v->by_ref != by_ref
>> +  || maybe_ne (tree_to_poly_int64 (TYPE_SIZE (TREE_TYPE (v->value))),
>> +   size))
>> +return NULL_TREE;
>
> two linear searches here - ugh.  I wonder if we should instead
> pre-fill a hash-map from PARM_DECL to a ipa_agg_replacement_value *
> vector sorted by offset which we can binary search?  That could be
> done once when starting value-numbering (not on regions).  Is
> there any reason the data structure is as it is?

Only that it is usually a very short list.  It is bounded by
param_ipa_cp_value_list_size (8 by default) times the number of
arguments and of course only few usually have any constants in them.

Having said that, changing the structure is something I am looking into
also for other reasons and I am very much opened to 

Re: [PATCH] JIT: Update docs v2

[David Malcolm via Gcc-patches]

On Sat, 2022-02-19 at 15:34 +, Petter Tomner via Gcc-patches wrote:
> Please disregard the prior patch I sent some minute ago. I spotted an
> copy-paste error, corrected bellow:
> 
> From 7f1d849319318a4cfd304279840899f928f9b86d Mon Sep 17 00:00:00 2001
> From: Petter Tomner 
> Date: Sat, 19 Feb 2022 16:01:54 +0100
> Subject: [PATCH] jit: Update docs
> 
> Update docs concerning linking and fix formatting errors. 'make html'
> looks fine.
> 
> /gcc/jit/docs/topics:
> * compatibility.rst: Add 19 tag
> * compilation.rst: Linking
> * contexts.rst: Linking example
> * expressions.rst: Fix formatting and dropped 's'
> 
> Signed-off-by:
> Petter Tomner   2022-02-19  
> ---
>  gcc/jit/docs/topics/compatibility.rst | 12 
>  gcc/jit/docs/topics/compilation.rst   |  8 ++--
>  gcc/jit/docs/topics/contexts.rst  |  5 +
>  gcc/jit/docs/topics/expressions.rst   | 15 ++-
>  4 files changed, 29 insertions(+), 11 deletions(-)


Thanks for these fixes, and sorry for the delayed in reviewing them.

I doublechecked them, and have pushed them to trunk as
r12-7958-gaed0f014781ee3.

Dave

[Bug lto/105121] ice in bp_unpack_string

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to Richard Biener from comment #2)
> Are you sure you have object files compiled with the same compiler as you
> link with?

I just compiled it again. Yes, I have the same compiler.
It looks like a mismatch in LTO readers and writers to me.

Would the .i file that is upstream of the .o file help ?

Re: [PATCH] libstdc++: Implement std::unreachable() for C++23 (P0627R6)

[Jonathan Wakely via Gcc-patches]

On Fri, 1 Apr 2022 at 12:56, Matthias Kretz wrote:
>
> On Friday, 1 April 2022 13:33:42 CEST Jonathan Wakely wrote:
> > Matthias didn't like my Princess Bride easter egg :-)
> > Would the attached be better?
>
> LGTM.

OK, thanks to everybody who commented. I've pushed that to trunk now.

[Bug debug/105124] -Og loses DWARF value for a reassigned variable that is kept instead by other optimization levels

[assaiante at diag dot uniroma1.it via Gcc-bugs]

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

--- Comment #1 from Cristian Assaiante  ---
We suspect this may be related to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108 but this time the behaviors
at -O1 and -Og are different

[Bug debug/105124] New: -Og loses DWARF value for a reassigned variable that is kept instead by other optimization levels

[assaiante at diag dot uniroma1.it via Gcc-bugs]

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

Bug ID: 105124
   Summary: -Og loses DWARF value for a reassigned variable that
is kept instead by other optimization levels
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: assaiante at diag dot uniroma1.it
  Target Milestone: ---

In this minimized C code, variable l_62 appears as optimized out at line 6,
where it is assigned again with the same value and used in the assignment of
global variable a. The variable is then available at line 8 with its correct
value 6 coming from the update at line 7.

This behavior only occurs when the optimization level is Og, while at -O1 and
higher optimization levels the variable is always visible with a correct value
available.

Interestingly, if we assign l_62 for instance with 2 at line 4, then the issue
is no longer present at Og and the value 2 is displayed at line 6 (just like at
-O1/O2/O3). We also note that, in this case, at -O1/-Og the DWARF info contains
values 0 and 6, while at -O2/-O3 also value 0 which is in use only between line
6 and 7.

We provide below a detailed analysis on x64.

$ cat a.c
short a;
int foo1() { return 0; }
short foo0(int d) {
  int e, f = 11, l_62 = 0;
  e = foo1();
  a = f | (l_62 = e) >= d;
  l_62 = 6;
  return d;
}
int main() { foo0(0); }


GCC and GDB version (GCC commit id: 500d3f0a302):
$ gcc --version
gcc (GCC) 12.0.0 20211227 (experimental)

$ gdb --version
GNU gdb (GDB) 11.2

GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 6
Breakpoint 1 at 0x40048f: file a.c, line 6.
(gdb) r
Starting program: /home/stepping/4/reduce/opt 

Breakpoint 1, foo0 (d=d@entry=0) at a.c:6
6 a = f | (l_62 = e) >= d;
(gdb) info loc
e = 
f = 11
l_62 = 
(gdb) n
8 return d;
(gdb) info loc
e = 
f = 11
l_62 = 6


ASM of foo0 function:
0040048c :
 40048c:   53  push   %rbx
 40048d:   89 fb   mov%edi,%ebx
 40048f:   66 c7 05 92 0b 20 00movw   $0xb,0x200b92(%rip)#
60102a 
 400496:   0b 00  
 400498:   89 d8   mov%ebx,%eax
 40049a:   5b  pop%rbx
 40049b:   c3  retq 


DWARF at -Og:
0x00c9: DW_TAG_variable
  DW_AT_name("l_62")
  DW_AT_decl_file   ("/home/stepping/4/reduce/a.c")
  DW_AT_decl_line   (4)
  DW_AT_decl_column (0x12)
  DW_AT_type(0x007f "int")
  DW_AT_location(0x0010: 
 [0x0040048f, 0x0040048f): DW_OP_lit0,
DW_OP_stack_value
 [0x00400498, 0x0040049c): DW_OP_lit6,
DW_OP_stack_value)
  DW_AT_unknown_2137(0x000c)



>From a quick analysis of DWARF symbols, the problem seems to be in the location
definition of the variable. The first entry is an empty range when it should
probably include the instruction at 40048f which is associated with line 6. We
tried to manually patch the executable file from -Og by setting the first entry
of the location [0x0040048f, 0x0040048f) to
[0x0040048f, 0x00400498). After the change, the variable is
displayed. 

At -O1 and higher optimization levels, the first entry of the DWARF location
info contains the correct range that includes the ASM instruction associated
with line 6.

DWARF at O1 (identical at O2/O3, only addresses change):
0x00a1:   DW_TAG_variable
DW_AT_abstract_origin   (0x00e2 "l_62")
DW_AT_location  (0x0020: 
   [0x004003a0, 0x004003ac): DW_OP_lit0,
DW_OP_stack_value
   [0x004003ac, 0x004003af): DW_OP_lit6,
DW_OP_stack_value)
DW_AT_unknown_2137  (0x001c)

 If we interpret the code correctly, foo1 is always
inlined/constant-propagated, while foo0 is inlined at other optimization levels
but not at -Og.


We have also tested older gcc versions (6.4, 7.5, 8.4, 9.3, 10.3, 11.1) and the
variable l_62 is always optimized out on line 6 at each optimization level.
The only exception is gcc-7 that produces (only at Og) a wrong debug
information, since at line 6 l_62 has 6 as current value.

[Bug target/105123] wrong code with -m32 -mtune=i686 and __builtin_shuffle()

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

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

--- Comment #2 from Jakub Jelinek  ---
Yeah, I'll bisect.

[Bug target/105123] wrong code with -m32 -mtune=i686 and __builtin_shuffle()

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-01
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started in between 4.8.x and 4.9.

[Bug target/105122] [12 Regression] Testsuite failures since r12-7931 on i686-linux

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

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

--- Comment #2 from Richard Biener  ---
Ah, in GCC 11 we had

/* Max number of bytes we can move from memory to memory
   in one reasonably fast instruction.  */
#define MOVE_MAX 16

while in GCC 12 it is now

/* Max number of bytes we can move from memory to memory in one
   reasonably fast instruction, as opposed to MOVE_MAX_PIECES which
   is the number of bytes at a time which we can move efficiently.
   MOVE_MAX_PIECES defaults to MOVE_MAX.  */

#define MOVE_MAX \
  ((TARGET_AVX512F \
&& (ix86_move_max == PVW_AVX512 \
|| ix86_store_max == PVW_AVX512)) \
   ? 64 \
   : ((TARGET_AVX \
   && (ix86_move_max >= PVW_AVX256 \
   || ix86_store_max >= PVW_AVX256)) \
  ? 32 \
  : ((TARGET_SSE2 \
  && TARGET_SSE_UNALIGNED_LOAD_OPTIMAL \
  && TARGET_SSE_UNALIGNED_STORE_OPTIMAL) \
 ? 16 : UNITS_PER_WORD)))

and UNITS_PER_WORD is now 4.  Not sure if that was a concious decision?

I'm not sure we want to "cheat" here.  For memcpy-6.c we have sth like

char a[32];
void fold_copy_8 (void)
{
  __builtin_memcpy (a + 3, a, 8);
}

where if we'd try to use 'long long' we'd succeed (since 'a' is properly
aligned).  We'd have to use lang_hook.types.types_for_mode to not get
too large types but even with that we'll happily use __int128_t on
i?86 with -mno-sse when copying 16 bytes.  The idea of using larger
types than MOVE_MAX was to restrict that to the cases where we do say

 __int128_t tem;
 memcpy (, a, 16);

and thus the large type is used in the source already (and is > MOVE_MAX).
Similarly for 'double' on i?86 where we'd use DImode.  For the sake
of removing abstraction.  But the gcc.dg/memcpy-6.c testcase should be
about RTL expansion (with the known lack of handling of memmmove).

Btw, lang_hooks.types.type_for_mode reveals __int128_t via

#if HOST_BITS_PER_WIDE_INT >= 64
  if (mode == TYPE_MODE (intTI_type_node))
return unsignedp ? unsigned_intTI_type_node : intTI_type_node;
#endif

even though we have

(gdb) p int_n_enabled_p
$2 = {false}
(gdb) p int_n_data[0]
$3 = {bitsize = 128, m = TImode}

of course __int128_t != unsigned __attribute__((mode(TI))), but ...

Re: [PATCH v2] Ignore zero width fields in arguments and issue -Wpsabi warning about C zero-width field ABI changes [PR102024]

[Jakub Jelinek via Gcc-patches]

On Fri, Apr 01, 2022 at 08:11:43PM +0800, Xi Ruoyao wrote:
> v1 -> v2:
> 
> * "int has_zero_width_bf_abi_change" -> "bool
> zero_width_field_abi_change".  "int" -> "bool" because it's only 0/1,
> "bf" -> "field" because the change also affects zero-length arrays and
> empty structs/unions, etc.
> 
> * Add tests with zero-length array and empty struct.
> 
> * Coding style fix.
> 
> * "#zero_width_bitfields" -> "#mips_zero_width_fields" because this is
> not the exactly same change documented by #zero_width_bitfields.  I'll
> send a wwwdoc patch after this is approved.
> 
> gcc/
>   PR target/102024
>   * mips.cc (mips_function_arg): Ignore zero-width fields, and
>   inform if it causes a psABI change.
> 
> gcc/testsuite/
>   PR target/102024
>   * gcc.target/mips/pr102024-1.c: New test.
>   * gcc.target/mips/pr102024-2.c: New test.
>   * gcc.target/mips/pr102024-3.c: New test.

LGTM, thanks.

Jakub

[Bug target/105123] New: wrong code with -m32 -mtune=i686 and __builtin_shuffle()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105123
   Summary: wrong code with -m32 -mtune=i686 and
__builtin_shuffle()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc -m32 -mtune=i686 testcase.c
$ ./a.out 
Aborted

v[] is { 0, 0, 0, 0 }

$ 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-7935-20220331110233-g90533de067d-checking-yes-rtl-df-extra-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
--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-7935-20220331110233-g90533de067d-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220331 (experimental) (GCC)