[Bug tree-optimization/106020] Spurious warnings about stringop overflows only with LTO

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

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

--- Comment #4 from Andrew Pinski  ---
I suspect it is warning on some unreachable code which is not optimized away
until later. Until a full testcase is attached, it is going to be hard. Also it
would be better if not using cmake, just use a makefile if needed or just a
normal shell script to describe how to compile the files (cmake adds so much
stuff to it is sometimes hard to tell if it is doing the right thing).

[Bug tree-optimization/106020] Spurious warnings about stringop overflows only with LTO

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

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

--- Comment #3 from Andrew Pinski  ---
Can you attach both files instead of the godbolt link?

[PATCH] c: Handle initializations of opaque types [PR106016]

[Peter Bergner via Gcc-patches]

The initial commit that added opaque types thought that there couldn't
be any valid initializations for variables of these types, but the test
case in the bug report shows that isn't true.  The solution is to handle
OPAQUE_TYPE initializations just like the other scalar types.

This passed bootstrap and regtesting with no regressions on powerpc64le-linux.
Ok for trunk?  This is an issue in GCC 12 and 11 too.  Ok for the release
branches after some burn-in on trunk?

Peter

gcc/
PR c/106016
* expr.cc (count_type_elements): Handle OPAQUE_TYPE.

gcc/testsuite/
PR c/106016
* gcc.target/powerpc/pr106016.c: New test.

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 78c839ab425..1675198a146 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -6423,13 +6423,13 @@ count_type_elements (const_tree type, bool for_ctor_p)
 case OFFSET_TYPE:
 case REFERENCE_TYPE:
 case NULLPTR_TYPE:
+case OPAQUE_TYPE:
   return 1;
 
 case ERROR_MARK:
   return 0;
 
 case VOID_TYPE:
-case OPAQUE_TYPE:
 case METHOD_TYPE:
 case FUNCTION_TYPE:
 case LANG_TYPE:
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106016.c 
b/gcc/testsuite/gcc.target/powerpc/pr106016.c
new file mode 100644
index 000..3db8345dcc6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr106016.c
@@ -0,0 +1,14 @@
+/* PR target/106016 */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Make sure we do not ICE on the following test case.  */
+
+extern void bar (__vector_quad *);
+
+void
+foo (__vector_quad *a, __vector_quad *b)
+{
+  __vector_quad arr[2] = {*a, *b};
+  bar ([0]);
+}

[Bug c/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

Peter Bergner  changed:

   What|Removed |Added

  Component|target  |c

--- Comment #9 from Peter Bergner  ---
This is not a target issue, so changing the Component to C.

[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi

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

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

--- Comment #4 from Segher Boessenkool  ---
(In reply to Marek Polacek from comment #0)
> It doesn't look like a wrong code problem, but it seems more optimal to use
> rldimi (rotate left, mask insert) rather than rotate left by 0 bits, AND
> with a mask, shift left, and add.

Confirmed.  The original code is much better (and yes, the current is correct
as well).

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #8 from Peter Bergner  ---
(In reply to Peter Bergner from comment #7)
> (In reply to Segher Boessenkool from comment #6)
> > Like that yes.  Pre-approved if it survives regcheck, too.  Thanks!
> > 
> > Please add the testcase as well of course :-)
> 
> Ok, bootstrap and regtests are running.

Bootstrap and regression testing were clean.

[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #1 from H.J. Lu  ---
SLP thinks that it needs 4 stores to store 4 bytes of integer constant.
But it takes only 1 4-byte store.

gcc-11-20220617 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-11-20220617.tar.xz   Complete GCC

  SHA256=78c1131f94074adc5c4478a0bb1e2b60e825ed62765c18464a4d3c205a51aced
  SHA1=9319a76782bf9b106e379b2981756c9836347885

Diffs from 11-20220610 are available in the diffs/ subdirectory.

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

[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #8 from Lewis Hyatt  ---
I submitted a patch for this here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596820.html

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[PATCH] libcpp: Support raw strings with newlines while processing directives [PR55971]

[Lewis Hyatt via Gcc-patches]

Hello-

The attached fixes PR preprocessor/55971:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971

, which is the issue that we don't currently allow raw string literals
containing embedded newlines to appear in #define. With the patch, they can be
used in any preprocessing directive.

While I was in there, I also added support for the argument to _Pragma() to be
a raw string, which was not supported (with or without newlines) previously,
but I think is nice to have.

Bootstrap + regtest all languages on x86-64 Linux looks good, with no new
failures and the new testcases passing:

FAIL 103 103
PASS 542454 542574
UNSUPPORTED 15248 15248
UNTESTED 136 136
XFAIL 4166 4166
XPASS 17 17

Please let me know if it looks OK?
Thanks!

-Lewis
[PATCH] libcpp: Support raw strings with newlines while processing directives 
[PR55971]

It's not currently possible to use a C++11 raw string containing a newline as
part of the definition of a macro, or in any other preprocessing directive,
such as:

 #define X R"(two
lines)"

 #error R"(this error has
two lines)"

This patch adds support for that by relaxing the conditions under which
_cpp_get_fresh_line() refuses to get a new line. For the case of lexing a raw
string, it's OK to do so as long as there is another line within the current
buffer. The code in cpp_get_fresh_line() was refactored into a new function
get_fresh_line_impl(), so that the new logic is applied only when processing a
raw string and not any other times.

gcc -E needed a small tweak now that it's possible to get a token from
macro expansion which contains a newline; in that case, c-ppoutput.c needs
to check and avoid incrementing its internal line counter in that case,
otherwise it erroneously prints a line change marker after printing the
expansion of a macro with an embedded newline.

I have added testcases for all preprocessing directives to make sure they are
OK with these kinds of raw strings. While doing that it became apparent that
we do not currently accept a raw string (with or without embedded newlines) as
the argument to _Pragma(). That was pretty straightforward to add, so I have
done that as well, since it seems potentially handy to avoid needing to escape
all the quotes inside the pragma, plus clang accepts this as well.

PR preprocessor/55971

libcpp/ChangeLog:

* directives.cc (destringize_and_run): Support C++11 raw strings
as the argument to _Pragma().
* lex.cc (get_fresh_line_impl): New function refactoring the code
from...
(_cpp_get_fresh_line): ...here.
(lex_raw_string): Use the new version of get_fresh_line_impl() to
support raw strings containing new lines when processing a directive.

gcc/testsuite/ChangeLog:

* c-c++-common/raw-string-directive-1.c: New test.
* c-c++-common/raw-string-directive-2.c: New test.

gcc/c-family/ChangeLog:

* c-ppoutput.cc (token_streamer::stream): Don't call
account_for_newlines() if the tokens came from macro expansion.

diff --git a/gcc/c-family/c-ppoutput.cc b/gcc/c-family/c-ppoutput.cc
index 9de46a9655f..4f3576fa273 100644
--- a/gcc/c-family/c-ppoutput.cc
+++ b/gcc/c-family/c-ppoutput.cc
@@ -292,11 +292,13 @@ token_streamer::stream (cpp_reader *pfile, const 
cpp_token *token,
   print.printed = true;
 }
 
-  /* CPP_COMMENT tokens and raw-string literal tokens can have
- embedded new-line characters.  Rather than enumerating all the
- possible token types just check if token uses val.str union
- member.  */
-  if (cpp_token_val_index (token) == CPP_TOKEN_FLD_STR)
+  /* CPP_COMMENT tokens and raw-string literal tokens can have embedded
+ new-line characters.  Rather than enumerating all the possible token
+ types, just check if token uses val.str union member.  If the token came
+ from a macro expansion, then no adjustment should be made since the
+ new-line characters did not appear in the source.  */
+  if (cpp_token_val_index (token) == CPP_TOKEN_FLD_STR
+  && !from_macro_expansion_at (loc))
 account_for_newlines (token->val.str.text, token->val.str.len);
 }
 
diff --git a/gcc/testsuite/c-c++-common/raw-string-directive-1.c 
b/gcc/testsuite/c-c++-common/raw-string-directive-1.c
new file mode 100644
index 000..810f11256fa
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/raw-string-directive-1.c
@@ -0,0 +1,77 @@
+/* { dg-do compile } */
+/* { dg-options "-std=gnu99" { target c } } */
+/* { dg-options "-std=c++11" { target c++ } } */
+
+/* Test that multi-line raw strings are lexed OK for all preprocessing
+   directives where one could appear. Test raw-string-directive-2.c
+   checks that #define is also processed properly.  */
+
+/* Note that in cases where we cause GCC to produce a multi-line error
+   message, we construct the string so that the second line looks enough
+   like an error message for DejaGNU to process it as such, so that we
+   can use dg-warning or dg-error directives to check for it.  */
+

Re: [RFC] analyzer: allocation size warning

[David Malcolm via Gcc]

On Fri, 2022-06-17 at 22:23 +0200, Tim Lange wrote:
> On Fri, Jun 17, 2022 at 01:48:09PM -0400, David Malcolm wrote:
> > On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote:

[...snip...]

> > 
> 
> I have resent the patch using git send-email as a reply to my original
> message. 
> The new message looks properly formatted in the archive:
>     https://gcc.gnu.org/pipermail/gcc/2022-June/238911.html

Thanks; that's *much* more readable.


[...snip...]

> > 
> > 
> > 
> > On symbolic buffer sizes:
> > warning: Allocated buffer size is not a multiple of the pointee's
> > size 
> > [CWE-131] [-Wanalyzer-allocation-size]
> >    33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3 }
> > */
> >   | ^~~~
> >   ‘test_3’: event 1
> >     |
> >     | 33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3
> > } 
> > */
> >     | | ^~~~
> >     | | |
> >     | | (1) Allocation is incompatible with ‘int *’; either the 
> > allocated size is bogus or the type on the left-hand side is wrong
> >     |
> > 
> > 
> > Is there location information for both the malloc and for the
> > assignment, here?
> 
> I'm not sure whether I understand your question but the warning is 
> emitted at the gcall* with a ssa var lhs and the call_fndecl on the
> rhs.
> I think that is enough to split that up into "(1) n + sizeof(int) 
> allocated here" and "(2) Allocation at (1) is incompatible with..."? 

Probably, yes.

FWIW I wrote some more notes about the events in my reply to to your
reply to Prathamesh, here:
  https://gcc.gnu.org/pipermail/gcc/2022-June/238917.html

[...snip...]

> > 
> > There are some things to discuss from my side:
> > * The tests with the "toy re-implementation of CPython's object 
> > model"[2] fail due to a extra warning emitted. Because the analyzer
> > can't know the calculation actually results in a correct buffer size 
> > when viewed as a string_obj later on, it emits a warning, e.g. at
> > line 
> > 61 in data-model-5.c. The only mitigation would be to disable the 
> > warning for structs entirely. Now, the question is to rather have
> > noise
> > on these cases or disable the warning for structs entirely?
> > 
> > Can you post the full warning please?
> 
> /path/to/data-model-5.c: In function ‘alloc_obj’:
> /path/to/data-model-5.c:61:31: warning: Allocated buffer size is not a
> multiple of the pointee's size [CWE-131] [-Wanalyzer-allocation-size]
>    61 |   base_obj *obj = (base_obj *)malloc (sz);
>   |   ^~~
>   ‘new_string_obj’: events 1-2
>     |
>     |   69 | base_obj *new_string_obj (const char *str)
>     |  |   ^~
>     |  |   |
>     |  |   (1) entry to ‘new_string_obj’
>     |..
>     |   75 | = (string_obj *)alloc_obj (_type, sizeof
> (string_obj) + len + 1);
>     |  |
> 
>     |  | |
>     |  | (2) calling ‘alloc_obj’ from
> ‘new_string_obj’
>     |
>     +--> ‘alloc_obj’: events 3-4
>    |
>    |   59 | base_obj *alloc_obj (type_obj *ob_type, size_t sz)
>    |  |   ^
>    |  |   |
>    |  |   (3) entry to ‘alloc_obj’
>    |   60 | {
>    |   61 |   base_obj *obj = (base_obj *)malloc (sz);
>    |  |   ~~~
>    |  |   |
>    |  |   (4) Allocation is
> incompatible with ‘base_obj *’; either the allocated size is bogus or
> the type on the left-hand side is wrong
>    |
> 
> > 
> > These testcases exhibit a common way of faking inheritance in C, and
> > I
> > think it ought to be possible to support this in the warning.
> > 
> > I thing what's happening is we have
> > 
> > struct base
> > { 
> >   /* fields */
> > };
> > 
> > struct sub
> > {
> >   struct base m_base;
> >   /* extra fields.  */
> > };
> > 
> > struct base *construct_base (size_t sz)
> > {
> >   struct base *p = (struct base *) malloc (sz);
> > 
> >   /* set up fields of base in p  */
> > 
> >   return p;
> > }
> > 
> > Or is this on the interprocedural path as called with a specific
> > sizeof
> > for struct sub?
> 
> At (4), it does not know that base_obj is later used as a "base
> struct". 
> As it is called with sizeof(struct sub), my checker thinks the buffer
> is
> too large for one but too small for another base_obj.
> 
> > 
> > Maybe we can special-case these by detecting where struct sub's first
> > field is struct base, and hence where we expect this pattern?  (and
> > use
> > this to suppress the warning for such cases?)
> 
> I already excluded all structs with structs inside with 
> struct_or_union_with_inheritance_p inside sm-malloc.cc. This does not
> help 
> in the case size for struct sub is allocated but 

[Bug target/106022] New: [12/13 Regression] Enable vectorizer generates extra load

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 106022
   Summary: [12/13 Regression] Enable vectorizer generates extra
load
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
  Target Milestone: ---

[hjl@gnu-clx-1 gcc-bisect]$ cat x.c
void foo(char * c) {
c[0] = 0;
c[1] = 1;
c[2] = 2;
c[3] = 3;
}
[hjl@gnu-clx-1 gcc-bisect]$ gcc -O3 x.c -S
[hjl@gnu-clx-1 gcc-bisect]$ cat x.s 
.file   "x.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl.LC0(%rip), %eax
movl%eax, (%rdi)
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.section.rodata.cst4,"aM",@progbits,4
.align 4
.LC0:
.byte   0
.byte   1
.byte   2
.byte   3
.ident  "GCC: (GNU) 12.1.1 20220507 (Red Hat 12.1.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-clx-1 gcc-bisect]$ gcc -O3 x.c -S -fno-tree-vectorize
[hjl@gnu-clx-1 gcc-bisect]$ cat x.s
.file   "x.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl$50462976, (%rdi)
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 12.1.1 20220507 (Red Hat 12.1.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-clx-1 gcc-bisect]$ /usr/gcc-11.2.1-x32/bin/gcc -S -O3 x.c 
[hjl@gnu-clx-1 gcc-bisect]$ cat x.s
.file   "x.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl$50462976, (%rdi)
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 11.2.1 20220118"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-clx-1 gcc-bisect]$

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #7 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #6)
> Like that yes.  Pre-approved if it survives regcheck, too.  Thanks!
> 
> Please add the testcase as well of course :-)

Ok, bootstrap and regtests are running.

Re: [RFC] analyzer: allocation size warning

[David Malcolm via Gcc]

On Fri, 2022-06-17 at 21:23 +0200, Tim Lange wrote:
> 
> 
> On Fr, Jun 17 2022 at 22:45:42 +0530, Prathamesh Kulkarni 
>  wrote:
> > On Fri, 17 Jun 2022 at 21:25, Tim Lange  wrote:
> > > 
> > >  Hi everyone,
> > Hi Tim,
> > Thanks for posting the POC patch!
> > Just a couple of comments (inline)
> Hi Prathamesh,
> thanks for looking at it.
> > > 
> > >  tracked in PR105900 [0], I'd like to add support for a new warning
> > > on
> > >  dubious allocation sizes. The new checker emits a warning when the
> > >  allocation size is not a multiple of the type's size. With the 
> > > checker,
> > >  following mistakes are detected:
> > >    int *arr = malloc(3); // forgot to multiply by sizeof
> > >    arr[0] = ...;
> > >    arr[1] = ...;
> > >  or
> > >    int *buf = malloc (n + sizeof(int)); // probably should be * 
> > > instead
> > >  of +
> > >  Because it is implemented inside the analyzer, it also emits 
> > > warnings
> > >  when the buffer is first of type void* and later on casted to 
> > > something
> > >  else. Though, this also inherits a limitation. The checker can not
> > >  distinguish 2 * sizeof(short) from sizeof(int) because sizeof is
> > >  resolved and constants are folded at the point when the analyzer
> > > runs.
> > >  As a mitigation, I plan to implement a check in the frontend that 
> > > emits
> > >  a warning if sizeof(lhs pointee type) is not part of the malloc
> > >  argument.
> > IMHO, warning if sizeof(lhs pointee_type) is not present inside
> > malloc, might not be a good idea because it
> > would reject valid calls to malloc.
> > For eg:
> > (1)
> > size_t size = sizeof(int);
> > int *p = malloc (size);
> > 
> > (2)
> > void *p = malloc (sizeof(int));
> > int *q = p;
> Hm, that's right. Maybe only warn when there is a sizeof(type) in the
> argument and the lhs pointee_type != type (except for void*, maybe 
> char* and "inherited" structs)?

That sounds plausible.


[...snip...]

> > > 
> > Won't the warning be incorrect if 'n' is a multiple of sizeof(int) ?
> > I assume by symbolic buffer size, 'n' is not known at compile time.
> * VLAs are resolved to n * `sizeof(type) when the analyzer runs and
> work 
> fine.

Great - and please make sure the test suite has test coverage for
anything we're talking about!


IIRC, VLAs work using __builtin_alloca, rather than malloc, and the new
diagnostic is currently implemented as an extension of the sm-malloc.cc
code, so I don't think it could fire anyway for a __builtin_alloca. 
Does it fire for:

  int *ptr = alloca (sizeof (short)); // BUG: sizeof(short) != sizeof(int), 
probably


There are two places in the analyzer that are tracking memory
allocations:
(a) the sm-malloc.cc code, and
(b) in the region_model's m_dynamic_extents hash_map, which tracks a
symbolic value for the size of each reachable dynamically-allocated
region (and inhibits merging of exploded_nodes that have different
dynamic extents).

See
  region_model::set_dynamic_extents
and
  region_model::get_dynamic_extents

These are called by:
  region_model::create_region_for_alloca
and
  region_model::create_region_for_heap_alloc
and:
  region_model::impl_call_realloc

My gut feeling is that the diagnostic would work better implemented in
terms of (b), rather than (a).  If you test in region_model::set_value,
rather than in a state machine, the test could use the dynamic-extent
tracking of region_model (and thus work e.g. with alloca and realloc,
see the example above), and could also be extended to catch assignments
to pointers from statically-allocated regions of the wrong size e.g.:

  char buf[2];
  int *ptr = (int *)buf; // BUG: sizeof(buf) is only 2 bytes

  short s;
  int *ptr = (int *) // BUG: sizeof(short) != sizeof(int), probably


diagnostic_manager::add_events_for_eedge already has some code that
will add a region_creation_event to the checker_path for the case where
a region is determined to be the one of interest to the diagnostic,

See e.g.
poisoned_value_diagnostic::mark_interesting_stuff, which indicates the
region of interest, which is how we get event (1) in the following for
an alloca:

../../src/gcc/testsuite/gcc.dg/analyzer/uninit-alloca.c: In function ‘test_1’:
../../src/gcc/testsuite/gcc.dg/analyzer/uninit-alloca.c:6:10: warning: use of 
uninitialized 
  value ‘*p’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
6 |   return *p; /* { dg-warning "use of uninitialized value '\\*p'" } */
  |  ^~
  ‘test_1’: events 1-2
|
|5 |   int *p = __builtin_alloca (sizeof (int));
|  |^~~
|  ||
|  |(1) region created on stack here
|6 |   return *p;
|  |  ~~ 
|  |  |
|  |  (2) use of uninitialized value ‘*p’ here
|

and event (1) for a statically-sized variable here:

../../src/gcc/testsuite/gcc.dg/analyzer/uninit-1.c: In function ‘test_1’:

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

[Ian Lance Taylor via Gcc-patches]

On Tue, May 31, 2022 at 12:41 PM Sören Tempel  wrote:
>
> PING.
>
> If there is anything else that needs to be addressed please let me know.

Thanks.  Committed as follows.  Sorry for the delay.

Ian
e584afe7976a40df42eed4df6ce6852abab74030
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 0cda305c648..4b75dd37355 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-8db6b78110f84e22c409f334aeaefb80a8b39917
+a409e049737ec9a358a19233e017d957db3d6d2a
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 7e2b98ba67c..bac58b07b41 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -579,7 +579,7 @@ AC_C_BIGENDIAN
 
 GCC_CHECK_UNWIND_GETIPINFO
 
-AC_CHECK_HEADERS(port.h sched.h semaphore.h sys/file.h sys/mman.h syscall.h 
sys/epoll.h sys/event.h sys/inotify.h sys/ptrace.h sys/syscall.h sys/sysctl.h 
sys/user.h sys/utsname.h sys/select.h sys/socket.h net/bpf.h net/if.h 
net/if_arp.h net/route.h netpacket/packet.h sys/prctl.h sys/mount.h sys/vfs.h 
sys/statfs.h sys/timex.h sys/sysinfo.h utime.h linux/ether.h linux/fs.h 
linux/ptrace.h linux/reboot.h netinet/in_syst.h netinet/ip.h 
netinet/ip_mroute.h netinet/if_ether.h lwp.h)
+AC_CHECK_HEADERS(fcntl.h port.h sched.h semaphore.h sys/file.h sys/mman.h 
syscall.h sys/epoll.h sys/event.h sys/inotify.h sys/ptrace.h sys/syscall.h 
sys/sysctl.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/bpf.h 
net/if.h net/if_arp.h net/route.h netpacket/packet.h sys/prctl.h sys/mount.h 
sys/vfs.h sys/statfs.h sys/timex.h sys/sysinfo.h utime.h linux/ether.h 
linux/fs.h linux/ptrace.h linux/reboot.h netinet/in_syst.h netinet/ip.h 
netinet/ip_mroute.h netinet/if_ether.h lwp.h)
 
 AC_CHECK_HEADERS([netinet/icmp6.h], [], [],
 [#include 
@@ -601,7 +601,11 @@ AC_STRUCT_DIRENT_D_TYPE
 
 AC_CHECK_FUNCS(accept4 dup3 epoll_create1 faccessat fallocate fchmodat 
fchownat futimesat getxattr inotify_add_watch inotify_init inotify_init1 
inotify_rm_watch listxattr mkdirat mknodat open64 openat pipe2 removexattr 
renameat setxattr sync_file_range splice syscall tee unlinkat unshare utimensat)
 AC_TYPE_OFF_T
-AC_CHECK_TYPES([loff_t])
+
+CFLAGS_hold="$CFLAGS"
+CFLAGS="$OSCFLAGS $CFLAGS"
+AC_CHECK_TYPES([loff_t], [], [], [[#include ]])
+CFLAGS="$CFLAGS_hold"
 
 LIBS_hold="$LIBS"
 LIBS="$LIBS -lm"
diff --git a/libgo/go/syscall/libcall_linux.go 
b/libgo/go/syscall/libcall_linux.go
index 7bec2fbaeb5..19ae4393cf1 100644
--- a/libgo/go/syscall/libcall_linux.go
+++ b/libgo/go/syscall/libcall_linux.go
@@ -210,20 +210,20 @@ func Gettid() (tid int) {
 //sys  Setxattr(path string, attr string, data []byte, flags int) (err error)
 //setxattr(path *byte, name *byte, value *byte, size Size_t, flags _C_int) 
_C_int
 
-//sys  splice(rfd int, roff *_loff_t, wfd int, woff *_loff_t, len int, flags 
int) (n int64, err error)
-//splice(rfd _C_int, roff *_loff_t, wfd _C_int, woff *_loff_t, len Size_t, 
flags _C_uint) Ssize_t
+//sys  splice(rfd int, roff *_libgo_loff_t_type, wfd int, woff 
*_libgo_loff_t_type, len int, flags int) (n int64, err error)
+//splice(rfd _C_int, roff *_libgo_loff_t_type, wfd _C_int, woff 
*_libgo_loff_t_type, len Size_t, flags _C_uint) Ssize_t
 
 func Splice(rfd int, roff *int64, wfd int, woff *int64, len int, flags int) (n 
int64, err error) {
-   var lroff _loff_t
-   var plroff *_loff_t
+   var lroff _libgo_loff_t_type
+   var plroff *_libgo_loff_t_type
if roff != nil {
-   lroff = _loff_t(*roff)
+   lroff = _libgo_loff_t_type(*roff)
plroff = 
}
-   var lwoff _loff_t
-   var plwoff *_loff_t
+   var lwoff _libgo_loff_t_type
+   var plwoff *_libgo_loff_t_type
if woff != nil {
-   lwoff = _loff_t(*woff)
+   lwoff = _libgo_loff_t_type(*woff)
plwoff = 
}
n, err = splice(rfd, plroff, wfd, plwoff, len, flags)
diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
index 0c52ea5d71a..5aa309155c3 100755
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -403,11 +403,7 @@ fi
 # Some basic types.
 echo 'type Size_t _size_t' >> ${OUT}
 echo "type Ssize_t _ssize_t" >> ${OUT}
-if grep '^const _HAVE_OFF64_T = ' gen-sysinfo.go > /dev/null 2>&1; then
-  echo "type Offset_t _off64_t" >> ${OUT}
-else
-  echo "type Offset_t _off_t" >> ${OUT}
-fi
+echo "type Offset_t _libgo_off_t_type" >> ${OUT}
 echo "type Mode_t _mode_t" >> ${OUT}
 echo "type Pid_t _pid_t" >> ${OUT}
 echo "type Uid_t _uid_t" >> ${OUT}
diff --git a/libgo/sysinfo.c b/libgo/sysinfo.c
index 8ce061e2f5f..a4259c02ded 100644
--- a/libgo/sysinfo.c
+++ b/libgo/sysinfo.c
@@ -357,6 +357,18 @@ enum {
 };
 #endif
 
+#if defined(HAVE_LOFF_T)
+// loff_t can be defined as a macro; for -fgo-dump-spec make sure we
+// see a typedef.
+typedef loff_t libgo_loff_t_type;
+#endif
+
+#if defined(HAVE_OFF64_T)
+typedef off64_t 

[Bug analyzer/106021] New: RFE: more sources of taint: scanf and its cousins

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

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

Bug ID: 106021
   Summary: RFE: more sources of taint: scanf and its cousins
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

scanf and its cousins should taint their arguments:

   #include 

   int scanf(const char *format, ...);
   int fscanf(FILE *stream, const char *format, ...);
   int sscanf(const char *str, const char *format, ...);

   #include 

   int vscanf(const char *format, va_list ap);
   int vsscanf(const char *str, const char *format, va_list ap);
   int vfscanf(FILE *stream, const char *format, va_list ap);

Possibly add/reuse an attribute for this, or hardcode it.

Additionally, we should probably "teach" the analyzer about the semantics of
them (possibly by refactoring the -Wformat code?)

[PATCH RFA] ubsan: do return check with -fsanitize=unreachable

[Jason Merrill via Gcc-patches]

Related to PR104642, the current situation where we get less return checking
with just -fsanitize=unreachable than no sanitize flags seems undesirable; I
propose that we do return checking when -fsanitize=unreachable.

Looks like clang just traps on missing return if not -fsanitize=return, but
the approach in this patch seems more helpful to me if we're already
sanitizing other should-be-unreachable code.

I'm assuming that the difference in treatment of SANITIZE_UNREACHABLE and
SANITIZE_RETURN with regard to loop optimization is deliberate.

This assumes Jakub's -fsanitize-trap patch.

gcc/ChangeLog:

* doc/invoke.texi: Note that -fsanitize=unreachable implies
-fsanitize=return.
* opts.cc (finish_options): Make that so.

gcc/cp/ChangeLog:

* cp-gimplify.cc (cp_maybe_instrument_return): Remove
return vs. unreachable handling.

gcc/testsuite/ChangeLog:

* g++.dg/ubsan/return-8c.C: New test.
---
 gcc/doc/invoke.texi|  2 ++
 gcc/cp/cp-gimplify.cc  | 12 
 gcc/opts.cc| 10 ++
 gcc/testsuite/g++.dg/ubsan/return-8c.C | 15 +++
 4 files changed, 27 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ubsan/return-8c.C

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 50f57877477..e572158a1ba 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15946,6 +15946,8 @@ built with this option turned on will issue an error 
message
 when the end of a non-void function is reached without actually
 returning a value.  This option works in C++ only.
 
+This check is also enabled by -fsanitize=unreachable.
+
 @item -fsanitize=signed-integer-overflow
 @opindex fsanitize=signed-integer-overflow
 This option enables signed integer overflow checking.  We check that
diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index 6f84d157c98..5c2eb61842c 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1806,18 +1806,6 @@ cp_maybe_instrument_return (tree fndecl)
   || !targetm.warn_func_return (fndecl))
 return;
 
-  if (!sanitize_flags_p (SANITIZE_RETURN, fndecl)
-  /* Don't add __builtin_unreachable () if not optimizing, it will not
-improve any optimizations in that case, just break UB code.
-Don't add it if -fsanitize=unreachable -fno-sanitize=return either,
-UBSan covers this with ubsan_instrument_return above where sufficient
-information is provided, while the __builtin_unreachable () below
-if return sanitization is disabled will just result in hard to
-understand runtime error without location.  */
-  && (!optimize
- || sanitize_flags_p (SANITIZE_UNREACHABLE, fndecl)))
-return;
-
   tree t = DECL_SAVED_TREE (fndecl);
   while (t)
 {
diff --git a/gcc/opts.cc b/gcc/opts.cc
index 062782ac700..a7b02b0f693 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -1254,6 +1254,16 @@ finish_options (struct gcc_options *opts, struct 
gcc_options *opts_set,
   if (opts->x_flag_sanitize & ~(SANITIZE_LEAK | SANITIZE_UNREACHABLE))
 opts->x_flag_aggressive_loop_optimizations = 0;
 
+  /* -fsanitize=unreachable implies -fsanitize=return, but without affecting
+  aggressive loop optimizations.  */
+  if ((opts->x_flag_sanitize & (SANITIZE_UNREACHABLE | SANITIZE_RETURN))
+  == SANITIZE_UNREACHABLE)
+{
+  opts->x_flag_sanitize |= SANITIZE_RETURN;
+  if (opts->x_flag_sanitize_trap & SANITIZE_UNREACHABLE)
+   opts->x_flag_sanitize_trap |= SANITIZE_RETURN;
+}
+
   /* Enable -fsanitize-address-use-after-scope if either address sanitizer is
  enabled.  */
   if (opts->x_flag_sanitize
diff --git a/gcc/testsuite/g++.dg/ubsan/return-8c.C 
b/gcc/testsuite/g++.dg/ubsan/return-8c.C
new file mode 100644
index 000..a67f086d452
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ubsan/return-8c.C
@@ -0,0 +1,15 @@
+// PR c++/104642
+
+// -fsanitize=unreachable should imply -fsanitize=return.
+
+// { dg-do run }
+// { dg-shouldfail { *-*-* } }
+// { dg-additional-options "-O -fsanitize=unreachable" }
+
+bool b;
+
+int f() {
+  if (b) return 42;
+} // { dg-warning "-Wreturn-type" }
+
+int main() { f(); }

base-commit: 0f96ac43fa0a5fdbfce317b274233852d5b46d23
prerequisite-patch-id: fa35013a253eae78fe744794172aeed26fe6f166
-- 
2.27.0

[Bug lto/106020] Spurious warnings about stringop overflows only with LTO

[matt at godbolt dot org via Gcc-bugs]

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

--- Comment #2 from Matt Godbolt  ---
There are many hundreds of similar errors in that example; perhaps this example
is more of a clue:

/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/move.h:205:11:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  205 |   __a = _GLIBCXX_MOVE(__b);

(which seems very suspicious, size 0 inside std::move?)

[Bug lto/106020] Spurious warnings about stringop overflows only with LTO

[matt at godbolt dot org via Gcc-bugs]

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

--- Comment #1 from Matt Godbolt  ---
Apologies for the unreduced issue, if I get a chance I'll try and shorten it,
but I hoped someone might recognise what the issue is from just this.

[Bug lto/106020] New: Spurious warnings about stringop overflows only with LTO

[matt at godbolt dot org via Gcc-bugs]

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

Bug ID: 106020
   Summary: Spurious warnings about stringop overflows only with
LTO
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at godbolt dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

When using Howard Hinnant's date library, and GCC 12.1 on x86, and then with
LTO enabled, there are many apparently spurious errors after the read.constprop
pass:

/opt/compiler-explorer/libs/date/v3.0.1/include/date/date.h: In function
'read.constprop':
/opt/compiler-explorer/libs/date/v3.0.1/include/date/date.h:6506:15: note:
destination object 'buf' of size 11
 6506 | CharT buf[std::numeric_limits::digits10+2u] = {};

It has proven tricky to get a smaller case but https://godbolt.org/z/hPaqz7TY1
demonstrates it with an inline version of date.h - a smaller version that
doesn't inline the date library is https://godbolt.org/z/e75YG6ano and the code
amounts to:

std::chrono::system_clock::time_point parse_datetime(const std::string ) {
std::istringstream ss{sv};
std::chrono::system_clock::time_point tp;
ss >> date::parse("%FT%T%Z", tp); // ignoring errors for simplicity
return tp;
}

(though it has to be linked in a separate TU with LTO enabled to trigger the
issues).

I initially filed this as a bug in the date library itself:
https://github.com/HowardHinnant/date/issues/740 but we now believe this is a
compiler issue.

Compiling with GCC 11 or earlier, or with clang, or without LTO doesn't trigger
these warnings.

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

--- Comment #6 from Segher Boessenkool  ---
FWIW, reinterpret_cast allows exactly the same things as C casts (but with the
obvious C++ extensions: member objects, member functions, C++'s concept of
lvalue, that kins of thing).  It is not similar to bit_cast at all.

Re: [PATCH]middle-end Add optimized float addsub without needing VEC_PERM_EXPR.

[Andrew Pinski via Gcc-patches]

On Thu, Jun 16, 2022 at 3:59 AM Tamar Christina via Gcc-patches
 wrote:
>
> Hi All,
>
> For IEEE 754 floating point formats we can replace a sequence of alternative
> +/- with fneg of a wider type followed by an fadd.  This eliminated the need 
> for
> using a permutation.  This patch adds a math.pd rule to recognize and do this
> rewriting.

I don't think this is correct. You don't check the format of the
floating point to make sure this is valid (e.g. REAL_MODE_FORMAT's
signbit_rw/signbit_ro field).
Also would just be better if you do the xor in integer mode (using
signbit_rw field for the correct bit)?
And then making sure the target optimizes the xor to the neg
instruction when needed?

Thanks,
Andrew Pinski



>
> For
>
> void f (float *restrict a, float *restrict b, float *res, int n)
> {
>for (int i = 0; i < (n & -4); i+=2)
> {
>   res[i+0] = a[i+0] + b[i+0];
>   res[i+1] = a[i+1] - b[i+1];
> }
> }
>
> we generate:
>
> .L3:
> ldr q1, [x1, x3]
> ldr q0, [x0, x3]
> fnegv1.2d, v1.2d
> faddv0.4s, v0.4s, v1.4s
> str q0, [x2, x3]
> add x3, x3, 16
> cmp x3, x4
> bne .L3
>
> now instead of:
>
> .L3:
> ldr q1, [x0, x3]
> ldr q2, [x1, x3]
> faddv0.4s, v1.4s, v2.4s
> fsubv1.4s, v1.4s, v2.4s
> tbl v0.16b, {v0.16b - v1.16b}, v3.16b
> str q0, [x2, x3]
> add x3, x3, 16
> cmp x3, x4
> bne .L3
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Thanks to George Steed for the idea.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * match.pd: Add fneg/fadd rule.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/simd/addsub_1.c: New test.
> * gcc.target/aarch64/sve/addsub_1.c: New test.
>
> --- inline copy of patch --
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 
> 51b0a1b562409af535e53828a10c30b8a3e1ae2e..af1c98d4a2831f38258d6fc1bbe811c8ee6c7c6e
>  100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -7612,6 +7612,49 @@ and,
>(simplify (reduc (op @0 VECTOR_CST@1))
>  (op (reduc:type @0) (reduc:type @1
>
> +/* Simplify vector floating point operations of alternating sub/add pairs
> +   into using an fneg of a wider element type followed by a normal add.
> +   under IEEE 754 the fneg of the wider type will negate every even entry
> +   and when doing an add we get a sub of the even and add of every odd
> +   elements.  */
> +(simplify
> + (vec_perm (plus:c @0 @1) (minus @0 @1) VECTOR_CST@2)
> + (if (!VECTOR_INTEGER_TYPE_P (type) && !BYTES_BIG_ENDIAN)
> +  (with
> +   {
> + /* Build a vector of integers from the tree mask.  */
> + vec_perm_builder builder;
> + if (!tree_to_vec_perm_builder (, @2))
> +   return NULL_TREE;
> +
> + /* Create a vec_perm_indices for the integer vector.  */
> + poly_uint64 nelts = TYPE_VECTOR_SUBPARTS (type);
> + vec_perm_indices sel (builder, 2, nelts);
> +   }
> +   (if (sel.series_p (0, 2, 0, 2))
> +(with
> + {
> +   machine_mode vec_mode = TYPE_MODE (type);
> +   auto elem_mode = GET_MODE_INNER (vec_mode);
> +   auto nunits = exact_div (GET_MODE_NUNITS (vec_mode), 2);
> +   tree stype;
> +   switch (elem_mode)
> +{
> +case E_HFmode:
> +  stype = float_type_node;
> +  break;
> +case E_SFmode:
> +  stype = double_type_node;
> +  break;
> +default:
> +  return NULL_TREE;
> +}
> +   tree ntype = build_vector_type (stype, nunits);
> +   if (!ntype)
> +return NULL_TREE;
> + }
> + (plus (view_convert:type (negate (view_convert:ntype @1))) @0))
> +
>  (simplify
>   (vec_perm @0 @1 VECTOR_CST@2)
>   (with
> diff --git a/gcc/testsuite/gcc.target/aarch64/simd/addsub_1.c 
> b/gcc/testsuite/gcc.target/aarch64/simd/addsub_1.c
> new file mode 100644
> index 
> ..1fb91a34c421bbd2894faa0dbbf1b47ad43310c4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_1.c
> @@ -0,0 +1,56 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target arm_v8_2a_fp16_neon_ok } */
> +/* { dg-options "-Ofast" } */
> +/* { dg-add-options arm_v8_2a_fp16_neon } */
> +/* { dg-final { check-function-bodies "**" "" "" { target { le } } } } */
> +
> +#pragma GCC target "+nosve"
> +
> +/*
> +** f1:
> +** ...
> +** fnegv[0-9]+.2d, v[0-9]+.2d
> +** faddv[0-9]+.4s, v[0-9]+.4s, v[0-9]+.4s
> +** ...
> +*/
> +void f1 (float *restrict a, float *restrict b, float *res, int n)
> +{
> +   for (int i = 0; i < (n & -4); i+=2)
> +{
> +  res[i+0] = a[i+0] + b[i+0];
> +  res[i+1] = a[i+1] - b[i+1];
> +}
> +}
> +
> +/*
> +** d1:
> +** ...
> +** fnegv[0-9]+.4s, v[0-9]+.4s
> +** faddv[0-9]+.8h, v[0-9]+.8h, v[0-9]+.8h
> +** ...
> +*/
> +void d1 (_Float16 *restrict a, _Float16 

Re: [RFC] analyzer: allocation size warning

[Tim Lange]

On Fri, Jun 17, 2022 at 01:48:09PM -0400, David Malcolm wrote:
> On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote:
> > Hi everyone,
> 
> Hi Tim.
> 
> Thanks for the patch.
> 
> Various comments inline below, throughout...
> 
> > 
> > tracked in PR105900 [0], I'd like to add support for a new warning on
> > dubious allocation sizes. The new checker emits a warning when the 
> > allocation size is not a multiple of the type's size. With the checker,
> > following mistakes are detected:
> >   int *arr = malloc(3); // forgot to multiply by sizeof
> >   arr[0] = ...;
> >   arr[1] = ...;
> > or
> >   int *buf = malloc (n + sizeof(int)); // probably should be * instead 
> > of +
> > Because it is implemented inside the analyzer, it also emits warnings
> > when the buffer is first of type void* and later on casted to something
> > else. Though, this also inherits a limitation. The checker can not 
> > distinguish 2 * sizeof(short) from sizeof(int) because sizeof is 
> > resolved and constants are folded at the point when the analyzer runs. 
> > As a mitigation, I plan to implement a check in the frontend that emits
> > a warning if sizeof(lhs pointee type) is not part of the malloc 
> > argument.
> > 
> > I'm looking for a first feedback on the phrasing of the diagnostics as 
> > well on the preliminary patch [1].
> > 
> > On constant buffer sizes, the warnings looks like this:
> > warning: Allocated buffer size is not a multiple of the pointee's size 
> > [CWE-131] [-Wanalyzer-allocation-size]
> >    22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } */
> >   | ^
> >   ‘test_2’: event 1
> >     |
> >     | 22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 }
> > */
> >     | | ^
> >     | | |
> >     | | (1) Casting a 14 byte buffer to ‘int *’ leaves 2 trailing 
> > bytes; either the allocated size is bogus or the type on the left-hand 
> > side is wrong
> >     |
> 
> Something strange seems to have happened with the indentation in your
> email; the code in the patch seems to me to be strangely indented, and
> looking at the archive here:
>   https://gcc.gnu.org/pipermail/gcc/2022-June/238907.html
> I see the same thing, so I think it's a problem with what the mailing
> list received, rather than just in my mail client.  Maybe something 
> 
> FWIW I normally use "git send-email" to send patches.
> 
> The underlinings in the above look strange; I see this in your email:

I have resent the patch using git send-email as a reply to my original message. 
The new message looks properly formatted in the archive:
https://gcc.gnu.org/pipermail/gcc/2022-June/238911.html

> 
> warning: Allocated buffer size is not a multiple of the pointee's size 
> [CWE-131] [-Wanalyzer-allocation-size]
>22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } */
>   | ^
>   ‘test_2’: event 1
> |
> | 22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } 
> */
> | | ^
> | | |
> | | (1) Casting a 14 byte buffer to ‘int *’ leaves 2 trailing 
> bytes; either the allocated size is bogus or the type on the left-hand 
> side is wrong
> |
> 
> Should it have been (omitting the dg-line directives for clarity):
> 
> warning: Allocated buffer size is not a multiple of the pointee's size  
> [CWE-131] [-Wanalyzer-allocation-size]
>22 | int *ptr = malloc (10 + sizeof(int));
>   |^
>   ‘test_2’: event 1
> |
> | 22 | int *ptr = malloc (10 + sizeof(int));
> ||^
> |||
> ||(1) Casting a 14 byte buffer to ‘int *’ leaves 2 
> trailing bytes; either the allocated size is bogus or the type on the 
> left-hand side is wrong
> |
> 
> ?
> 
> It looks like something somewhere has collapsed repeated whitespace in
> the message down to single spaces, which has broken the ASCII art in
> your examples, and the indentation in your code.
> 
> 
> It would probably be helpful for the message to tell the user what
> sizeof(*ptr) is,  sizeof(int) in this case (much more helpful when it's
> a struct)
> 
> Maybe something alike:
> 
> note: a buffer of 14 bytes is allocated...
> note: ...but sizeof (int) is 4 bytes...
> note: ...leaving 2 trailing bytes for an array of 3 'int's (which would
> occupy 12 bytes)
> 
> or somesuch???
> 
> I'm brainstorming here, my ideas above aren't necessarily good. 
> Sometimes it's good to chop up messages like this, to minimize
> combinatorial explosion for all the different cases.
> 
> 
> 
> On symbolic buffer sizes:
> warning: Allocated buffer size is not a multiple of the pointee's size 
> [CWE-131] [-Wanalyzer-allocation-size]
>    33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3 } */
>   | ^~~~
>   ‘test_3’: event 1
>     |
>     | 33 | int *ptr = malloc (n + sizeof(int)); /* { 

Re: [PATCH] alpha: Introduce target specific store_data_bypass_p function [PR105209]

[Jeff Law via Gcc-patches]

On 6/17/2022 9:22 AM, Uros Bizjak via Gcc-patches wrote:

This patch introduces alpha-specific version of store_data_bypass_p that
ignores TRAP_IF that would result in assertion failure (and internal
compiler error) in the generic store_data_bypass_p function.

While at it, also remove ev4_ist_c reservation, store_data_bypass_p
can handle the patterns with multiple sets since some time ago.

2022-06-17  Uroš Bizjak  

gcc/ChangeLog:

 PR target/105209
 * config/alpha/alpha-protos.h (alpha_store_data_bypass_p): New.
 * config/alpha/alpha.cc (alpha_store_data_bypass_p): New function.
 (alpha_store_data_bypass_p_1): Ditto.
 * config/alpha/ev4.md: Use alpha_store_data_bypass_p instead
 of generic store_data_bypass_p.
 (ev4_ist_c): Remove insn reservation.

gcc/testsuite/ChangeLog:

 PR target/105209
 * gcc.target/alpha/pr105209.c: New test.

Tested with a cross-compiler.

Pushed to master
And FWIW it'll get bootstrapped using qemu user mode emulation over the 
weekend.


http://law-sandy.freeddns.org:8080/job/alpha-linux-gnu

jeff

ps.  I think last weekend's run got aborted due to an overheated server.

Re: GSoC Blog Post 0 - GCCprefab build system

[Jonathan Wakely via Gcc]

On Fri, 17 Jun 2022 at 19:45, Bernhard Reutner-Fischer wrote:
>
> On 13 June 2022 17:26:59 CEST, Jonathan Wakely via Fortran 
>  wrote:
>
> >https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh
>
> s/[[/[/
> s/==/=/
>
> The former are deprecated or obsolescent notations of test(1) syntax, fwiw.

The former are defined by bash. If I made your change, [ $ver = ?.?.?
] would never be true, because ?.?.? is not a GCC version.

With Bash [[ $ver == ?.?.? ]] doesn't do word splitting etc. and
matches the RHS as a glob patttern, which is exactly what I want it to
do.

Re: GSoC Blog Post 0 - GCCprefab build system

[Jakub Jelinek via Gcc]

On Fri, Jun 17, 2022 at 08:45:04PM +0200, Bernhard Reutner-Fischer via Gcc 
wrote:
> PS: we should rm https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/gcc_build

No.  gcc_build is used by maintainer-scripts/gcc_release, so by killing it
you'd make gcc unreleasable.

> It was not updated since the switch to git so, apparently, nobody uses it 
> anymore (sadly, seeing who authored it).

Jakub

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #6 from Segher Boessenkool  ---
Like that yes.  Pre-approved if it survives regcheck, too.  Thanks!

Please add the testcase as well of course :-)

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

Segher Boessenkool  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #5 from Segher Boessenkool  ---
Okay, I'll handle it.

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #5 from Peter Bergner  ---
(In reply to Peter Bergner from comment #4)
> diff --git a/gcc/expr.cc b/gcc/expr.cc
> index 78c839ab425..1675198a146 100644
> --- a/gcc/expr.cc
> +++ b/gcc/expr.cc
> @@ -6423,13 +6423,13 @@ count_type_elements (const_tree type, bool
> for_ctor_p)
>  case OFFSET_TYPE:
>  case REFERENCE_TYPE:
>  case NULLPTR_TYPE:
> +case OPAQUE_TYPE:
>return 1;
>  
>  case ERROR_MARK:
>return 0;
>  
>  case VOID_TYPE:
> -case OPAQUE_TYPE:
>  case METHOD_TYPE:
>  case FUNCTION_TYPE:
>  case LANG_TYPE:

It does fix the ICE.

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #4 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #3)
> Yeah.  It should just return 1 like the other scalar types?

So the code did look for OPAQUE_TYPE and expected never to see it, so it was on
an error path.  I agree with your comment above and I'm guessing we want
something like:

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 78c839ab425..1675198a146 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -6423,13 +6423,13 @@ count_type_elements (const_tree type, bool for_ctor_p)
 case OFFSET_TYPE:
 case REFERENCE_TYPE:
 case NULLPTR_TYPE:
+case OPAQUE_TYPE:
   return 1;

 case ERROR_MARK:
   return 0;

 case VOID_TYPE:
-case OPAQUE_TYPE:
 case METHOD_TYPE:
 case FUNCTION_TYPE:
 case LANG_TYPE:

Re: [RFC] analyzer: allocation size warning

[Tim Lange]

On Fr, Jun 17 2022 at 22:45:42 +0530, Prathamesh Kulkarni 
 wrote:

On Fri, 17 Jun 2022 at 21:25, Tim Lange  wrote:


 Hi everyone,

Hi Tim,
Thanks for posting the POC patch!
Just a couple of comments (inline)

Hi Prathamesh,
thanks for looking at it.


 tracked in PR105900 [0], I'd like to add support for a new warning 
on

 dubious allocation sizes. The new checker emits a warning when the
 allocation size is not a multiple of the type's size. With the 
checker,

 following mistakes are detected:
   int *arr = malloc(3); // forgot to multiply by sizeof
   arr[0] = ...;
   arr[1] = ...;
 or
   int *buf = malloc (n + sizeof(int)); // probably should be * 
instead

 of +
 Because it is implemented inside the analyzer, it also emits 
warnings
 when the buffer is first of type void* and later on casted to 
something

 else. Though, this also inherits a limitation. The checker can not
 distinguish 2 * sizeof(short) from sizeof(int) because sizeof is
 resolved and constants are folded at the point when the analyzer 
runs.
 As a mitigation, I plan to implement a check in the frontend that 
emits

 a warning if sizeof(lhs pointee type) is not part of the malloc
 argument.

IMHO, warning if sizeof(lhs pointee_type) is not present inside
malloc, might not be a good idea because it
would reject valid calls to malloc.
For eg:
(1)
size_t size = sizeof(int);
int *p = malloc (size);

(2)
void *p = malloc (sizeof(int));
int *q = p;
Hm, that's right. Maybe only warn when there is a sizeof(type) in the 
argument and the lhs pointee_type != type (except for void*, maybe 
char* and "inherited" structs)?


 I'm looking for a first feedback on the phrasing of the diagnostics 
as

 well on the preliminary patch [1].

 On constant buffer sizes, the warnings looks like this:
 warning: Allocated buffer size is not a multiple of the pointee's 
size

 [CWE-131] [-Wanalyzer-allocation-size]
22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 
} */

   | ^
   ‘test_2’: event 1
 |
 | 22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line 
malloc2 }

 */
 | | ^
 | | |
 | | (1) Casting a 14 byte buffer to ‘int *’ leaves 2 
trailing
 bytes; either the allocated size is bogus or the type on the 
left-hand

 side is wrong
 |

 On symbolic buffer sizes:
 warning: Allocated buffer size is not a multiple of the pointee's 
size

 [CWE-131] [-Wanalyzer-allocation-size]
33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3 } 
*/

   | ^~~~
   ‘test_3’: event 1
 |
 | 33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line 
malloc3 }

 */
 | | ^~~~
 | | |
 | | (1) Allocation is incompatible with ‘int *’; either the
 allocated size is bogus or the type on the left-hand side is wrong
 |

Won't the warning be incorrect if 'n' is a multiple of sizeof(int) ?
I assume by symbolic buffer size, 'n' is not known at compile time.
* VLAs are resolved to n * sizeof(type) when the analyzer runs and work 
fine.
* Flows with if (cond) n = ...; else n = ...; are tracked by the 
analyzer with a widening_svalue and can be handled (While thinking 
about this answer, I noticed my patch is missing this case. Thanks!)
* In case of more complicated flows, the analyzer's buffer size 
tracking resorts to unknown_svalue. If any variable in an expression is 
unknown, no warning will be emitted.
* Generally, when requesting memory for a variable type, accepting an 
arbitrary number doesn't sound right. I do warn, e.g. if 'n' is a 
conjured_svalue (e.g. a from scanf call).


I think only the last case could in theory be a false-positive. I've 
noticed that this is the case when 'n' is guarded by an if making sure 
n is only a multiple of sizeof(type). In theory, I can fix this case 
too as the analysis is path-sensitive.
Do you know of some other case where 'n' might be an unknown value 
neither guarded an if condition nor resorted to 'unknown' by a 
complicated flow but still correct?


- Tim


Thanks,
Prathamesh


 And this is how a simple flow looks like:
 warning: Allocated buffer size is not a multiple of the pointee's 
size

 [CWE-131] [-Wanalyzer-allocation-size]
39 | int *iptr = (int *)ptr; /* { dg-line assign } */
   | ^~~~
   ‘test_4’: events 1-2
 |
 | 38 | void *ptr = malloc (n * sizeof (short)); /* { dg-message 
} */

 | | ^~~
 | | |
 | | (1) allocated here
 | 39 | int *iptr = (int *)ptr; /* { dg-line assign } */
 | | 
 | | |
 | | (2) ‘ptr’ is incompatible with ‘int *’; either the
 allocated size at (1) is bogus or the type on the left-hand side is
 wrong
 |

 There are some things to discuss from my side:
 * The tests with the "toy re-implementation of CPython's object
 model"[2] fail due to a extra warning emitted. Because the analyzer
 can't know the calculation actually results in a correct buffer size
 when 

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

[nemanja.i.ibm at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Nemanja Ivanovic  ---
(In reply to Peter Bergner from comment #2)
> (In reply to Segher Boessenkool from comment #1)
> > So the restriction in rs6000_invalid_conversion errors for valid C programs.
> > What was it intended to accomplish?
> 
> We do not want or allow automatic conversions between the opaque
> __vector_pair and __vector_quad types and other types and those are
> correctly disallowed there.  Conversions between those types needs to go
> through the builtins defined for that.
> 
> As for the pointer conversions tested there, I guess they came along for the
> ride?  Nemanja, do you remember the history there?  Or does LLVM allow the
> pointer conversions and it's just GCC that complains?

Yes, the desired semantics are to disallow implicit or explicit conversions
from these types to any other types. But pointer casts (presumably including
reinterpret_cast in C++) should be fair game. Clang allows these conversions.

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Richard Biener via Gcc-patches]

> Am 17.06.2022 um 19:09 schrieb Gaius Mulley via Gcc-patches 
> :
> 
> 
> New linking implementation is complete, gcc bootstraps and hello
> world links.  I'll git push the changes, then test/debug/polish and
> produce new patch sets

Great!

Thanks,
Richard 

> regards,
> Gaius

[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #5 from Lewis Hyatt  ---
I have a patch awaiting review to fix PR53431 which would fix this one too.
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html

[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"

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

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

--- Comment #4 from Lewis Hyatt  ---
*** Bug 64698 has been marked as a duplicate of this bug. ***

[Bug preprocessor/64698] preprocessor ignores #pragma GCC diagnostic when using -save-temps

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
 CC||lhyatt at gcc dot gnu.org

--- Comment #3 from Lewis Hyatt  ---
It is indeed a dup of PR53920. Also, I have a patch awaiting review for
PR53431; that fixes all 3.

*** This bug has been marked as a duplicate of bug 53920 ***

Re: GSoC Blog Post 0 - GCCprefab build system

[Bernhard Reutner-Fischer via Gcc]

On 13 June 2022 17:26:59 CEST, Jonathan Wakely via Fortran 
 wrote:

>https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh

s/[[/[/
s/==/=/

The former are deprecated or obsolescent notations of test(1) syntax, fwiw.

PS: we should rm https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/gcc_build
It was not updated since the switch to git so, apparently, nobody uses it 
anymore (sadly, seeing who authored it).

[Bug tree-optimization/105973] Wrong branch prediction for if (COND) { if(x) noreturn1(); else noreturn2(); }

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #7 from hubicka at kam dot mff.cuni.cz ---
> I can try implementing that.
That would be nice.  I think if path predictor logic hits the same
predictor both ways, it can simply predict that basic block with the
same predictor (i.e. recurse on that block).   It will need to keep
track what basic blocks were already predicted to handle cycles.

Honza

[RFC] analyzer: add allocation size warning

[Tim Lange]

I think my mail client did apply auto-wrap and reduced multiple spaces to a 
single one while doing so. Here again, the full patch as well as the ASCII
diagnostics. This should look better now.

On constant size allocations:
/path/to/allocation-size-3.c:22:14: warning: Allocated buffer size is not a 
multiple of the pointee's size [CWE-131] [-Wanalyzer-allocation-size]
   22 |   int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } */
  |  ^
  ‘test_2’: event 1
|
|   22 |   int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } */
|  |  ^
|  |  |
|  |  (1) Casting a 14 byte buffer to ‘int *’ leaves 2 
trailing bytes; either the allocated size is bogus or the type on the left-hand 
side is wrong
|

On symbolic buffer sizes:
/path/to/allocation-size-3.c:33:14: warning: Allocated buffer size is not a 
multiple of the pointee's size [CWE-131] [-Wanalyzer-allocation-size]
   33 |   int *ptr = malloc (n + sizeof (int)); /* { dg-line malloc3 } */
  |  ^
  ‘test_3’: event 1
|
|   33 |   int *ptr = malloc (n + sizeof (int)); /* { dg-line malloc3 } */
|  |  ^
|  |  |
|  |  (1) Allocation is incompatible with ‘int *’; either 
the allocated size is bogus or the type on the left-hand side is wrong
|
   
And this is how a simple flow looks like:
warning: Allocated buffer size is not a multiple of the pointee's size 
[CWE-131] [-Wanalyzer-allocation-size]
/path/to/allocation-size-2.c:39:8: warning: Allocated buffer size is not a 
multiple of the pointee's size [CWE-131] [-Wanalyzer-allocation-size]
   39 |   int *iptr = (int *)ptr; /* { dg-line assign } */
  |^~~~
  ‘test_4’: events 1-2
|
|   38 |   void *ptr = malloc (n * sizeof (short)); /* { dg-message } */
|  |   ^~~
|  |   |
|  |   (1) allocated here
|   39 |   int *iptr = (int *)ptr; /* { dg-line assign } */
|  |
|  ||
|  |(2) ‘ptr’ is incompatible with ‘int *’; either the 
allocated size at (1) is bogus or the type on the left-hand side is wrong
|

This patch adds an allocation size checker to the analyzer.
The checker warns when the tracked buffer size is not a multiple of the 
left-hand side pointee's type. This resolves PR analyzer/105900.

The patch is not yet fully tested.

gcc/analyzer/ChangeLog:

   * analyzer.opt: Add Wanalyzer-allocation-size.
   * sm-malloc.cc (class dubious_allocation_size): New pending_diagnostic 
subclass.
   (capacity_compatible_with_type): New.
   (const_operand_in_sval_p): New.
   (struct_or_union_with_inheritance_p): New.
   (check_capacity): New.
   (malloc_state_machine::on_stmt): Add calls to on_pointer_assignment.
   (malloc_state_machine::on_allocator_call): Add node to parameters and 
call to on_pointer_assignment.
   (malloc_state_machine::on_pointer_assignment): New.

gcc/testsuite/ChangeLog:

   * gcc.dg/analyzer/attr-malloc-6.c: Disabled Wanalyzer-allocation-size 
and added default implementation for FILE.
   * gcc.dg/analyzer/capacity-1.c: Added dg directives.
   * gcc.dg/analyzer/malloc-4.c: Disabled Wanalyzer-allocation-size.
   * gcc.dg/analyzer/pr96639.c: Disabled Wanalyzer-allocation-size and 
added default implementation for foo and bar.
   * gcc.dg/analyzer/allocation-size-1.c: New test.
   * gcc.dg/analyzer/allocation-size-2.c: New test.
   * gcc.dg/analyzer/allocation-size-3.c: New test.
   * gcc.dg/analyzer/allocation-size-4.c: New test.

Signed-off-by: Tim Lange 
---
 gcc/analyzer/analyzer.opt |   4 +
 gcc/analyzer/sm-malloc.cc | 363 +-
 .../gcc.dg/analyzer/allocation-size-1.c   |  54 +++
 .../gcc.dg/analyzer/allocation-size-2.c   |  44 +++
 .../gcc.dg/analyzer/allocation-size-3.c   |  48 +++
 .../gcc.dg/analyzer/allocation-size-4.c   |  39 ++
 gcc/testsuite/gcc.dg/analyzer/attr-malloc-6.c |   2 +
 gcc/testsuite/gcc.dg/analyzer/capacity-1.c|   5 +-
 gcc/testsuite/gcc.dg/analyzer/malloc-4.c  |   6 +-
 gcc/testsuite/gcc.dg/analyzer/pr96639.c   |   2 +
 10 files changed, 559 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/allocation-size-1.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/allocation-size-2.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/allocation-size-3.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/allocation-size-4.c

diff --git a/gcc/analyzer/analyzer.opt b/gcc/analyzer/analyzer.opt
index 4aea52d3a87..f213989e0bb 100644
--- a/gcc/analyzer/analyzer.opt
+++ b/gcc/analyzer/analyzer.opt
@@ -78,6 +78,10 @@ Wanalyzer-malloc-leak
 Common 

Re: [PATCH] ubsan: Add -fsanitize-trap= support

[Jason Merrill via Gcc-patches]

On 6/17/22 11:34, Jakub Jelinek via Gcc-patches wrote:

On Thu, Jun 16, 2022 at 09:32:02PM +0100, Jonathan Wakely wrote:

It looks like clang has addressed this deficiency now:

https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#usage


Thanks, that is roughly what I'd implement anyway and apparently they have
it already since 2015, we've added the -fsanitize-undefined-trap-on-error
support back in 2014 and didn't change it since then.

As a small divergence from clang, I chose -fsanitize-undefined-trap-on-error
to be a (deprecated) alias for -fsanitize-trap aka -fsanitize-trap=all
rather thn -fsanitize-trap=undefined which seems to be what clang does,
because for a deprecated option it is IMHO more important backwards
compatibility with what gcc did over the past 8 years rather than clang
compatibility.
Some sanitizers (e.g. asan, lsan, tsan) don't support traps,
-fsanitize-trap=address etc. will be rejected (if enabled at the end of
command line), -fno-sanitize-trap= can be specified even for them.
This is similar behavior to -fsanitize-recover=.
One complication is vptr sanitization, which can't easily trap,
as the whole slow path of the checking is inside of libubsan.
Previously, -fsanitize=vptr -fsanitize-undefined-trap-on-error
silently ignored vptr sanitization.
This patch similarly to what clang does will accept
-fsanitize-trap=all or -fsanitize-trap=undefined which enable
the vptr bit as trapping and again that causes silent disabling
of vptr sanitization, while -fsanitize-trap=vptr is rejected
(already during option processing).

So far quickly tested with make check-gcc check-g++ RUNTESTFLAGS=ubsan.exp,
ok for trunk if it passes full bootstrap/regtest?

2022-06-17  Jakub Jelinek  

gcc/
* common.opt (flag_sanitize_trap): New variable.
(fsanitize-trap=, fsanitize-trap): New options.
(fsanitize-undefined-trap-on-error): Change into deprecated alias
for -fsanitize-trap=all.
* opts.h (struct sanitizer_opts_s): Add can_trap member.
* opts.cc (finish_options): Complain about unsupported
-fsanitize-trap= options.
(sanitizer_opts): Add can_trap values to all entries.
(get_closest_sanitizer_option): Ignore -fsanitize-trap=
options which have can_trap false.
(parse_sanitizer_options): Add support for -fsanitize-trap=.
For -fsanitize-trap=all, enable
SANITIZE_UNDEFINED | SANITIZE_UNDEFINED_NONDEFAULT.  Disallow
-fsanitize-trap=vptr here.
(common_handle_option): Handle OPT_fsanitize_trap_ and
OPT_fsanitize_trap.
* sanopt.cc (maybe_optimize_ubsan_null_ifn): Check
flag_sanitize_trap & SANITIZE_{NULL,ALIGNMENT} instead of
flag_sanitize_undefined_trap_on_error.
* gcc.cc (sanitize_spec_function): Use
flag_sanitize & ~flag_sanitize_trap instead of flag_sanitize
and drop use of flag_sanitize_undefined_trap_on_error in
"undefined" handling.
* ubsan.cc (ubsan_instrument_unreachable): Use
flag_sanitize_trap & SANITIZE_??? instead of
flag_sanitize_undefined_trap_on_error.
(ubsan_expand_bounds_ifn, ubsan_expand_null_ifn,
ubsan_expand_objsize_ifn, ubsan_expand_ptr_ifn,
ubsan_build_overflow_builtin, instrument_bool_enum_load,
ubsan_instrument_float_cast, instrument_nonnull_arg,
instrument_nonnull_return, instrument_builtin): Likewise.
* doc/invoke.texi (-fsanitize-trap=, -fsanitize-trap): Document.
(-fsanitize-undefined-trap-on-error): Document as deprecated
alias of -fsanitize-trap.
gcc/c-family/
* c-ubsan.cc (ubsan_instrument_division, ubsan_instrument_shift):
Use flag_sanitize_trap & SANITIZE_??? instead of
flag_sanitize_undefined_trap_on_error.  If 2 sanitizers are involved
and flag_sanitize_trap differs for them, emit __builtin_trap only
for the comparison where trap is requested.
(ubsan_instrument_vla, ubsan_instrument_return): Use
lag_sanitize_trap & SANITIZE_??? instead of
flag_sanitize_undefined_trap_on_error.
gcc/cp/
* cp-ubsan.cc (cp_ubsan_instrument_vptr_p): Use
flag_sanitize_trap & SANITIZE_VPTR instead of
flag_sanitize_undefined_trap_on_error.
gcc/testsuite/
* c-c++-common/ubsan/nonnull-4.c: Use -fsanitize-trap=all
instead of -fsanitize-undefined-trap-on-error.
* c-c++-common/ubsan/div-by-zero-4.c: Use
-fsanitize-trap=signed-integer-overflow instead of
-fsanitize-undefined-trap-on-error.
* c-c++-common/ubsan/overflow-add-4.c: Use -fsanitize-trap=undefined
instead of -fsanitize-undefined-trap-on-error.
* c-c++-common/ubsan/pr56956.c: Likewise.
* c-c++-common/ubsan/pr68142.c: Likewise.
* c-c++-common/ubsan/pr80932.c: Use
-fno-sanitize-trap=all -fsanitize-trap=shift,undefined
instead of -fsanitize-undefined-trap-on-error.
* 

Re: [PATCH, rs6000] Use CC for BCD operations [PR100736]

[Segher Boessenkool]

Hi!

On Fri, Jun 17, 2022 at 04:19:37PM +0800, HAO CHEN GUI wrote:
> On 16/6/2022 下午 7:24, Segher Boessenkool wrote:
> > You shouldn't need anything like this, bcdinvalid will work just fine if
> > written as bcdadd_ov (with vector of 0 as the second op)?
> 
> The vector of 0 is not equal to BCD 0, I think. The BCD number contains
> preferred sign (PS) bit. So all zeros itself is an invalid encoding. We may
> use bcdsub_ov with duplicated op to implement bcdinvalid.

For the machine, you should use 0x0c or 0x0f, sure.  But in RTL we can
do whatever we want.

But bcdsub is easier indeed, and we don't need to construct a 0 first
then.


Segher

[Bug tree-optimization/106019] New: Surprising SLP failure on trivial code

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

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

Bug ID: 106019
   Summary: Surprising SLP failure on trivial code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

In the following code, 'f' is not SLP-vectorized, but 'g' is. From a brief look
at slp2 dump, looks like dependence analysis for p[i] vs. p[i+1] fails?

void f(double *p, long i)
{
p[i+0] += 1;
p[i+1] += 1;
}
void g(double *p, long i)
{
double *q = p + i;
q[0] += 1;
q[1] += 1;
}

Re: [RFC] analyzer: allocation size warning

[David Malcolm via Gcc]

On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote:
> Hi everyone,

Hi Tim.

Thanks for the patch.

Various comments inline below, throughout...

> 
> tracked in PR105900 [0], I'd like to add support for a new warning on
> dubious allocation sizes. The new checker emits a warning when the 
> allocation size is not a multiple of the type's size. With the checker,
> following mistakes are detected:
>   int *arr = malloc(3); // forgot to multiply by sizeof
>   arr[0] = ...;
>   arr[1] = ...;
> or
>   int *buf = malloc (n + sizeof(int)); // probably should be * instead 
> of +
> Because it is implemented inside the analyzer, it also emits warnings
> when the buffer is first of type void* and later on casted to something
> else. Though, this also inherits a limitation. The checker can not 
> distinguish 2 * sizeof(short) from sizeof(int) because sizeof is 
> resolved and constants are folded at the point when the analyzer runs. 
> As a mitigation, I plan to implement a check in the frontend that emits
> a warning if sizeof(lhs pointee type) is not part of the malloc 
> argument.
> 
> I'm looking for a first feedback on the phrasing of the diagnostics as 
> well on the preliminary patch [1].
> 
> On constant buffer sizes, the warnings looks like this:
> warning: Allocated buffer size is not a multiple of the pointee's size 
> [CWE-131] [-Wanalyzer-allocation-size]
>    22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } */
>   | ^
>   ‘test_2’: event 1
>     |
>     | 22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 }
> */
>     | | ^
>     | | |
>     | | (1) Casting a 14 byte buffer to ‘int *’ leaves 2 trailing 
> bytes; either the allocated size is bogus or the type on the left-hand 
> side is wrong
>     |

Something strange seems to have happened with the indentation in your
email; the code in the patch seems to me to be strangely indented, and
looking at the archive here:
  https://gcc.gnu.org/pipermail/gcc/2022-June/238907.html
I see the same thing, so I think it's a problem with what the mailing
list received, rather than just in my mail client.  Maybe something 

FWIW I normally use "git send-email" to send patches.

The underlinings in the above look strange; I see this in your email:

warning: Allocated buffer size is not a multiple of the pointee's size 
[CWE-131] [-Wanalyzer-allocation-size]
   22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } */
  | ^
  ‘test_2’: event 1
|
| 22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } 
*/
| | ^
| | |
| | (1) Casting a 14 byte buffer to ‘int *’ leaves 2 trailing 
bytes; either the allocated size is bogus or the type on the left-hand 
side is wrong
|

Should it have been (omitting the dg-line directives for clarity):

warning: Allocated buffer size is not a multiple of the pointee's size  
[CWE-131] [-Wanalyzer-allocation-size]
   22 | int *ptr = malloc (10 + sizeof(int));
  |^
  ‘test_2’: event 1
|
| 22 | int *ptr = malloc (10 + sizeof(int));
||^
|||
||(1) Casting a 14 byte buffer to ‘int *’ leaves 2 trailing 
bytes; either the allocated size is bogus or the type on the left-hand side is 
wrong
|

?

It looks like something somewhere has collapsed repeated whitespace in
the message down to single spaces, which has broken the ASCII art in
your examples, and the indentation in your code.


It would probably be helpful for the message to tell the user what
sizeof(*ptr) is,  sizeof(int) in this case (much more helpful when it's
a struct)

Maybe something alike:

note: a buffer of 14 bytes is allocated...
note: ...but sizeof (int) is 4 bytes...
note: ...leaving 2 trailing bytes for an array of 3 'int's (which would
occupy 12 bytes)

or somesuch???

I'm brainstorming here, my ideas above aren't necessarily good. 
Sometimes it's good to chop up messages like this, to minimize
combinatorial explosion for all the different cases.



On symbolic buffer sizes:
warning: Allocated buffer size is not a multiple of the pointee's size 
[CWE-131] [-Wanalyzer-allocation-size]
   33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3 } */
  | ^~~~
  ‘test_3’: event 1
    |
    | 33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3 } 
*/
    | | ^~~~
    | | |
    | | (1) Allocation is incompatible with ‘int *’; either the 
allocated size is bogus or the type on the left-hand side is wrong
    |


Is there location information for both the malloc and for the
assignment, here?

If so, then maybe two events:

warning: Allocated buffer size is not a multiple of the pointee's size 
[CWE-131] [-Wanalyzer-allocation-size]
   33 | int *ptr = malloc (n + sizeof(int));
  |

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #3 from Segher Boessenkool  ---
Yeah.  It should just return 1 like the other scalar types?

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

--- Comment #3 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #2)
> We do not want or allow automatic conversions between the opaque
> __vector_pair and __vector_quad types and other types and those are
> correctly disallowed there.

Of course, but that is not what this is about...

> As for the pointer conversions tested there, I guess they came along for the
> ride?  Nemanja, do you remember the history there?  Or does LLVM allow the
> pointer conversions and it's just GCC that complains?

... this is.

Possibly the restriction prevents some ICEs elsewhere, but those just need to
be solved then, not hidden.

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #2 from Peter Bergner  ---
Given where this is ICEing, I'm guessing this is non-target specific issue in
handling opaque types.

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

--- Comment #2 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #1)
> So the restriction in rs6000_invalid_conversion errors for valid C programs.
> What was it intended to accomplish?

We do not want or allow automatic conversions between the opaque __vector_pair
and __vector_quad types and other types and those are correctly disallowed
there.  Conversions between those types needs to go through the builtins
defined for that.

As for the pointer conversions tested there, I guess they came along for the
ride?  Nemanja, do you remember the history there?  Or does LLVM allow the
pointer conversions and it's just GCC that complains?

[Bug target/106015] [PowerPC] pointer to MMA accumulator not convertible to char pointer

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

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

--- Comment #2 from Segher Boessenkool  ---
Confirmed.  Likely the same cause as PR106017.

[Bug target/106015] [PowerPC] pointer to MMA accumulator not convertible to char pointer

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

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

Peter Bergner  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-17

--- Comment #1 from Peter Bergner  ---
Confirmed.

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-17

--- Comment #1 from Segher Boessenkool  ---
Confirmed.  Thanks for reporting these bugs!

kernel sparse annotations vs. compiler attributes and debug_annotate_{type,decl} WAS: Re: [PATCH 0/9] Add debug_annotate attributes

[Jose E. Marchesi via Gcc-patches]

Hi Yonghong.

> On 6/15/22 1:57 PM, David Faust wrote:
>> 
>> On 6/14/22 22:53, Yonghong Song wrote:
>>>
>>>
>>> On 6/7/22 2:43 PM, David Faust wrote:
 Hello,

 This patch series adds support for:

 - Two new C-language-level attributes that allow to associate (to 
 "annotate" or
 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.

 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 parameters 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/


 Implementation Overview
 ===

 To enable these annotations, two new C language attributes are added:
 __attribute__((debug_annotate_decl("foo"))) and
 __attribute__((debug_annotate_type("bar"))). Both attributes accept a 
 single
 arbitrary string constant argument, which will be recorded in the generated
 DWARF and/or BTF debug 

Re: [RFC] analyzer: allocation size warning

[Prathamesh Kulkarni via Gcc]

On Fri, 17 Jun 2022 at 21:25, Tim Lange  wrote:
>
> Hi everyone,
Hi Tim,
Thanks for posting the POC patch!
Just a couple of comments (inline)
>
> tracked in PR105900 [0], I'd like to add support for a new warning on
> dubious allocation sizes. The new checker emits a warning when the
> allocation size is not a multiple of the type's size. With the checker,
> following mistakes are detected:
>   int *arr = malloc(3); // forgot to multiply by sizeof
>   arr[0] = ...;
>   arr[1] = ...;
> or
>   int *buf = malloc (n + sizeof(int)); // probably should be * instead
> of +
> Because it is implemented inside the analyzer, it also emits warnings
> when the buffer is first of type void* and later on casted to something
> else. Though, this also inherits a limitation. The checker can not
> distinguish 2 * sizeof(short) from sizeof(int) because sizeof is
> resolved and constants are folded at the point when the analyzer runs.
> As a mitigation, I plan to implement a check in the frontend that emits
> a warning if sizeof(lhs pointee type) is not part of the malloc
> argument.
IMHO, warning if sizeof(lhs pointee_type) is not present inside
malloc, might not be a good idea because it
would reject valid calls to malloc.
For eg:
(1)
size_t size = sizeof(int);
int *p = malloc (size);

(2)
void *p = malloc (sizeof(int));
int *q = p;
>
> I'm looking for a first feedback on the phrasing of the diagnostics as
> well on the preliminary patch [1].
>
> On constant buffer sizes, the warnings looks like this:
> warning: Allocated buffer size is not a multiple of the pointee's size
> [CWE-131] [-Wanalyzer-allocation-size]
>22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } */
>   | ^
>   ‘test_2’: event 1
> |
> | 22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 }
> */
> | | ^
> | | |
> | | (1) Casting a 14 byte buffer to ‘int *’ leaves 2 trailing
> bytes; either the allocated size is bogus or the type on the left-hand
> side is wrong
> |
>
> On symbolic buffer sizes:
> warning: Allocated buffer size is not a multiple of the pointee's size
> [CWE-131] [-Wanalyzer-allocation-size]
>33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3 } */
>   | ^~~~
>   ‘test_3’: event 1
> |
> | 33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3 }
> */
> | | ^~~~
> | | |
> | | (1) Allocation is incompatible with ‘int *’; either the
> allocated size is bogus or the type on the left-hand side is wrong
> |
Won't the warning be incorrect if 'n' is a multiple of sizeof(int) ?
I assume by symbolic buffer size, 'n' is not known at compile time.

Thanks,
Prathamesh
>
> And this is how a simple flow looks like:
> warning: Allocated buffer size is not a multiple of the pointee's size
> [CWE-131] [-Wanalyzer-allocation-size]
>39 | int *iptr = (int *)ptr; /* { dg-line assign } */
>   | ^~~~
>   ‘test_4’: events 1-2
> |
> | 38 | void *ptr = malloc (n * sizeof (short)); /* { dg-message } */
> | | ^~~
> | | |
> | | (1) allocated here
> | 39 | int *iptr = (int *)ptr; /* { dg-line assign } */
> | | 
> | | |
> | | (2) ‘ptr’ is incompatible with ‘int *’; either the
> allocated size at (1) is bogus or the type on the left-hand side is
> wrong
> |
>
> There are some things to discuss from my side:
> * The tests with the "toy re-implementation of CPython's object
> model"[2] fail due to a extra warning emitted. Because the analyzer
> can't know the calculation actually results in a correct buffer size
> when viewed as a string_obj later on, it emits a warning, e.g. at line
> 61 in data-model-5.c. The only mitigation would be to disable the
> warning for structs entirely. Now, the question is to rather have noise
> on these cases or disable the warning for structs entirely?
> * I'm unable to emit a warning whenever the cast happens at an
> assignment with a call as the rhs, e.g. test_1 in allocation-size-4.c.
> This is because I'm unable to access a region_svalue for the returned
> value. Even in the new_program_state, the svalue of the lhs is still a
> conjured_svalue. Maybe David can lead me to a place where I can access
> the return value's region_svalue or do I have to adapt the engine?
> * attr-malloc-6.c and pr96639.c did both contain structs without an
> implementation. Something in the analyzer must have triggered another
> warning about the usage of those without them having an implementation.
> I changed those structs to have an empty implementation, such that the
> additional warning are gone. I think this shouldn't change the test
> case, so is this change okay?
>
> - Tim
>
> [0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900
> [1] While all tests except the cpython ones work, I have yet to test it
> on large C projects
> [2] FAIL: gcc.dg/analyzer/data-model-5.c (test for excess 

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-17

--- Comment #1 from Segher Boessenkool  ---
Confirmed.

C allows to convert a pointer to data to any other pointer to data (possibly
modulo alignment restrictions).  What is *not* valid is accessing anything via
a type not compatible with its effective type (or via a character type).

So the restriction in rs6000_invalid_conversion errors for valid C programs.
What was it intended to accomplish?

Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to set the lowpart.

[Richard Sandiford via Gcc-patches]

Tamar Christina  writes:
>> -Original Message-
>> From: Richard Sandiford 
>> Sent: Monday, June 13, 2022 9:41 AM
>> To: Tamar Christina 
>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de
>> Subject: Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to
>> set the lowpart.
>> 
>> Tamar Christina  writes:
>> > Hi All,
>> >
>> > When lowering COMPLEX_EXPR we currently emit two VEC_EXTRACTs.
>> One
>> > for the lowpart and one for the highpart.
>> >
>> > The problem with this is that in RTL the lvalue of the RTX is the only
>> > thing tying the two instructions together.
>> >
>> > This means that e.g. combine is unable to try to combine the two
>> > instructions for setting the lowpart and highpart.
>> >
>> > For ISAs that have bit extract instructions we can eliminate one of
>> > the extracts if, and only if we're setting the entire complex number.
>> >
>> > This change changes the expand code when we're setting the entire
>> > complex number to generate a subreg for the lowpart instead of a
>> vec_extract.
>> >
>> > This allows us to optimize sequences such as:
>> >
>> > _Complex int f(int a, int b) {
>> > _Complex int t = a + b * 1i;
>> > return t;
>> > }
>> >
>> > from:
>> >
>> > f:
>> >bfi x2, x0, 0, 32
>> >bfi x2, x1, 32, 32
>> >mov x0, x2
>> >ret
>> >
>> > into:
>> >
>> > f:
>> >bfi x0, x1, 32, 32
>> >ret
>> >
>> > I have also confirmed the codegen for x86_64 did not change.
>> >
>> > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
>> > and no issues.
>> >
>> > Ok for master?
>> 
>> I'm not sure this is endian-safe.  For big-endian it's the imaginary part 
>> that can
>> be written as a subreg.  The real part might be the high part of a register.
>> 
>> Maybe a more general way to handle this would be to add (yet another)
>> parameter to store_bit_field that indicates that the current value of the
>> structure is undefined.  That would also be useful in at least one other 
>> caller
>> (from calls.cc).  write_complex_part could then have a similar parameter,
>> true for the first write and false for the second.
>
> Ohayou-gozaimasu!
>
> I've rewritten it using the approach you requested. I attempted to set the 
> flag
> In the correct places as well.

Thanks, looks good.  But rather than treat this as a new case, I think
we can instead generalise this store_bit_field_1 code:

  else if (constant_multiple_p (bitnum, regsize * BITS_PER_UNIT, )
   && multiple_p (bitsize, regsize * BITS_PER_UNIT)
   && known_ge (GET_MODE_BITSIZE (GET_MODE (op0)), bitsize))
{
  sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0),
 regnum * regsize);
  if (sub)
{
  if (reverse)
value = flip_storage_order (fieldmode, value);
  emit_move_insn (sub, value);
  return true;
}
}

so that the multiple_p test is skipped if the structure is undefined.

Richard

> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
>   * expmed.cc (store_bit_field): Add parameter that indicates if value is
>   still undefined and if so emit a subreg move instead.
>   * expr.h (write_complex_part): Likewise.
>   * expmed.h (store_bit_field): Add new parameter.
>   * builtins.cc (expand_ifn_atomic_compare_exchange_into_call): Use new
>   parameter.
>   (expand_ifn_atomic_compare_exchange): Likewise.
>   * calls.cc (store_unaligned_arguments_into_pseudos): Likewise.
>   * emit-rtl.cc (validate_subreg): Likewise.
>   * expr.cc (emit_group_store): Likewise.
>   (copy_blkmode_from_reg): Likewise.
>   (copy_blkmode_to_reg): Likewise.
>   (clear_storage_hints): Likewise.
>   (write_complex_part):  Likewise.
>   (emit_move_complex_parts): Likewise.
>   (expand_assignment): Likewise.
>   (store_expr): Likewise.
>   (store_field): Likewise.
>   (expand_expr_real_2): Likewise.
>   * ifcvt.cc (noce_emit_move_insn): Likewise.
>   * internal-fn.cc (expand_arith_set_overflow): Likewise.
>   (expand_arith_overflow_result_store): Likewise.
>   (expand_addsub_overflow): Likewise.
>   (expand_neg_overflow): Likewise.
>   (expand_mul_overflow): Likewise.
>   (expand_arith_overflow): Likewise.
>
> gcc/testsuite/ChangeLog:
>
>   * g++.target/aarch64/complex-init.C: New test.
>
> --- inline copy of patch ---
>
> diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> index 
> 4c6c29390531d8ae9765add598621727213b23ec..8c80e46d9c9c9c2a7e1ce0f8add86729fd542b16
>  100644
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -6014,8 +6014,8 @@ expand_ifn_atomic_compare_exchange_into_call (gcall 
> *call, machine_mode mode)
>if (GET_MODE (boolret) != mode)
>   boolret = convert_modes (mode, GET_MODE (boolret), 

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

New linking implementation is complete, gcc bootstraps and hello
world links.  I'll git push the changes, then test/debug/polish and
produce new patch sets

regards,
Gaius

[PATCH] c++, v2: Add support for __real__/__imag__ modifications in constant expressions [PR88174]

[Jakub Jelinek via Gcc-patches]

On Fri, Jun 10, 2022 at 09:57:06PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Jun 10, 2022 at 01:27:28PM -0400, Jason Merrill wrote:
> > Doesn't this assert mean that complex_expr will always be == valp?
> 
> No, even when handling the pushed *PART_EXPR, it will set
> valp = _OPERAND (*valp, index != integer_zero_node);
> So, valp will be either _OPERAND (*complex_expr, 0)
> or _OPERAND (*complex_expr, 1).
> As *valp = init; is what is usually then stored and we want to store there
> the scalar.
> 
> > I don't understand this block; shouldn't valp point to the real or imag part
> > of the complex number at this point?  How could complex_part be set without
> > us handling the complex case in the loop already?
> 
> Because for most references, the code will do:
>   vec_safe_push (ctors, *valp);
>   vec_safe_push (indexes, index);
> I chose not to do this for *PART_EXPR, because the COMPLEX_EXPR isn't a
> CONSTRUCTOR and code later on e.g. walks all the ctors and accesses
> CONSTRUCTOR_NO_CLEARING on them etc.  As the *PART_EXPR is asserted to
> be outermost only, complex_expr is a variant of that ctors push and
> complex_part of the indexes.
> The reason for the above if is just in case the evaluation of the rhs
> of the store would store to the complex and could e.g. make it a COMPLEX_CST
> again.
> 
> > I might have added the COMPLEX_EXPR to ctors instead of a separate variable,
> > but this is fine too.
> 
> See above.
> The COMPLEX_EXPR needs special handling (conversion into COMPLEX_CST if it
> is constant) anyway.

Here is a variant patch which pushes even the *PART_EXPR related entries
into ctors and indexes vectors, so it doesn't need to use extra variables
for the complex stuff.

2022-06-17  Jakub Jelinek  

PR c++/88174
* constexpr.cc (cxx_eval_store_expression): Handle REALPART_EXPR
and IMAGPART_EXPR.  Change ctors from releasing_vec to
auto_vec, adjust all uses.

* g++.dg/cpp1y/constexpr-complex1.C: New test.

--- gcc/cp/constexpr.cc.jj  2022-06-09 17:42:23.606243920 +0200
+++ gcc/cp/constexpr.cc 2022-06-17 18:59:54.809208997 +0200
@@ -5714,6 +5714,20 @@ cxx_eval_store_expression (const constex
  }
  break;
 
+   case REALPART_EXPR:
+ gcc_assert (probe == target);
+ vec_safe_push (refs, probe);
+ vec_safe_push (refs, TREE_TYPE (probe));
+ probe = TREE_OPERAND (probe, 0);
+ break;
+
+   case IMAGPART_EXPR:
+ gcc_assert (probe == target);
+ vec_safe_push (refs, probe);
+ vec_safe_push (refs, TREE_TYPE (probe));
+ probe = TREE_OPERAND (probe, 0);
+ break;
+
default:
  if (evaluated)
object = probe;
@@ -5752,7 +5766,8 @@ cxx_eval_store_expression (const constex
   type = TREE_TYPE (object);
   bool no_zero_init = true;
 
-  releasing_vec ctors, indexes;
+  auto_vec ctors;
+  releasing_vec indexes;
   auto_vec index_pos_hints;
   bool activated_union_member_p = false;
   bool empty_base = false;
@@ -5792,14 +5807,36 @@ cxx_eval_store_expression (const constex
  *valp = ary_ctor;
}
 
-  /* If the value of object is already zero-initialized, any new ctors for
-subobjects will also be zero-initialized.  */
-  no_zero_init = CONSTRUCTOR_NO_CLEARING (*valp);
-
   enum tree_code code = TREE_CODE (type);
   tree reftype = refs->pop();
   tree index = refs->pop();
 
+  if (code == COMPLEX_TYPE)
+   {
+ if (TREE_CODE (*valp) == COMPLEX_CST)
+   *valp = build2 (COMPLEX_EXPR, type, TREE_REALPART (*valp),
+   TREE_IMAGPART (*valp));
+ else if (TREE_CODE (*valp) == CONSTRUCTOR
+  && CONSTRUCTOR_NELTS (*valp) == 0
+  && CONSTRUCTOR_NO_CLEARING (*valp))
+   {
+ tree r = build_constructor (reftype, NULL);
+ CONSTRUCTOR_NO_CLEARING (r) = 1;
+ *valp = build2 (COMPLEX_EXPR, type, r, r);
+   }
+ gcc_assert (TREE_CODE (*valp) == COMPLEX_EXPR);
+ ctors.safe_push (valp);
+ vec_safe_push (indexes, index);
+ valp = _OPERAND (*valp, TREE_CODE (index) == IMAGPART_EXPR);
+ gcc_checking_assert (refs->is_empty ());
+ type = reftype;
+ break;
+   }
+
+  /* If the value of object is already zero-initialized, any new ctors for
+subobjects will also be zero-initialized.  */
+  no_zero_init = CONSTRUCTOR_NO_CLEARING (*valp);
+
   if (code == RECORD_TYPE && is_empty_field (index))
/* Don't build a sub-CONSTRUCTOR for an empty base or field, as they
   have no data and might have an offset lower than previously declared
@@ -5842,7 +5879,7 @@ cxx_eval_store_expression (const constex
  no_zero_init = true;
}
 
-  vec_safe_push (ctors, *valp);
+  ctors.safe_push (valp);
   vec_safe_push (indexes, index);
 
   constructor_elt *cep
@@ -5904,11 

[Bug c/106018] New: Feature Request: Add function attribute fn_enter, and fn_exit

[alan.rosenthal at gmail dot com via Gcc-bugs]

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

Bug ID: 106018
   Summary: Feature Request: Add function attribute fn_enter, and
fn_exit
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alan.rosenthal at gmail dot com
  Target Milestone: ---

Add a function attributes: fn_enter and fn_exit to auto generate functions that
are called before a function starts and after a function ends.

This function:
char myfn(int param1, bool pararm2, void* param3) __attribute__ ((fn_enter,
fn_exit)) {
  if (param1) {
return '0';
  }
  if (param2) {
return '1';
  }
  char ret = (char) param3;
  return ret;
}

Would generated these two functions:

void __enter_myfn(int param1, bool pararm2, void* param3);
void __exit_myfn(char ret);

These functions would be called during normal enter/exit conditions, i.e.:
char myfn(int param1, bool pararm2, void* param3) __attribute__ ((fn_enter,
fn_exit)) {
  __enter_myfn(param1, param2, param3);
  if (param1) {
__exit_fn('0');
return '0';
  }
  if (param2) {
__exit_fn('1');
return '1';
  }
  char ret = (char) param3;
  __exit_fn(ret);
  return ret;
}


This would allow a developer to easily add diagnostics to a specific function
to get a better sense of how often it was called, with what arguments, and what
the return value were. 

Similarly functionality exists in -finstrument-functions, but it doesn't
provide a way to capture function parameters or return values.

Re: Signed vs. unsigned compares

[Paul Koning via Gcc]

> On Jun 17, 2022, at 11:51 AM, Andreas Schwab  wrote:
> 
> On Jun 17 2022, Paul Koning via Gcc wrote:
> 
>> In expanding a longer-than-word compare, I need to do things differently 
>> depending on whether a signed vs. unsigned compare is needed.  But it seems 
>> the compare operation applies to either.  How can I do this in the target 
>> code?
> 
> There are both signed and unsigned comparison operations, eg. GE
> vs. GEU.
> 
> -- 
> Andreas Schwab, sch...@linux-m68k.org

It looks like what I need is to define additional CCmodes, to describe "cc mode 
valid for unsigned comparison" vs. "cc mode valid for signed comparison".  
Right now I don't make that distinction and that reportedly can produce bad 
code errors.

paul

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #6 from Steve Kargl  ---
On Fri, Jun 17, 2022 at 02:56:50PM +, wileamyp at outlook dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005
> 
> --- Comment #5 from Wileam Yonatan Phan  ---
> Hi Steve,
> 
> I think I recognize you from the Fortran-lang Discourse forum!
> 

Yep.

> > The committee is ready to vote, but it is still a non-existent standard.
> 
> That's technically true, since the votes haven't been cast, yet.
> 
> > The first thing required for gfortran to support any F2023 feature would be 
> > the addition of a -std=f2023.  This has not been implemented, yet.
> 
> That is correct, and I guess work on implementing the `-std=f2023` flag will
> start as soon as the standard is agreed upon and published. Do you know when
> the committee will meet to vote?

I've seem some voting in the J3 mailing list, bu that may have
been for interpretation requests against the current standard.
J3 is scheduled to meet in July.  If J3 hasn't passed F2023 to
ISO yet, then it likely will be finalized at this meeting.


> > I'll also note that things don't magically appear in gfortran. Someone has 
> > to implement it.
> 
> Hopefully I will be able to implement this particular part (REDUCE) as part of
> my GSoC '22 project
> . The
> second phase of the project specifically addresses support in the parser, and
> the third phase implements the actual parallelization.
> 
> So, my intention on filing this bug is to have a public record for tracking my
> project's progress. I'll also periodically blog about it at
>  and
> 
> 

I haven't used DO CURRENT in my own codes so only have a small
amount of exposure to what gfortran does.  I suspect it is 
missing some, if not most, of the locality stuff from F2018.
If you have general questions about gfortran internals, feel
free to ping me.

[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer

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

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

--- Comment #3 from Tim Lange  ---
See also this mailing list thread:
https://gcc.gnu.org/pipermail/gcc/2022-June/238907.html

[RFC] analyzer: allocation size warning

[Tim Lange]

Hi everyone,

tracked in PR105900 [0], I'd like to add support for a new warning on 
dubious allocation sizes. The new checker emits a warning when the 
allocation size is not a multiple of the type's size. With the checker, 
following mistakes are detected:

 int *arr = malloc(3); // forgot to multiply by sizeof
 arr[0] = ...;
 arr[1] = ...;
or
 int *buf = malloc (n + sizeof(int)); // probably should be * instead 
of +
Because it is implemented inside the analyzer, it also emits warnings 
when the buffer is first of type void* and later on casted to something 
else. Though, this also inherits a limitation. The checker can not 
distinguish 2 * sizeof(short) from sizeof(int) because sizeof is 
resolved and constants are folded at the point when the analyzer runs. 
As a mitigation, I plan to implement a check in the frontend that emits 
a warning if sizeof(lhs pointee type) is not part of the malloc 
argument.


I'm looking for a first feedback on the phrasing of the diagnostics as 
well on the preliminary patch [1].


On constant buffer sizes, the warnings looks like this:
warning: Allocated buffer size is not a multiple of the pointee's size 
[CWE-131] [-Wanalyzer-allocation-size]

  22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } */
 | ^
 ‘test_2’: event 1
   |
   | 22 | int *ptr = malloc (10 + sizeof(int)); /* { dg-line malloc2 } 
*/

   | | ^
   | | |
   | | (1) Casting a 14 byte buffer to ‘int *’ leaves 2 trailing 
bytes; either the allocated size is bogus or the type on the left-hand 
side is wrong

   |

On symbolic buffer sizes:
warning: Allocated buffer size is not a multiple of the pointee's size 
[CWE-131] [-Wanalyzer-allocation-size]

  33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3 } */
 | ^~~~
 ‘test_3’: event 1
   |
   | 33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3 } 
*/

   | | ^~~~
   | | |
   | | (1) Allocation is incompatible with ‘int *’; either the 
allocated size is bogus or the type on the left-hand side is wrong

   |

And this is how a simple flow looks like:
warning: Allocated buffer size is not a multiple of the pointee's size 
[CWE-131] [-Wanalyzer-allocation-size]

  39 | int *iptr = (int *)ptr; /* { dg-line assign } */
 | ^~~~
 ‘test_4’: events 1-2
   |
   | 38 | void *ptr = malloc (n * sizeof (short)); /* { dg-message } */
   | | ^~~
   | | |
   | | (1) allocated here
   | 39 | int *iptr = (int *)ptr; /* { dg-line assign } */
   | | 
   | | |
   | | (2) ‘ptr’ is incompatible with ‘int *’; either the 
allocated size at (1) is bogus or the type on the left-hand side is 
wrong

   |

There are some things to discuss from my side:
* The tests with the "toy re-implementation of CPython's object 
model"[2] fail due to a extra warning emitted. Because the analyzer 
can't know the calculation actually results in a correct buffer size 
when viewed as a string_obj later on, it emits a warning, e.g. at line 
61 in data-model-5.c. The only mitigation would be to disable the 
warning for structs entirely. Now, the question is to rather have noise 
on these cases or disable the warning for structs entirely?
* I'm unable to emit a warning whenever the cast happens at an 
assignment with a call as the rhs, e.g. test_1 in allocation-size-4.c. 
This is because I'm unable to access a region_svalue for the returned 
value. Even in the new_program_state, the svalue of the lhs is still a 
conjured_svalue. Maybe David can lead me to a place where I can access 
the return value's region_svalue or do I have to adapt the engine?
* attr-malloc-6.c and pr96639.c did both contain structs without an 
implementation. Something in the analyzer must have triggered another 
warning about the usage of those without them having an implementation. 
I changed those structs to have an empty implementation, such that the 
additional warning are gone. I think this shouldn't change the test 
case, so is this change okay?


- Tim

[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900
[1] While all tests except the cpython ones work, I have yet to test it 
on large C projects

[2] FAIL: gcc.dg/analyzer/data-model-5.c (test for excess errors)
   FAIL: gcc.dg/analyzer/data-model-5b.c (test for excess errors)
   FAIL: gcc.dg/analyzer/data-model-5c.c (test for excess errors)
   FAIL: gcc.dg/analyzer/data-model-5d.c (test for excess errors)
   FAIL: gcc.dg/analyzer/first-field-2.c (test for excess errors)

---

Subject: [PATCH] analyzer: add allocation size warning

This patch adds an allocation size checker to the analyzer.
The checker warns when the tracked buffer size is not a multiple of the 
left-hand side pointee's type. This resolves PR analyzer/105900.


The patch is not yet fully tested.

gcc/analyzer/ChangeLog:

   * analyzer.opt: Add Wanalyzer-allocation-size.
   * sm-malloc.cc (class dubious_allocation_size): New 

Re: Signed vs. unsigned compares

[Andreas Schwab]

On Jun 17 2022, Paul Koning via Gcc wrote:

> In expanding a longer-than-word compare, I need to do things differently 
> depending on whether a signed vs. unsigned compare is needed.  But it seems 
> the compare operation applies to either.  How can I do this in the target 
> code?

There are both signed and unsigned comparison operations, eg. GE
vs. GEU.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

[Bug c++/106001] [12/13 Regression] ICE: expected expression 'static_cast(1)' of kind static_cast_expr since r12-1128-gef8176e0fac935

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-1158-ga284fadcce8ef443cc3cc047a8017745efb51758
Author: Jakub Jelinek 
Date:   Fri Jun 17 17:40:49 2022 +0200

c++: Use fold_non_dependent_expr rather than maybe_constant_value in
__builtin_shufflevector handling [PR106001]

In this case the STATIC_CAST_EXPR expressions in the call aren't
type nor value dependent, but maybe_constant_value still ICEs on those
when processing_template_decl.  Calling fold_non_dependent_expr on it
instead fixes the ICE and folds them to INTEGER_CSTs.

2022-06-17  Jakub Jelinek  

PR c++/106001
* typeck.cc (build_x_shufflevector): Use fold_non_dependent_expr
instead of maybe_constant_value.

* g++.dg/ext/builtin-shufflevector-4.C: New test.

[PATCH] ubsan: Add -fsanitize-trap= support

[Jakub Jelinek via Gcc-patches]

On Thu, Jun 16, 2022 at 09:32:02PM +0100, Jonathan Wakely wrote:
> It looks like clang has addressed this deficiency now:
> 
> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#usage

Thanks, that is roughly what I'd implement anyway and apparently they have
it already since 2015, we've added the -fsanitize-undefined-trap-on-error
support back in 2014 and didn't change it since then.

As a small divergence from clang, I chose -fsanitize-undefined-trap-on-error
to be a (deprecated) alias for -fsanitize-trap aka -fsanitize-trap=all
rather thn -fsanitize-trap=undefined which seems to be what clang does,
because for a deprecated option it is IMHO more important backwards
compatibility with what gcc did over the past 8 years rather than clang
compatibility.
Some sanitizers (e.g. asan, lsan, tsan) don't support traps,
-fsanitize-trap=address etc. will be rejected (if enabled at the end of
command line), -fno-sanitize-trap= can be specified even for them.
This is similar behavior to -fsanitize-recover=.
One complication is vptr sanitization, which can't easily trap,
as the whole slow path of the checking is inside of libubsan.
Previously, -fsanitize=vptr -fsanitize-undefined-trap-on-error
silently ignored vptr sanitization.
This patch similarly to what clang does will accept
-fsanitize-trap=all or -fsanitize-trap=undefined which enable
the vptr bit as trapping and again that causes silent disabling
of vptr sanitization, while -fsanitize-trap=vptr is rejected
(already during option processing).

So far quickly tested with make check-gcc check-g++ RUNTESTFLAGS=ubsan.exp,
ok for trunk if it passes full bootstrap/regtest?

2022-06-17  Jakub Jelinek  

gcc/
* common.opt (flag_sanitize_trap): New variable.
(fsanitize-trap=, fsanitize-trap): New options.
(fsanitize-undefined-trap-on-error): Change into deprecated alias
for -fsanitize-trap=all.
* opts.h (struct sanitizer_opts_s): Add can_trap member.
* opts.cc (finish_options): Complain about unsupported
-fsanitize-trap= options.
(sanitizer_opts): Add can_trap values to all entries.
(get_closest_sanitizer_option): Ignore -fsanitize-trap=
options which have can_trap false.
(parse_sanitizer_options): Add support for -fsanitize-trap=.
For -fsanitize-trap=all, enable
SANITIZE_UNDEFINED | SANITIZE_UNDEFINED_NONDEFAULT.  Disallow
-fsanitize-trap=vptr here.
(common_handle_option): Handle OPT_fsanitize_trap_ and
OPT_fsanitize_trap.
* sanopt.cc (maybe_optimize_ubsan_null_ifn): Check
flag_sanitize_trap & SANITIZE_{NULL,ALIGNMENT} instead of
flag_sanitize_undefined_trap_on_error.
* gcc.cc (sanitize_spec_function): Use
flag_sanitize & ~flag_sanitize_trap instead of flag_sanitize
and drop use of flag_sanitize_undefined_trap_on_error in
"undefined" handling.
* ubsan.cc (ubsan_instrument_unreachable): Use
flag_sanitize_trap & SANITIZE_??? instead of
flag_sanitize_undefined_trap_on_error.
(ubsan_expand_bounds_ifn, ubsan_expand_null_ifn,
ubsan_expand_objsize_ifn, ubsan_expand_ptr_ifn,
ubsan_build_overflow_builtin, instrument_bool_enum_load,
ubsan_instrument_float_cast, instrument_nonnull_arg,
instrument_nonnull_return, instrument_builtin): Likewise.
* doc/invoke.texi (-fsanitize-trap=, -fsanitize-trap): Document.
(-fsanitize-undefined-trap-on-error): Document as deprecated
alias of -fsanitize-trap.
gcc/c-family/
* c-ubsan.cc (ubsan_instrument_division, ubsan_instrument_shift):
Use flag_sanitize_trap & SANITIZE_??? instead of
flag_sanitize_undefined_trap_on_error.  If 2 sanitizers are involved
and flag_sanitize_trap differs for them, emit __builtin_trap only
for the comparison where trap is requested.
(ubsan_instrument_vla, ubsan_instrument_return): Use
lag_sanitize_trap & SANITIZE_??? instead of
flag_sanitize_undefined_trap_on_error.
gcc/cp/
* cp-ubsan.cc (cp_ubsan_instrument_vptr_p): Use
flag_sanitize_trap & SANITIZE_VPTR instead of
flag_sanitize_undefined_trap_on_error.
gcc/testsuite/
* c-c++-common/ubsan/nonnull-4.c: Use -fsanitize-trap=all
instead of -fsanitize-undefined-trap-on-error.
* c-c++-common/ubsan/div-by-zero-4.c: Use
-fsanitize-trap=signed-integer-overflow instead of
-fsanitize-undefined-trap-on-error.
* c-c++-common/ubsan/overflow-add-4.c: Use -fsanitize-trap=undefined
instead of -fsanitize-undefined-trap-on-error.
* c-c++-common/ubsan/pr56956.c: Likewise.
* c-c++-common/ubsan/pr68142.c: Likewise.
* c-c++-common/ubsan/pr80932.c: Use
-fno-sanitize-trap=all -fsanitize-trap=shift,undefined
instead of -fsanitize-undefined-trap-on-error.
* c-c++-common/ubsan/align-8.c: Use -fsanitize-trap=alignment

Signed vs. unsigned compares

[Paul Koning via Gcc]

Question for target code:

In expanding a longer-than-word compare, I need to do things differently 
depending on whether a signed vs. unsigned compare is needed.  But it seems the 
compare operation applies to either.  How can I do this in the target code?

paul

Re: [PATCH] varasm: Fix up ICE in narrowing_initializer_constant_valid_p [PR105998]

[Richard Biener via Gcc-patches]

> Am 17.06.2022 um 11:20 schrieb Jakub Jelinek via Gcc-patches 
> :
> 
> On Fri, Jun 17, 2022 at 10:37:45AM +0200, Richard Biener wrote:
>>> --- gcc/varasm.cc.jj2022-06-06 12:18:12.792812888 +0200
>>> +++ gcc/varasm.cc2022-06-17 09:49:21.918029072 +0200
>>> @@ -4716,7 +4716,8 @@ narrowing_initializer_constant_valid_p (
>>>{
>>>  tree inner = TREE_OPERAND (op0, 0);
>>>  if (inner == error_mark_node
>>> -  || ! INTEGRAL_MODE_P (TYPE_MODE (TREE_TYPE (inner)))
>>> +  || VECTOR_TYPE_P (TREE_TYPE (inner))
>> 
>> Do we really want to allow all integer modes here regardless of a
>> composite type (record type for example)?  I’d say !INTEGRAL_TYPE_P would
>> match the rest better.  OTOH if we want to allow integer modes I fail to
>> see why to exclude vector types (but not complex, etc)
> 
> I've excluded VECTOR_TYPE_P because those are the only types for which
> TYPE_MODE can be different from the raw type mode (so, SCALAR_INT_MODE_P
> was true but SCALAR_INT_TYPE_MODE still ICEd).
> 
> Checking for INTEGRAL_TYPE_P seems reasonable to me though,
> and I'd say we also want to check the outer type too because nothing
> really checks it (at least for the first iteration, 2nd and further
> get it from checking of inner in the previous iteration).
> 
> So like this if it passes bootstrap/regtest?

Ok.

Richard 
> 2022-06-17  Jakub Jelinek  
> 
>PR middle-end/105998
>* varasm.cc (narrowing_initializer_constant_valid_p): Check
>SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P, also break on
>! INTEGRAL_TYPE_P and do the same check also on op{0,1}'s type.
> 
>* c-c++-common/pr105998.c: New test.
> 
> --- gcc/varasm.cc.jj2022-06-17 11:07:57.883679019 +0200
> +++ gcc/varasm.cc2022-06-17 11:10:09.190932417 +0200
> @@ -4716,7 +4716,10 @@ narrowing_initializer_constant_valid_p (
> {
>   tree inner = TREE_OPERAND (op0, 0);
>   if (inner == error_mark_node
> -  || ! INTEGRAL_MODE_P (TYPE_MODE (TREE_TYPE (inner)))
> +  || ! INTEGRAL_TYPE_P (TREE_TYPE (op0))
> +  || ! SCALAR_INT_MODE_P (TYPE_MODE (TREE_TYPE (op0)))
> +  || ! INTEGRAL_TYPE_P (TREE_TYPE (inner))
> +  || ! SCALAR_INT_MODE_P (TYPE_MODE (TREE_TYPE (inner)))
>  || (GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (TREE_TYPE (op0)))
>  > GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (TREE_TYPE (inner)
>break;
> @@ -4728,7 +4731,10 @@ narrowing_initializer_constant_valid_p (
> {
>   tree inner = TREE_OPERAND (op1, 0);
>   if (inner == error_mark_node
> -  || ! INTEGRAL_MODE_P (TYPE_MODE (TREE_TYPE (inner)))
> +  || ! INTEGRAL_TYPE_P (TREE_TYPE (op1))
> +  || ! SCALAR_INT_MODE_P (TYPE_MODE (TREE_TYPE (op1)))
> +  || ! INTEGRAL_TYPE_P (TREE_TYPE (inner))
> +  || ! SCALAR_INT_MODE_P (TYPE_MODE (TREE_TYPE (inner)))
>  || (GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (TREE_TYPE (op1)))
>  > GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (TREE_TYPE (inner)
>break;
> --- gcc/testsuite/c-c++-common/pr105998.c.jj2022-06-17 11:09:11.196703834 
> +0200
> +++ gcc/testsuite/c-c++-common/pr105998.c2022-06-17 11:09:11.196703834 
> +0200
> @@ -0,0 +1,12 @@
> +/* PR middle-end/105998 */
> +
> +typedef int __attribute__((__vector_size__ (sizeof (long long V;
> +
> +V v;
> +
> +long long
> +foo (void)
> +{
> +  long long l = (long long) ((0 | v) - ((V) { } == 0));
> +  return l;
> +}
> 
> 
>Jakub
> 

[PATCH] alpha: Introduce target specific store_data_bypass_p function [PR105209]

[Uros Bizjak via Gcc-patches]

This patch introduces alpha-specific version of store_data_bypass_p that
ignores TRAP_IF that would result in assertion failure (and internal
compiler error) in the generic store_data_bypass_p function.

While at it, also remove ev4_ist_c reservation, store_data_bypass_p
can handle the patterns with multiple sets since some time ago.

2022-06-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/105209
* config/alpha/alpha-protos.h (alpha_store_data_bypass_p): New.
* config/alpha/alpha.cc (alpha_store_data_bypass_p): New function.
(alpha_store_data_bypass_p_1): Ditto.
* config/alpha/ev4.md: Use alpha_store_data_bypass_p instead
of generic store_data_bypass_p.
(ev4_ist_c): Remove insn reservation.

gcc/testsuite/ChangeLog:

PR target/105209
* gcc.target/alpha/pr105209.c: New test.

Tested with a cross-compiler.

Pushed to master.

Uros.
diff --git a/gcc/config/alpha/alpha-protos.h b/gcc/config/alpha/alpha-protos.h
index 0c832bf039c..adfdd774ef4 100644
--- a/gcc/config/alpha/alpha-protos.h
+++ b/gcc/config/alpha/alpha-protos.h
@@ -73,6 +73,8 @@ extern void alpha_end_function (FILE *, const char *, tree);
 
 extern bool alpha_find_lo_sum_using_gp (rtx);
 
+extern int alpha_store_data_bypass_p (rtx_insn *, rtx_insn *);
+
 #ifdef REAL_VALUE_TYPE
 extern int check_float_value (machine_mode, REAL_VALUE_TYPE *, int);
 #endif
diff --git a/gcc/config/alpha/alpha.cc b/gcc/config/alpha/alpha.cc
index 3db53374c9e..0a85e66fa89 100644
--- a/gcc/config/alpha/alpha.cc
+++ b/gcc/config/alpha/alpha.cc
@@ -7564,6 +7564,75 @@ alpha_does_function_need_gp (void)
   return 0;
 }
 
+/* Helper function for alpha_store_data_bypass_p, handle just a single SET
+   IN_SET.  */
+
+static bool
+alpha_store_data_bypass_p_1 (rtx_insn *out_insn, rtx in_set)
+{
+  if (!MEM_P (SET_DEST (in_set)))
+return false;
+
+  rtx out_set = single_set (out_insn);
+  if (out_set)
+return !reg_mentioned_p (SET_DEST (out_set), SET_DEST (in_set));
+
+  rtx out_pat = PATTERN (out_insn);
+  if (GET_CODE (out_pat) != PARALLEL)
+return false;
+
+  for (int i = 0; i < XVECLEN (out_pat, 0); i++)
+{
+  rtx out_exp = XVECEXP (out_pat, 0, i);
+
+  if (GET_CODE (out_exp) == CLOBBER || GET_CODE (out_exp) == USE
+ || GET_CODE (out_exp) == TRAP_IF)
+   continue;
+
+  gcc_assert (GET_CODE (out_exp) == SET);
+
+  if (reg_mentioned_p (SET_DEST (out_exp), SET_DEST (in_set)))
+   return false;
+}
+
+  return true;
+}
+
+/* True if the dependency between OUT_INSN and IN_INSN is on the store
+   data not the address operand(s) of the store.  IN_INSN and OUT_INSN
+   must be either a single_set or a PARALLEL with SETs inside.
+
+   This alpha-specific version of store_data_bypass_p ignores TRAP_IF
+   that would result in assertion failure (and internal compiler error)
+   in the generic store_data_bypass_p function.  */
+
+int
+alpha_store_data_bypass_p (rtx_insn *out_insn, rtx_insn *in_insn)
+{
+  rtx in_set = single_set (in_insn);
+  if (in_set)
+return alpha_store_data_bypass_p_1 (out_insn, in_set);
+
+  rtx in_pat = PATTERN (in_insn);
+  if (GET_CODE (in_pat) != PARALLEL)
+return false;
+
+  for (int i = 0; i < XVECLEN (in_pat, 0); i++)
+{
+  rtx in_exp = XVECEXP (in_pat, 0, i);
+
+  if (GET_CODE (in_exp) == CLOBBER || GET_CODE (in_exp) == USE
+ || GET_CODE (in_exp) == TRAP_IF)
+   continue;
+
+  gcc_assert (GET_CODE (in_exp) == SET);
+
+  if (!alpha_store_data_bypass_p_1 (out_insn, in_exp))
+   return false;
+}
+
+  return true;
+}
 
 /* Helper function to set RTX_FRAME_RELATED_P on instructions, including
sequences.  */
diff --git a/gcc/config/alpha/ev4.md b/gcc/config/alpha/ev4.md
index 01b9a727a18..c8ff4ed8f0d 100644
--- a/gcc/config/alpha/ev4.md
+++ b/gcc/config/alpha/ev4.md
@@ -44,14 +44,7 @@ (define_insn_reservation "ev4_ld" 1
 ; Stores can issue before the data (but not address) is ready.
 (define_insn_reservation "ev4_ist" 1
   (and (eq_attr "tune" "ev4")
-   (eq_attr "type" "ist"))
-  "ev4_ib1+ev4_abox")
-
-; ??? Separate from ev4_ist because store_data_bypass_p can't handle
-; the patterns with multiple sets, like store-conditional.
-(define_insn_reservation "ev4_ist_c" 1
-  (and (eq_attr "tune" "ev4")
-   (eq_attr "type" "st_c"))
+   (eq_attr "type" "ist,st_c"))
   "ev4_ib1+ev4_abox")
 
 (define_insn_reservation "ev4_fst" 1
@@ -110,7 +103,7 @@ (define_bypass 1 "ev4_icmp" "ev4_ibr")
 (define_bypass 0
   "ev4_iaddlog,ev4_shiftcm,ev4_icmp"
   "ev4_ist"
-  "store_data_bypass_p")
+  "alpha_store_data_bypass_p")
 
 ; Multiplies use a non-pipelined imul unit.  Also, "no [ebox] insn can
 ; be issued exactly three cycles before an integer multiply completes".
@@ -121,7 +114,7 @@ (define_insn_reservation "ev4_imulsi" 21
(eq_attr "opsize" "si")))
   "ev4_ib0+ev4_imul,ev4_imul*18,ev4_ebox")
 
-(define_bypass 20 "ev4_imulsi" "ev4_ist" "store_data_bypass_p")
+(define_bypass 20 "ev4_imulsi" "ev4_ist" 

[Bug target/105209] internal compiler error: in store_data_bypass_p_1

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r13-1157-gcc378e655740e93743e7f43e14faaff707aef6c1
Author: Uros Bizjak 
Date:   Fri Jun 17 17:19:44 2022 +0200

alpha: Introduce target specific store_data_bypass_p function [PR105209]

This patch introduces alpha-specific version of store_data_bypass_p that
ignores TRAP_IF that would result in assertion failure (and internal
compiler error) in the generic store_data_bypass_p function.

While at it, also remove ev4_ist_c reservation, store_data_bypass_p
can handle the patterns with multiple sets since some time ago.

2022-06-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/105209
* config/alpha/alpha-protos.h (alpha_store_data_bypass_p): New.
* config/alpha/alpha.cc (alpha_store_data_bypass_p): New function.
(alpha_store_data_bypass_p_1): Ditto.
* config/alpha/ev4.md: Use alpha_store_data_bypass_p instead
of generic store_data_bypass_p.
(ev4_ist_c): Remove insn reservation.

gcc/testsuite/ChangeLog:

PR target/105209
* gcc.target/alpha/pr105209.c: New test.

[PATCH] i386: Fix assert in ix86_function_arg [PR105970]

[Uros Bizjak via Gcc-patches]

The mode of pointer argument should equal ptr_mode, not Pmode.

2022-06-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/105970
* config/i386/i386.cc (ix86_function_arg): Assert that
the mode of pointer argumet is equal to ptr_mode, not Pmode.

gcc/testsuite/ChangeLog:

PR target/105970
* gcc.target/i386/pr105970.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Pushed to master.

Uros.
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 3d189e124e4..f158cc3aaea 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -3348,7 +3348,7 @@ ix86_function_arg (cumulative_args_t cum_v, const 
function_arg_info )
   if (POINTER_TYPE_P (arg.type))
{
  /* This is the pointer argument.  */
- gcc_assert (TYPE_MODE (arg.type) == Pmode);
+ gcc_assert (TYPE_MODE (arg.type) == ptr_mode);
  /* It is at -WORD(AP) in the current frame in interrupt and
 exception handlers.  */
  reg = plus_constant (Pmode, arg_pointer_rtx, -UNITS_PER_WORD);
diff --git a/gcc/testsuite/gcc.target/i386/pr105970.c 
b/gcc/testsuite/gcc.target/i386/pr105970.c
new file mode 100644
index 000..326486faebf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr105970.c
@@ -0,0 +1,6 @@
+/* PR target/105970 */
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-require-effective-target maybe_x32 } */
+/* { dg-options "-mx32 -mgeneral-regs-only -maddress-mode=long" } */
+
+#include "../../gcc.dg/torture/pr68037-1.c"

[Bug c/105970] ICE in ix86_function_arg, at config/i386/i386.cc:3351

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:1f8278bfcfc7f7157bf2b405471e67dd5097636b

commit r13-1156-g1f8278bfcfc7f7157bf2b405471e67dd5097636b
Author: Uros Bizjak 
Date:   Fri Jun 17 17:01:31 2022 +0200

i386: Fix assert in ix86_function_arg [PR105970]

The mode of pointer argument should equal ptr_mode, not Pmode.

2022-06-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/105970
* config/i386/i386.cc (ix86_function_arg): Assert that
the mode of pointer argumet is equal to ptr_mode, not Pmode.

gcc/testsuite/ChangeLog:

PR target/105970
* gcc.target/i386/pr105970.c: New test.

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[wileamyp at outlook dot com via Gcc-bugs]

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

--- Comment #5 from Wileam Yonatan Phan  ---
Hi Steve,

I think I recognize you from the Fortran-lang Discourse forum!

> The committee is ready to vote, but it is still a non-existent standard.

That's technically true, since the votes haven't been cast, yet.

> The first thing required for gfortran to support any F2023 feature would be 
> the addition of a -std=f2023.  This has not been implemented, yet.

That is correct, and I guess work on implementing the `-std=f2023` flag will
start as soon as the standard is agreed upon and published. Do you know when
the committee will meet to vote?

> I'll also note that things don't magically appear in gfortran. Someone has to 
> implement it.

Hopefully I will be able to implement this particular part (REDUCE) as part of
my GSoC '22 project
. The
second phase of the project specifically addresses support in the parser, and
the third phase implements the actual parallelization.

So, my intention on filing this bug is to have a public record for tracking my
project's progress. I'll also periodically blog about it at
 and


Wish me luck!

Thanks,
Wil

[Bug c++/106011] [12 Regression] ICE: unexpected expression 'ElemSize' of kind template_parm_index

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #2 from Sam James  ---
Indeed, from the same source :)

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #4 from Steve Kargl  ---
On Fri, Jun 17, 2022 at 02:31:20PM +, wileamyp at outlook dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005
> 
> --- Comment #2 from Wileam Yonatan Phan  ---
> Wait, I thought the committee is ready to vote on it? I've seen the draft of
> the summary paper by Reid linked from here:
> 
> 

Everything you said is correct.  The committee is ready to vote,
but it is still a none existent standard.  The first thing required
for gfortran to support any F2023 feature would be the addition of
a -std=2023.  This has not been implemented, yet.

I'll also note that things don't magically appear in gfortran.
Someone has to implement it.

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Fri, Jun 17, 2022 at 02:31:20PM +, wileamyp at outlook dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005
> 
> --- Comment #2 from Wileam Yonatan Phan  ---
> Wait, I thought the committee is ready to vote on it? I've seen the draft of
> the summary paper by Reid linked from here:
> 
> 

Everything you said is correct.  The committee is ready to vote,
but it is still a none existent standard.  The first thing required
for gfortran to support any F2023 feature would be the addition of
a -std=2023.  This has not been implemented, yet.

I'll also note that things don't magically appear in gfortran.
Someone has to implement it.

[Bug c/106017] New: [PowerPC] No array-to-pointer conversion for MMA accumulator

[nemanja.i.ibm at gmail dot com via Gcc-bugs]

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

Bug ID: 106017
   Summary: [PowerPC] No array-to-pointer conversion for MMA
accumulator
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nemanja.i.ibm at gmail dot com
  Target Milestone: ---

It appears that the typical array to pointer conversion for function arguments
does not work for MMA accumulator types. The user has to explicitly convert.

Code:
$ cat aa.c 
void takeacc(__vector_quad *);
void passacc() {
__vector_quad arr[4];
#ifdef _EXPLICIT
takeacc([0]);
#else
takeacc(arr);
#endif
}

Compile (success):
$ gcc -mcpu=power10 -O3 aa.c -S -D_EXPLICIT && echo Success
Success

Compile (failure):
$ gcc -mcpu=power10 -O3 aa.c -S && echo Success
aa.c: In function 'passacc':
aa.c:7:9: error: invalid conversion to type '* __vector_quad'
7 | takeacc(arr);
  | ^~~

Version:
$ gcc --version
gcc (GCC) 12.1.1 20220524 [releases/gcc-12 r12-8410-gf0a0aeec44]
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[wileamyp at outlook dot com via Gcc-bugs]

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

--- Comment #2 from Wileam Yonatan Phan  ---
Wait, I thought the committee is ready to vote on it? I've seen the draft of
the summary paper by Reid linked from here:

[Bug c/106016] New: [PowerPC] crash with attempt to initialize array of MMA accumulators

[nemanja.i.ibm at gmail dot com via Gcc-bugs]

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

Bug ID: 106016
   Summary: [PowerPC] crash with attempt to initialize array of
MMA accumulators
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nemanja.i.ibm at gmail dot com
  Target Milestone: ---

Code:
$ cat aa.c 
void array_crash(__vector_quad *a, __vector_quad *b) {
  __vector_quad arr[2] = {*a, *b}; // Should not crash
}

Compile:
$ /opt/gcc-nightly/12/bin/gcc -mcpu=power10 -O3 aa.c -S
aa.c: In function 'array_crash':
aa.c:2:17: internal compiler error: in count_type_elements, at expr.cc:6407
2 |   __vector_quad arr[2] = {*a, *b}; // Should not crash
  | ^~~
0x105583df count_type_elements
/home/gccbuild/gcc_12_git/gcc/gcc/expr.cc:6407
0x1055cd3b categorize_ctor_elements_1
/home/gccbuild/gcc_12_git/gcc/gcc/expr.cc:6519
0x10646293 gimplify_init_constructor
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:5179
0x10647643 gimplify_modify_expr
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:6040
0x10639d93 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:15098
0x10643fd3 gimplify_stmt(tree_node**, gimple**)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:7151
0x10643fd3 gimplify_and_add(tree_node*, gimple**)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:496
0x10643fd3 gimplify_decl_expr
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:1936
0x1063ad0b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:15295
0x10642b6f gimplify_stmt(tree_node**, gimple**)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:7151
0x10642b6f gimplify_bind_expr
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:1428
0x1063a79b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:15299
0x1063e3d7 gimplify_stmt(tree_node**, gimple**)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:7151
0x1063e3d7 gimplify_body(tree_node*, bool)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:16355
0x1063e83b gimplify_function_tree(tree_node*)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:16509
0x1044cab7 cgraph_node::analyze()
/home/gccbuild/gcc_12_git/gcc/gcc/cgraphunit.cc:676
0x1044fbf7 analyze_functions
/home/gccbuild/gcc_12_git/gcc/gcc/cgraphunit.cc:1241
0x10450893 symbol_table::finalize_compilation_unit()
/home/gccbuild/gcc_12_git/gcc/gcc/cgraphunit.cc:2501
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Version:
$ /opt/gcc-nightly/12/bin/gcc --version
gcc (GCC) 12.1.1 20220524 [releases/gcc-12 r12-8410-gf0a0aeec44]
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug target/105993] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 with -O -mxop

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Uroš Bizjak  ---
Fixed.

[PATCH] i386: Fix VPMOV splitter [PR105993]

[Uros Bizjak via Gcc-patches]

REGNO should not be used with register_operand before reload because
subregs of registers or even subregs of memory match the predicate.
The build with RTL checking enabled does not tolerate REGNO with
non-reg operand.
The patch splits the splitter into two related splitters and uses
(match_dup ...) RTXes instead of REGNO comparisons.

2022-06-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/105993
* config/i386/sse.md (vpmov splitter): Use (match_dup ...)
instead of REGNO comparisons in combine splitter.

gcc/testsuite/ChangeLog:

PR target/105993
* gcc.target/i386/pr105993.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu ,-m32}.

Pushed to master.

Uros.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 3e3d96fe087..64ac490d272 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -23875,21 +23875,23 @@ (define_split
(xor:V_128_256 (match_operand:V_128_256 1 "register_operand")
   (match_operand:V_128_256 2 "register_operand"))
(match_operand:V_128_256 3 "nonimmediate_operand"))
- (match_operand:V_128_256 4 "register_operand")))]
-  "TARGET_XOP
-   && (REGNO (operands[4]) == REGNO (operands[1])
-   || REGNO (operands[4]) == REGNO (operands[2]))"
+ (match_dup 1)))]
+  "TARGET_XOP"
   [(set (match_dup 0) (if_then_else:V_128_256 (match_dup 3)
- (match_dup 5)
- (match_dup 4)))]
-{
-  /* To handle the commutivity of XOR, operands[4] is either operands[1]
- or operands[2], we need operands[5] to be the other one.  */
-  if (REGNO (operands[4]) == REGNO (operands[1]))
-operands[5] = operands[2];
-  else
-operands[5] = operands[1];
-})
+ (match_dup 2)
+ (match_dup 1)))])
+(define_split
+  [(set (match_operand:V_128_256 0 "register_operand")
+   (xor:V_128_256
+ (and:V_128_256
+   (xor:V_128_256 (match_operand:V_128_256 1 "register_operand")
+  (match_operand:V_128_256 2 "register_operand"))
+   (match_operand:V_128_256 3 "nonimmediate_operand"))
+ (match_dup 2)))]
+  "TARGET_XOP"
+  [(set (match_dup 0) (if_then_else:V_128_256 (match_dup 3)
+ (match_dup 1)
+ (match_dup 2)))])
 
 ;; XOP horizontal add/subtract instructions
 (define_insn "xop_phaddbw"
diff --git a/gcc/testsuite/gcc.target/i386/pr105993.c 
b/gcc/testsuite/gcc.target/i386/pr105993.c
new file mode 100644
index 000..79e3414f67b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr105993.c
@@ -0,0 +1,18 @@
+/* PR target/105993 */
+/* { dg-do compile } */
+/* { dg-options "-O -mxop" } */
+
+typedef unsigned short __attribute__((__vector_size__ (16))) V;
+V x, y, z;
+
+char c;
+short s;
+
+V
+foo (void)
+{
+  V u = __builtin_shufflevector (z, y, 2, 1, 0, 8, 4, 1, 7, 2);
+  V v = ~(__builtin_bswap16 (s) & (u ^ c));
+
+  return v;
+}

[Bug c/106015] New: [PowerPC] pointer to MMA accumulator not convertible to char pointer

[nemanja.i.ibm at gmail dot com via Gcc-bugs]

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

Bug ID: 106015
   Summary: [PowerPC] pointer to MMA accumulator not convertible
to char pointer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nemanja.i.ibm at gmail dot com
  Target Milestone: ---

Code:
$ cat aa.c 
unsigned char *conv(__vector_quad *a) {
  return (unsigned char *)a;
}

Compile:
gcc -mcpu=power10 -O3 aa.c -S
aa.c:2:3: error: invalid conversion from type '* __vector_quad'
2 |   return (unsigned char *)a;
  |   ^~

Version:
gcc --version
gcc (GCC) 12.1.1 20220524 [releases/gcc-12 r12-8410-gf0a0aeec44]
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug target/105993] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 with -O -mxop

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:1d6044c250e3badfa2a403fee670b295106bf4fc

commit r13-1155-g1d6044c250e3badfa2a403fee670b295106bf4fc
Author: Uros Bizjak 
Date:   Fri Jun 17 16:22:20 2022 +0200

i386: Fix VPMOV splitter [PR105993]

REGNO should not be used with register_operand before reload because
subregs of registers or even subregs of memory match the predicate.
The build with RTL checking enabled does not tolerate REGNO with
non-reg operand.
The patch splits the splitter into two related splitters and uses
(match_dup ...) RTXes instead of REGNO comparisons.

2022-06-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/105993
* config/i386/sse.md (vpmov splitter): Use (match_dup ...)
instead of REGNO comparisons in combine splitter.

gcc/testsuite/ChangeLog:

PR target/105993
* gcc.target/i386/pr105993.c: New test.

Re: [PATCH v1 2/3] RISC-V: Split slli+sh[123]add.uw opportunities to avoid zext.w

[Philipp Tomsich]

Kito, thanks: you were a few minutes ahead of my fix there.

On Fri, 17 Jun 2022 at 16:00, Kito Cheng  wrote:

> Hi Andreas:
>
> Fixed via
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d6b423882a05d7b4f40ae1e9d942c9c4c13761b7
> ,
> thanks!
>
> On Fri, Jun 17, 2022 at 4:34 PM Andreas Schwab 
> wrote:
> >
> > ../../gcc/config/riscv/bitmanip.md: In function 'rtx_insn*
> gen_split_44(rtx_ins\
> > n*, rtx_def**)':
> > ../../gcc/config/riscv/bitmanip.md:110:28: error: comparison of integer
> express\
> > ions of different signedness: 'int' and 'long unsigned int'
> [-Werror=sign-compa\
> > re]
> >   110 | if ((scale + bias) != UINTVAL (operands[2]))
> >
> > --
> > Andreas Schwab, sch...@linux-m68k.org
> > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> > "And now for something completely different."
>

Re: [PATCH] Add operators / and * for profile_{count,probability}.

[Jan Hubicka via Gcc-patches]

> PING^2
Sorry, I thought it is approved once we settled down the multiplicatoin
datatype, but apparently never sent the email.
Patch is oK.

Honza
> 
> On 5/24/22 13:35, Martin Liška wrote:
> > PING^1
> > 
> > On 5/5/22 20:15, Martin Liška wrote:
> >> On 5/5/22 15:49, Jan Hubicka wrote:
> >>> Hi,
>  The patch simplifies usage of the profile_{count,probability} types.
> 
>  Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
>  Ready to be installed?
> >>>
> >>> The reason I intentionally did not add * and / to the original API was
> >>> to detect situations where values that should be
> >>> profile_count/profile_probability are stored into integers, since
> >>> previous code used integers for everything.
> >>>
> >>> Having one to add apply_scale made him/her (mostly me :) to think if the
> >>> value is really just a fixed scale or it it should be better converted
> >>> to proper data type (count or probability).
> >>>
> >>> I guess now we completed the conversion so risk of this creeping in is
> >>> relatively low and the code indeed looks better.
> >>
> >> Yes, that's my impression as well that the profiling code is quite settled 
> >> down.
> >>
> >>> It will make it bit
> >>> harder for me to backport jump threading profile updating fixes I plan
> >>> for 12.2 but it should not be hard.
> >>
> >> You'll manage ;)
> >>
>  diff --git a/gcc/cfgloopmanip.cc b/gcc/cfgloopmanip.cc
>  index b4357c03e86..a1ac1146445 100644
>  --- a/gcc/cfgloopmanip.cc
>  +++ b/gcc/cfgloopmanip.cc
>  @@ -563,8 +563,7 @@ scale_loop_profile (class loop *loop, 
>  profile_probability p,
>   
> /* Probability of exit must be 1/iterations.  */
> count_delta = e->count ();
>  -  e->probability = profile_probability::always ()
>  -.apply_scale (1, iteration_bound);
>  +  e->probability = profile_probability::always () / 
>  iteration_bound;
> >>> However this is kind of example of the problem. 
> >>> iteration_bound is gcov_type so we can get overflow here.
> >>
> >> typedef int64_t gcov_type;
> >>
> >> and apply_scale takes int64_t types as arguments. Similarly the newly 
> >> added operators,
> >> so how can that change anything?
> >>
> >>> I guess we want to downgrade iteration_bound since it is always either 0
> >>> or int.
>  diff --git a/gcc/tree-switch-conversion.cc 
>  b/gcc/tree-switch-conversion.cc
>  index e14b4e6c94a..cef26a9878e 100644
>  --- a/gcc/tree-switch-conversion.cc
>  +++ b/gcc/tree-switch-conversion.cc
>  @@ -1782,7 +1782,7 @@ switch_decision_tree::analyze_switch_statement ()
> tree high = CASE_HIGH (elt);
>   
> profile_probability p
>  -= case_edge->probability.apply_scale (1, (intptr_t) 
>  (case_edge->aux));
>  += case_edge->probability / ((intptr_t) (case_edge->aux));
> >>>
> >>> I think the switch ranges may be also in risk of overflow?
> >>>
> >>> We could make operators to accept gcov_type or int64_t.
> >>
> >> As explained, they do.
> >>
> >> Cheers,
> >> Martin
> >>
> >>>
> >>> Thanks,
> >>> Honza
> >>
> > 
> 

[PATCH] rs6000: Fix some error messages for invalid conversions

[Segher Boessenkool]

"* something" isn't a type.  "something *" is.

Tested and committed.


Segher


2022-06-17  Segher Boessenkool  

* config/rs6000/rs6000.cc (rs6000_invalid_conversion): Correct some
types.
---
 gcc/config/rs6000/rs6000.cc | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 59481d9ac708..3d1f895ebd52 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -28305,13 +28305,13 @@ rs6000_invalid_conversion (const_tree fromtype, 
const_tree totype)
  && tomode != VOIDmode)
{
  if (frommode == XOmode)
-   return N_("invalid conversion from type %<* __vector_quad%>");
+   return N_("invalid conversion from type %<__vector_quad *%>");
  if (tomode == XOmode)
-   return N_("invalid conversion to type %<* __vector_quad%>");
+   return N_("invalid conversion to type %<__vector_quad *%>");
  if (frommode == OOmode)
-   return N_("invalid conversion from type %<* __vector_pair%>");
+   return N_("invalid conversion from type %<__vector_pair *%>");
  if (tomode == OOmode)
-   return N_("invalid conversion to type %<* __vector_pair%>");
+   return N_("invalid conversion to type %<__vector_pair *%>");
}
 }
 
-- 
1.8.3.1

Re: [PATCH] c: Extend the -Wpadded message with actual padding size

[Marek Polacek via Gcc-patches]

On Thu, Jun 16, 2022 at 09:37:32PM +0200, Vit Kabele wrote:
> When the compiler warns about padding struct to alignment boundary, it
> now also informs the user about the size of the alignment that needs to
> be added to get rid of the warning.
> 
> This removes the need of using pahole or similar tools, or manually
> determining the padding size.

Thanks for the patch, it looks reasonable, with the formatting fixed.
It would be nice to have a testcase, at least something like

struct S {
  __UINT64_TYPE__ i;
  char c;
};

The problem is what value to check for, on 32-bit arches the padding is
probably 3 bytes large and on 64-bit arches probably 7 bytes.  So I think
you could use __attribute__((aligned (8))) and then it's always 7.

> Tested on x86_64-pc-linux-gnu.
> 
> gcc/ChangeLog:
> 
>   * stor-layout.cc (finalize_record_size): Improve warning message

Missing '.' at the end.

> 
> Signed-off-by: Vit Kabele 
> ---
>  gcc/stor-layout.cc | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
> index 765f22f68b9..57ddb001780 100644
> --- a/gcc/stor-layout.cc
> +++ b/gcc/stor-layout.cc
> @@ -1781,7 +1781,14 @@ finalize_record_size (record_layout_info rli)
>&& simple_cst_equal (unpadded_size, TYPE_SIZE (rli->t)) == 0
>&& input_location != BUILTINS_LOCATION
>&& !TYPE_ARTIFICIAL (rli->t))
> -warning (OPT_Wpadded, "padding struct size to alignment boundary");
> +  {
> +  tree padding_size
> + = size_binop (MINUS_EXPR,
> + TYPE_SIZE_UNIT (rli->t), unpadded_size_unit);
> +  warning (OPT_Wpadded,
> +"padding struct size to alignment boundary with %E bytes",
> +padding_size);
> +  }
>  
>if (warn_packed && TREE_CODE (rli->t) == RECORD_TYPE
>&& TYPE_PACKED (rli->t) && ! rli->packed_maybe_necessary
> -- 
> 2.30.2
> 

Marek

Re: [PATCH v1 2/3] RISC-V: Split slli+sh[123]add.uw opportunities to avoid zext.w

[Kito Cheng via Gcc-patches]

Hi Andreas:

Fixed via 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d6b423882a05d7b4f40ae1e9d942c9c4c13761b7,
thanks!

On Fri, Jun 17, 2022 at 4:34 PM Andreas Schwab  wrote:
>
> ../../gcc/config/riscv/bitmanip.md: In function 'rtx_insn* 
> gen_split_44(rtx_ins\
> n*, rtx_def**)':
> ../../gcc/config/riscv/bitmanip.md:110:28: error: comparison of integer 
> express\
> ions of different signedness: 'int' and 'long unsigned int' 
> [-Werror=sign-compa\
> re]
>   110 | if ((scale + bias) != UINTVAL (operands[2]))
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

Re: [PATCH] xtensa: Defer storing integer constants into litpool until reload

[Takayuki 'January June' Suwa via Gcc-patches]

erratum:

-   extern unsigned int value;
+   extern unsigned short value;

On 2022/06/17 22:47, Takayuki 'January June' Suwa via Gcc-patches wrote:
> Storing integer constants into litpool in the early stage of compilation
> hinders some integer optimizations.  In fact, such integer constants are
> not subject to the constant folding process.
> 
> For example:
> 
> extern unsigned int value;
> extern void foo(void);
> void test(void) {
>   if (value == 30001)
> foo();
> }
> 
>   .literal_position
>   .literal .LC0, value
>   .literal .LC1, 30001
> test:
>   l32ra3, .LC0
>   l32ra2, .LC1
>   l16ui   a3, a3, 0
>   extui   a2, a2, 0, 16  // runtime zero-extension despite constant
>   bne a3, a2, .L1
>   j.l foo, a9
> .L1:
>   ret.n
> 
> This patch defers the placement of integer constants into litpool until
> the start of reload:
> 
>   .literal_position
>   .literal .LC0, value
>   .literal .LC1, 30001
> test:
>   l32ra3, .LC0
>   l32ra2, .LC1
>   l16ui   a3, a3, 0
>   bne a3, a2, .L1
>   j.l foo, a9
> .L1:
>   ret.n
> 
> gcc/ChangeLog:
> 
>   * config/xtensa/constraints.md (Y):
>   Change to include integer constants until reload begins.
>   * config/xtensa/predicates.md (move_operand): Ditto.
>   * config/xtensa/xtensa.cc (xtensa_emit_move_sequence):
>   Change to allow storing integer constants into litpool only after
>   reload begins.

[PATCH] xtensa: Defer storing integer constants into litpool until reload

[Takayuki 'January June' Suwa via Gcc-patches]

Storing integer constants into litpool in the early stage of compilation
hinders some integer optimizations.  In fact, such integer constants are
not subject to the constant folding process.

For example:

extern unsigned int value;
extern void foo(void);
void test(void) {
  if (value == 30001)
foo();
}

.literal_position
.literal .LC0, value
.literal .LC1, 30001
test:
l32ra3, .LC0
l32ra2, .LC1
l16ui   a3, a3, 0
extui   a2, a2, 0, 16  // runtime zero-extension despite constant
bne a3, a2, .L1
j.l foo, a9
.L1:
ret.n

This patch defers the placement of integer constants into litpool until
the start of reload:

.literal_position
.literal .LC0, value
.literal .LC1, 30001
test:
l32ra3, .LC0
l32ra2, .LC1
l16ui   a3, a3, 0
bne a3, a2, .L1
j.l foo, a9
.L1:
ret.n

gcc/ChangeLog:

* config/xtensa/constraints.md (Y):
Change to include integer constants until reload begins.
* config/xtensa/predicates.md (move_operand): Ditto.
* config/xtensa/xtensa.cc (xtensa_emit_move_sequence):
Change to allow storing integer constants into litpool only after
reload begins.
---
 gcc/config/xtensa/constraints.md | 6 --
 gcc/config/xtensa/predicates.md  | 5 +++--
 gcc/config/xtensa/xtensa.cc  | 3 ++-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/gcc/config/xtensa/constraints.md b/gcc/config/xtensa/constraints.md
index e7ac8dbfebf..0b7dcd1440e 100644
--- a/gcc/config/xtensa/constraints.md
+++ b/gcc/config/xtensa/constraints.md
@@ -113,8 +113,10 @@
 
 (define_constraint "Y"
  "A constant that can be used in relaxed MOVI instructions."
- (and (match_code "const_int,const_double,const,symbol_ref,label_ref")
-  (match_test "TARGET_AUTO_LITPOOLS")))
+ (ior (and (match_code "const_int,const_double,const,symbol_ref,label_ref")
+  (match_test "TARGET_AUTO_LITPOOLS"))
+  (and (match_code "const_int")
+  (match_test "can_create_pseudo_p ()"
 
 ;; Memory constraints.  Do not use define_memory_constraint here.  Doing so
 ;; causes reload to force some constants into the constant pool, but since
diff --git a/gcc/config/xtensa/predicates.md b/gcc/config/xtensa/predicates.md
index edd13ae41b9..0590c0f81a9 100644
--- a/gcc/config/xtensa/predicates.md
+++ b/gcc/config/xtensa/predicates.md
@@ -147,8 +147,9 @@
   (match_test "!constantpool_mem_p (op)
|| GET_MODE_SIZE (mode) % UNITS_PER_WORD == 0")))
  (ior (and (match_code "const_int")
-  (match_test "GET_MODE_CLASS (mode) == MODE_INT
-   && xtensa_simm12b (INTVAL (op))"))
+  (match_test "(GET_MODE_CLASS (mode) == MODE_INT
+&& xtensa_simm12b (INTVAL (op)))
+   || can_create_pseudo_p ()"))
  (and (match_code "const_int,const_double,const,symbol_ref,label_ref")
   (match_test "(TARGET_CONST16 || TARGET_AUTO_LITPOOLS)
&& CONSTANT_P (op)
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index d6f08b11648..c5d00acdf2c 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -1182,7 +1182,8 @@ xtensa_emit_move_sequence (rtx *operands, machine_mode 
mode)
  return 1;
}
 
-  if (! TARGET_AUTO_LITPOOLS && ! TARGET_CONST16)
+  if (! TARGET_AUTO_LITPOOLS && ! TARGET_CONST16
+ && ! (CONST_INT_P (src) && can_create_pseudo_p ()))
{
  src = force_const_mem (SImode, src);
  operands[1] = src;
-- 
2.20.1

[Bug target/106004] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Richard Earnshaw  ---
Fixed

Re: [PATCH] c++: Use fold_non_dependent_expr rather than maybe_constant_value in __builtin_shufflevector handling [PR106001]

[Jason Merrill via Gcc-patches]

On 6/17/22 03:28, Jakub Jelinek wrote:

Hi!

In this case the STATIC_CAST_EXPR expressions in the call aren't
type nor value dependent, but maybe_constant_value still ICEs on those
when processing_template_decl.  Calling fold_non_dependent_expr on it
instead fixes the ICE and folds them to INTEGER_CSTs.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


OK.


2022-06-17  Jakub Jelinek  

PR c++/106001
* typeck.cc (build_x_shufflevector): Use fold_non_dependent_expr
instead of maybe_constant_value.

* g++.dg/ext/builtin-shufflevector-4.C: New test.

--- gcc/cp/typeck.cc.jj 2022-06-04 10:34:26.261505682 +0200
+++ gcc/cp/typeck.cc2022-06-16 19:38:04.397979247 +0200
@@ -6344,7 +6344,7 @@ build_x_shufflevector (location_t loc, v
auto_vec mask;
for (unsigned i = 2; i < args->length (); ++i)
  {
-  tree idx = maybe_constant_value ((*args)[i]);
+  tree idx = fold_non_dependent_expr ((*args)[i], complain);
mask.safe_push (idx);
  }
tree exp = c_build_shufflevector (loc, arg0, arg1, mask, complain & 
tf_error);
--- gcc/testsuite/g++.dg/ext/builtin-shufflevector-4.C.jj   2022-06-16 
19:43:13.103935249 +0200
+++ gcc/testsuite/g++.dg/ext/builtin-shufflevector-4.C  2022-06-16 
19:42:37.534401207 +0200
@@ -0,0 +1,18 @@
+// PR c++/106001
+// { dg-do compile }
+
+typedef int V __attribute__((vector_size (2 * sizeof (int;
+
+template 
+void
+foo ()
+{
+  V v = {};
+  v = __builtin_shufflevector (v, v, static_cast(1), 
static_cast(0));
+}
+
+void
+bar ()
+{
+  foo <0> ();
+}

Jakub

[committed] arm: fix checking ICE in arm_print_operand [PR106004]

[Richard Earnshaw via Gcc-patches]

Sigh, another instance where I incorrectly used XUINT instead of
UINTVAL.

I've also made the code here a little more robust (although I think
this case can't in fact be reached) if the 32-bit clear mask includes
bit 31.  This case, if reached, would print out an out-of-range value
based on the size of the compiler's HOST_WIDE_INT type due to
sign-extension.  We avoid this by masking the value after inversion.

gcc/ChangeLog:
PR target/106004
* config/arm/arm.cc (arm_print_operand, case 'V'): Use UINTVAL.
Clear bits in the mask above bit 31.
---
 gcc/config/arm/arm.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 2925907b436..33fb98d5cad 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -24199,7 +24199,8 @@ arm_print_operand (FILE *stream, rtx x, int code)
 	return;
 	  }
 
-	unsigned HOST_WIDE_INT val = ~XUINT (x, 0);
+	unsigned HOST_WIDE_INT val
+	  = ~UINTVAL (x) & HOST_WIDE_INT_UC (0x);
 	int lsb = exact_log2 (val & -val);
 	asm_fprintf (stream, "#%d, #%d", lsb,
 		 (exact_log2 (val + (val & -val)) - lsb));

[Bug target/106004] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Earnshaw :

https://gcc.gnu.org/g:040f8224617ad3924f606c8982da369f898693d1

commit r13-1152-g040f8224617ad3924f606c8982da369f898693d1
Author: Richard Earnshaw 
Date:   Fri Jun 17 14:25:51 2022 +0100

arm: fix checking ICE in arm_print_operand [PR106004]

Sigh, another instance where I incorrectly used XUINT instead of
UINTVAL.

I've also made the code here a little more robust (although I think
this case can't in fact be reached) if the 32-bit clear mask includes
bit 31.  This case, if reached, would print out an out-of-range value
based on the size of the compiler's HOST_WIDE_INT type due to
sign-extension.  We avoid this by masking the value after inversion.

gcc/ChangeLog:
PR target/106004
* config/arm/arm.cc (arm_print_operand, case 'V'): Use UINTVAL.
Clear bits in the mask above bit 31.

Re: [PATCH] c: Extend the -Wpadded message with actual padding size

[Eric Gallager via Gcc-patches]

On Thu, Jun 16, 2022 at 3:37 PM Vit Kabele  wrote:
>
> When the compiler warns about padding struct to alignment boundary, it
> now also informs the user about the size of the alignment that needs to
> be added to get rid of the warning.

Hi, thanks for taking the time to improve -Wpadded; I have been
wishing that GCC's implementation of -Wpadded would print this
information for a while now and thought there was a bug open for it,
but can't seem to find it now...

>
> This removes the need of using pahole or similar tools, or manually
> determining the padding size.
>
> Tested on x86_64-pc-linux-gnu.
>
> gcc/ChangeLog:
>
> * stor-layout.cc (finalize_record_size): Improve warning message
>
> Signed-off-by: Vit Kabele 
> ---
>  gcc/stor-layout.cc | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
> index 765f22f68b9..57ddb001780 100644
> --- a/gcc/stor-layout.cc
> +++ b/gcc/stor-layout.cc
> @@ -1781,7 +1781,14 @@ finalize_record_size (record_layout_info rli)
>&& simple_cst_equal (unpadded_size, TYPE_SIZE (rli->t)) == 0
>&& input_location != BUILTINS_LOCATION
>&& !TYPE_ARTIFICIAL (rli->t))
> -warning (OPT_Wpadded, "padding struct size to alignment boundary");
> +  {
> +  tree padding_size
> +   = size_binop (MINUS_EXPR,
> +   TYPE_SIZE_UNIT (rli->t), unpadded_size_unit);
> +  warning (OPT_Wpadded,
> +  "padding struct size to alignment boundary with %E bytes",
> +  padding_size);
> +  }

Style nit: indentation seems off; check your tabs vs. spaces etc.

>
>if (warn_packed && TREE_CODE (rli->t) == RECORD_TYPE
>&& TYPE_PACKED (rli->t) && ! rli->packed_maybe_necessary
> --
> 2.30.2

Re: [committed] libstdc++: Support constexpr global std::string for size < 15 [PR105995]

[Jonathan Wakely via Gcc-patches]

On Thu, 16 Jun 2022 at 20:23, Jonathan Wakely via Libstdc++
 wrote:
>
> Tested x86_64-linux, pushed to trunk.

Somehow I messed up the test in the commit I pushed (but not the one I
tested ... weird).

Fixed at r13-1151-g0f96ac43fa0a5f by the attached patch.

-- >8 --

   libstdc++: Add missing #include  to new test

   Somehow I pushed a different version of this test to the one I actually
   tested.

   libstdc++-v3/ChangeLog:

   * testsuite/21_strings/basic_string/cons/char/105995.cc: Add
   missing #include.
commit 0f96ac43fa0a5fdbfce317b274233852d5b46d23
Author: Jonathan Wakely 
Date:   Fri Jun 17 13:29:05 2022

libstdc++: Add missing #include  to new test

Somehow I pushed a different version of this test to the one I actually
tested.

libstdc++-v3/ChangeLog:

* testsuite/21_strings/basic_string/cons/char/105995.cc: Add
missing #include.

diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/105995.cc 
b/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/105995.cc
index aa8bcba3dca..4764ceff72a 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/105995.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/105995.cc
@@ -2,6 +2,8 @@
 // { dg-do compile { target c++20 } }
 // { dg-require-effective-target cxx11_abi }
 
+#include 
+
 // PR libstdc++/105995
 // Not required by the standard, but supported for QoI.
 constexpr std::string pr105995_empty;

[PATCH 2/2] aarch64: Fix bit-field alignment in param passing [PR105549]

[Christophe Lyon via Gcc-patches]

While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. These tests are generated during 'make
check' and enabling DFP made generation different (not sure if new
non-DFP tests are generated, or if existing ones are generated
differently, the tests in question are huge and difficult to compare).

Anyway, I reduced the problem to what I attach at the end of the new
gcc.target/aarch64/aapcs64/va_arg-17.c test and rewrote it in the same
scheme as other va_arg* AArch64 tests.  Richard Sandiford further
reduced this to a non-vararg function, added as a second testcase.

This is a tough case mixing bit-fields and alignment, where
aarch64_function_arg_alignment did not follow what its descriptive
comment says: we want to use the natural alignment of the bit-field
type only if the user didn't reduce the alignment for the bit-field
itself.

The fix would be very small, except that this introduces a new ABI
break, and we have to warn about that.  Since this actually fixes a
problem introduced in GCC 9.1, we keep the old computation to detect
when we now behave differently.

This patch adds two new tests (va_arg-17.c and
pr105549.c). va_arg-17.c contains the reduced offending testcase from
struct-layout-1.exp for reference.  We update some tests introduced by
the previous patch, where parameters with bit-fields and packed
attribute now emit a different warning.

We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.

2022-06-16  Christophe Lyon  

gcc/
PR target/105549
* config/aarch64/aarch64.cc (aarch64_function_arg_alignment):
Check DECL_PACKED for bitfield.
(aarch64_layout_arg): Warn when parameter passing ABI changes.
(aarch64_function_arg_boundary): Likewise.
(aarch64_gimplify_va_arg_expr): Likewise.

gcc/testsuite/
PR target/105549
* gcc.target/aarch64/bitfield-abi-warning-align16-O0.c: Update.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: Update.
* gcc.target/aarch64/aapcs64/va_arg-17.c: New test.
* gcc.target/aarch64/pr105549.c: New test.
---
 gcc/config/aarch64/aarch64.cc |  87 ---
 .../gcc.target/aarch64/aapcs64/va_arg-17.c| 105 ++
 .../aarch64/bitfield-abi-warning-align16-O0.c |  60 +-
 .../aarch64/bitfield-abi-warning-align16-O2.c |  60 +-
 gcc/testsuite/gcc.target/aarch64/pr105549.c   |  12 ++
 5 files changed, 249 insertions(+), 75 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-17.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/pr105549.c

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 13984e3435b..e7a6288d7a7 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -7248,15 +7248,19 @@ aarch64_vfp_is_call_candidate (cumulative_args_t 
pcum_v, machine_mode mode,
 /* Given MODE and TYPE of a function argument, return the alignment in
bits.  The idea is to suppress any stronger alignment requested by
the user and opt for the natural alignment (specified in AAPCS64 \S
-   4.1).  ABI_BREAK is set to true if the alignment was incorrectly
-   calculated in versions of GCC prior to GCC-9.  This is a helper
+   4.1).  ABI_BREAK is set to the old alignment if the alignment was
+   incorrectly calculated in versions of GCC prior to GCC-9.
+   ABI_BREAK_PACKED is set to the old alignment if it was incorrectly
+   calculated in versions between GCC-9 and GCC-13.  This is a helper
function for local use only.  */
 
 static unsigned int
 aarch64_function_arg_alignment (machine_mode mode, const_tree type,
-   unsigned int *abi_break)
+   unsigned int *abi_break,
+   unsigned int *abi_break_packed)
 {
   *abi_break = 0;
+  *abi_break_packed = 0;
   if (!type)
 return GET_MODE_ALIGNMENT (mode);
 
@@ -7272,6 +7276,7 @@ aarch64_function_arg_alignment (machine_mode mode, 
const_tree type,
 return TYPE_ALIGN (TREE_TYPE (type));
 
   unsigned int alignment = 0;
+  unsigned int bitfield_alignment_with_packed = 0;
   unsigned int bitfield_alignment = 0;
   for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
 if (TREE_CODE (field) == FIELD_DECL)
@@ -7290,12 +7295,32 @@ aarch64_function_arg_alignment (machine_mode mode, 
const_tree type,
   "s" contains only one Fundamental Data Type (the int field)
   but gains 8-byte alignment and size thanks to "e".  */
alignment = std::max (alignment, DECL_ALIGN (field));
+
if (DECL_BIT_FIELD_TYPE (field))
- bitfield_alignment
-   = std::max (bitfield_alignment,
-   TYPE_ALIGN 

[PATCH 1/2] aarch64: fix warning emission for ABI break since GCC 9.1

[Christophe Lyon via Gcc-patches]

While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, I noticed
that the GCC 9.1 warning is not emitted in all the cases where it
should be.  This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.

I split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1.  This way, patch #1 can be back-ported to
release branches if needed to fix the GCC 9.1 warning issue.

The fix in aarch64_layout_arg highlights the bug fixed by patch #2:
GCC 9 should not have changed behavior for nregs==1, and this patch
makes it warn so as to be consistent.

The part of the fix in aarch64_function_arg_boundary (replacing & with
&&) looks like an oversight of a previous commit in this area which
changed 'abi_break' from a boolean to an integer.

2022-06-16  Christophe Lyon  

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_layout_arg): Fix warning
emission.
(aarch64_function_arg_boundary): Fix typo.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-abi-warning-align16-O0.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O0.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
---
 gcc/config/aarch64/aarch64.cc |  20 ++-
 .../aarch64/bitfield-abi-warning-align16-O0.c |  81 
 .../aarch64/bitfield-abi-warning-align16-O2.c |  86 
 .../aarch64/bitfield-abi-warning-align8-O0.c  |   7 +
 .../aarch64/bitfield-abi-warning-align8-O2.c  |  16 +++
 .../gcc.target/aarch64/bitfield-abi-warning.h | 125 ++
 6 files changed, 329 insertions(+), 6 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/aarch64/bitfield-abi-warning-align16-O0.c
 create mode 100644 
gcc/testsuite/gcc.target/aarch64/bitfield-abi-warning-align16-O2.c
 create mode 100644 
gcc/testsuite/gcc.target/aarch64/bitfield-abi-warning-align8-O0.c
 create mode 100644 
gcc/testsuite/gcc.target/aarch64/bitfield-abi-warning-align8-O2.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/bitfield-abi-warning.h

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index d049f9a9819..13984e3435b 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -7453,23 +7453,31 @@ aarch64_layout_arg (cumulative_args_t pcum_v, const 
function_arg_info )
   if (allocate_ncrn && (ncrn + nregs <= NUM_ARG_REGS))
 {
   gcc_assert (nregs == 0 || nregs == 1 || nregs == 2);
+  unsigned int alignment;
 
   /* C.8 if the argument has an alignment of 16 then the NGRN is
 rounded up to the next even number.  */
-  if (nregs == 2
- && ncrn % 2
+  alignment = aarch64_function_arg_alignment (mode, type, _break);
+  if (ncrn % 2
  /* The == 16 * BITS_PER_UNIT instead of >= 16 * BITS_PER_UNIT
 comparison is there because for > 16 * BITS_PER_UNIT
 alignment nregs should be > 2 and therefore it should be
 passed by reference rather than value.  */
- && (aarch64_function_arg_alignment (mode, type, _break)
+ && (alignment
  == 16 * BITS_PER_UNIT))
{
+ /* We want to emit a warning even if nregs == 1, because
+although we do not round ncrn up in this case, the callee
+has a different (broken) expectation.  */
  if (abi_break && warn_psabi && currently_expanding_gimple_stmt)
inform (input_location, "parameter passing for argument of type "
"%qT changed in GCC 9.1", type);
- ++ncrn;
- gcc_assert (ncrn + nregs <= NUM_ARG_REGS);
+
+ if (ncrn % 2)
+   {
+ ++ncrn;
+ gcc_assert (ncrn + nregs <= NUM_ARG_REGS);
+   }
}
 
   /* If an argument with an SVE mode needs to be shifted up to the
@@ -7648,7 +7656,7 @@ aarch64_function_arg_boundary (machine_mode mode, 
const_tree type)
   unsigned int alignment = aarch64_function_arg_alignment (mode, type,
   _break);
   alignment = MIN (MAX (alignment, PARM_BOUNDARY), STACK_BOUNDARY);
-  if (abi_break & warn_psabi)
+  if (abi_break && warn_psabi)
 {
   abi_break = MIN (MAX (abi_break, PARM_BOUNDARY), STACK_BOUNDARY);
   if (alignment != abi_break)
diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-abi-warning-align16-O0.c 
b/gcc/testsuite/gcc.target/aarch64/bitfield-abi-warning-align16-O0.c
new file mode 100644
index 000..0a1f54acb2d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/bitfield-abi-warning-align16-O0.c
@@ -0,0 +1,81 @@
+/* { dg-do compile } */
+/* { dg-options "-O0 -save-temps" } */
+
+#define ALIGN 16
+#define EXTRA
+
+#include "bitfield-abi-warning.h"
+
+/* 

[Bug libstdc++/106014] Overload std::distance for filesystem::recursive_directory_iterator

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

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

--- Comment #3 from Jonathan Wakely  ---
Also, ranges::advance doesn't use the custom advance for path::iterator. Maybe
we should make path::iterator satisfy the random_access_iterator concept. We
can't do that for directory iterators though, so maybe we want another
customization point for internal use.

[Bug libstdc++/106014] Overload std::distance for filesystem::recursive_directory_iterator

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

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

--- Comment #2 from Jonathan Wakely  ---
We already have a custom std::distance for filesystem::path::iterator, and
std::ranges::distance doesn't use that either. Maybe we want to add a
customization point for std::ranges::distance that we can use internally.

We also already have a custom std::advance for filesystem::path::iterator,
because we can advance by N steps in O(1) instead of O(N). That might be
possible for directory iterators too, so that advancing a directory iterator by
N would only create a path for the final increment, not the intermediate ones.
It wouldn't be O(1) but it would be a much cheaper O(N) than it is now.

[PATCH][pushed] docs: add missing table header

[Martin Liška]

libgomp/ChangeLog:

* libgomp.texi: Add table header for new features of
OpenMP 5.2.
---
 libgomp/libgomp.texi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index a5e54456746..2c4622c1092 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -353,6 +353,7 @@ The OpenMP 4.5 specification is fully supported.
 @unnumberedsubsec New features listed in Appendix B of the OpenMP specification
 
 @multitable @columnfractions .60 .10 .25
+@headitem Description @tab Status @tab Comments
 @item @code{omp_in_explicit_task} routine and @emph{implicit-task-var} ICV
   @tab N @tab
 @item @code{omp}/@code{ompx}/@code{omx} sentinels and @code{omp_}/@code{ompx_}
-- 
2.36.1