[Bug target/108654] Incorrect codegen of RVV GCC

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from JuzheZhong  ---
Fixed

[Bug target/108654] Incorrect codegen of RVV GCC

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #3 from JuzheZhong  ---
FIXED

[Bug analyzer/109098] Encoding errors on SARIF output for non-UTF-8 source files

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

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

--- Comment #8 from Hans-Peter Nilsson  ---
(In reply to David Malcolm from comment #7)
> The invalid UTF-8 in the patch seems to have broken the server-side script:

Maybe the not-really-utf8 files need to be marked in some way in the git repo
to be safely handled for future checkout and updates, including the problematic
scripting?  However, reading gitattributes(5) it's not obvious how.

[Bug target/109279] RISC-V: complex constants synthesized should be improved

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #13 from Vineet Gupta  ---
Ok it seems I missed _some_ improvement with prev change, although not ideal
still.

With 2e886eef7f2b

li  a0,0x0101_
addia0,a0,0x0101
sllia0,a0,16
addia0,a0,0x0101
sllia0,a0,16
addia0,a0,0x0101
ret

Allow can_create_pseudo() in splitter

li  a0,0x0101_
addia5,a5,0x0101
mv  a0,a5
sllia5,a5,32
add a0,a5,a0
ret

[pushed] diagnostics: ensure that .sarif files are UTF-8 encoded [PR109098]

[David Malcolm via Gcc-patches]

PR analyzer/109098 notes that the SARIF spec mandates that .sarif
files are UTF-8 encoded, but -fdiagnostics-format=sarif-file naively
assumes that the source files are UTF-8 encoded when quoting source
artefacts in the .sarif output, which can lead to us writing out
.sarif files with non-UTF-8 bytes in them (which break my reporting
scripts).

The root cause is that sarif_builder::maybe_make_artifact_content_object
was using maybe_read_file to load the file content as bytes, and
assuming they were UTF-8 encoded.

This patch reworks both overloads of this function (one used for the
whole file, the other for snippets of quoted lines) so that they go
through input.cc's file cache, which attempts to decode the input files
according to the input charset, and then encode as UTF-8.  They also
check that the result actually is UTF-8, for cases where the input
charset is missing, or incorrectly specified, and omit the quoted
source for such awkward cases.

Doing so fixes all of the cases I've encountered.

The patch adds a new:
  { dg-final { verify-sarif-file } }
directive to all SARIF test cases in the test suite, which verifies
that the output is UTF-8 encoded, and is valid JSON.  In particular
it verifies that when we complain about encoding problems, the .sarif
report we emit is itself correctly encoded.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Integration testing shows no regressions, and a fix for the case
seen in haproxy-2.7.1.
Pushed to trunk as r13-6861-gd495ea2b232f3e.

FWIW the invalid UTF-8 in the patch (in some of the test cases) seems
to have broken the server-side scripts:

Enumerating objects: 51, done.
Counting objects: 100% (51/51), done.
Delta compression using up to 64 threads
Compressing objects: 100% (29/29), done.
Writing objects: 100% (29/29), 7.74 KiB | 1.29 MiB/s, done.
Total 29 (delta 22), reused 0 (delta 0), pack-reused 0
remote: Traceback (most recent call last):
remote:   File "hooks/post_receive.py", line 118, in 
remote: post_receive(refs_data, args.submitter_email)
remote:   File "hooks/post_receive.py", line 65, in post_receive
remote: submitter_email)
remote:   File "hooks/post_receive.py", line 47, in post_receive_one
remote: update.send_email_notifications()
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 189, 
in send_email_notifications
remote: self.__email_new_commits()
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 
1031, in __email_new_commits
remote: commit, self.get_standard_commit_email(commit))
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 
1011, in __send_commit_email
remote: default_diff=email.diff)
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 946, 
in __maybe_get_email_custom_contents
remote: hook_input=json.dumps(hooks_data),
remote:   File "/usr/lib64/python2.7/json/__init__.py", line 244, in dumps
remote: return _default_encoder.encode(obj)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 207, in encode
remote: chunks = self.iterencode(o, _one_shot=True)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 270, in iterencode
remote: return _iterencode(o, 0)
remote: UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 in position 
13147: invalid start byte
To git+ssh://gcc.gnu.org/git/gcc.git
   13ec81eb4c3..d495ea2b232  master -> master

gcc/ChangeLog:
PR analyzer/109098
* diagnostic-format-sarif.cc (read_until_eof): Delete.
(maybe_read_file): Delete.
(sarif_builder::maybe_make_artifact_content_object): Use
get_source_file_content rather than maybe_read_file.
Reject it if it's not valid UTF-8.
* input.cc (file_cache_slot::get_full_file_content): New.
(get_source_file_content): New.
(selftest::check_cpp_valid_utf8_p): New.
(selftest::test_cpp_valid_utf8_p): New.
(selftest::input_cc_tests): Call selftest::test_cpp_valid_utf8_p.
* input.h (get_source_file_content): New prototype.

gcc/testsuite/ChangeLog:
PR analyzer/109098
* c-c++-common/diagnostic-format-sarif-file-1.c: Add
verify-sarif-file directive.
* c-c++-common/diagnostic-format-sarif-file-2.c: Likewise.
* c-c++-common/diagnostic-format-sarif-file-3.c: Likewise.
* c-c++-common/diagnostic-format-sarif-file-4.c: Likewise.
* c-c++-common/diagnostic-format-sarif-file-Wbidi-chars.c: New
test case, adapted from Wbidi-chars-1.c.
* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-1.c:
New test case.
* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-2.c:
New test case.
* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-3.c:
New test case, adapted from cpp/Winvalid-utf8-1.c.
* 

[Bug analyzer/109098] Encoding errors on SARIF output for non-UTF-8 source files

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from David Malcolm  ---
Should be fixed on trunk by r13-6861-gd495ea2b232f3e:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d495ea2b232f3eb50155d7c7362c09a744766746

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff_plain;h=d495ea2b232f3eb50155d7c7362c09a744766746

The invalid UTF-8 in the patch seems to have broken the server-side script:

Enumerating objects: 51, done.
Counting objects: 100% (51/51), done.
Delta compression using up to 64 threads
Compressing objects: 100% (29/29), done.
Writing objects: 100% (29/29), 7.74 KiB | 1.29 MiB/s, done.
Total 29 (delta 22), reused 0 (delta 0), pack-reused 0
remote: Traceback (most recent call last):
remote:   File "hooks/post_receive.py", line 118, in 
remote: post_receive(refs_data, args.submitter_email)
remote:   File "hooks/post_receive.py", line 65, in post_receive
remote: submitter_email)
remote:   File "hooks/post_receive.py", line 47, in post_receive_one
remote: update.send_email_notifications()
remote:   File
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 189,
in send_email_notifications
remote: self.__email_new_commits()
remote:   File
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line
1031, in __email_new_commits
remote: commit, self.get_standard_commit_email(commit))
remote:   File
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line
1011, in __send_commit_email
remote: default_diff=email.diff)
remote:   File
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 946,
in __maybe_get_email_custom_contents
remote: hook_input=json.dumps(hooks_data),
remote:   File "/usr/lib64/python2.7/json/__init__.py", line 244, in dumps
remote: return _default_encoder.encode(obj)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 207, in encode
remote: chunks = self.iterencode(o, _one_shot=True)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 270, in iterencode
remote: return _iterencode(o, 0)
remote: UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 in position
13147: invalid start byte
To git+ssh://gcc.gnu.org/git/gcc.git
   13ec81eb4c3..d495ea2b232  master -> master

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

--- Comment #12 from Andrew Pinski  ---
Here is something to look into:
#define const1 0x0101010101010101ULL 
#define const2 0x0080402010080400ULL 
#define const0 const1
unsigned long long g(unsigned long long occ, const unsigned int sq) {
  return const0 ;
}
unsigned long long f(unsigned long long occ, const unsigned int sq) {
  unsigned long long t= (const0)>>32<<32 ;
  unsigned long long t1= (unsigned int)(const0) ;
  asm("":"+r"(t));
  return t | t1;
}

[Bug target/109279] RISC-V: complex constants synthesized should be improved

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #11 from Vineet Gupta  ---
With change suggested by @pinksia, I do see that in split1, 
riscv_move_integer() -> riscv_split_integer() is now called.

[Bug target/109279] RISC-V: complex constants synthesized should be improved

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #10 from Vineet Gupta  ---
I tried removing the in_splitter  check (in 2 places), but no change in
results.

@@ -1313,7 +1313,7 @@ riscv_force_temporary (rtx dest, rtx value, bool
in_splitter)

-  if (can_create_pseudo_p () && !in_splitter)
+  if (can_create_pseudo_p ())


@@ -1669,7 +1669,7 @@ riscv_move_integer (rtx temp, rtx dest, HOST_WIDE_INT
value,

-  bool can_create_pseudo = can_create_pseudo_p () && ! in_splitter;
+  bool can_create_pseudo = can_create_pseudo_p ();

Re: Building gcc-12 on MacOS Ventura (aarch64)

[Stuff Received]

On 2023-03-24 19:51, Chris Johns wrote:

On 25/3/2023 10:07 am, Jonathan Wakely wrote:

On Fri, 24 Mar 2023, 23:07 Jonathan Wakely, mailto:jwakely@gmail.com>> wrote:
 On Fri, 24 Mar 2023, 23:03 Chris Johns, mailto:ch...@contemporary.net.au>> wrote:

 Hi,

 I am sorting out some issues building RTEMS on MacOS including the M
 processors.
 The building gcc-12.2.1 for the few architectures I tested fail with 
sig
 faults
 in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a
 result I
 wondered about bootstrapping gcc and using that to build the tools
 rather than
 clang from Xcode.

 Is aarch64-apple-darwin supported?

 No. Iain Sandoe has some personal branches with changes to support it, but
 the changes are not in the official gcc repo yet. If you search the
 gcc-h...@gcc.gnu.org  list you'll find links 
to
 his code. I think Homebrew is his patches too.

*uses his patches too.



I tried Iain's repo and it fails in the same way.

I have been building the tools on MacOS for over a decade with just the Apple
base to make sure we have a clean platform without any issues. To do that I
avoid MacPorts and Homebrew. I am fine with our users making use of those
packages however knowing a build works with just the Apple support makes our
support simpler.

Chris


I am able to build gcc from Iain's repo gcc-darwin-arm64 on an M1 Mini, 
running macos 11.3.1, using the following configuration.  (Change your 
language preferences accordingly.)  I used make -j4.


CC=/opt/homebrew/bin/gcc-12 \
CXX=/opt/homebrew/bin/g++-12 \
../../src/gcc-darwin-arm64/configure \
--prefix=$HOME/gm2/arm64 \
--exec-prefix=$HOME/gm2/arm64 \
--enable-languages=c,c++,m2 \
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk \
--with-mpc=/opt/homebrew \
--with-gmp=/opt/homebrew \
--with-mpfr=/opt/homebrew \
--disable-bootstrap \
--enable-threads=posix

However, you must first define HAVE_FCNTL_H to 1 in libiberty/config.h 
(that is missed somehow by configure).


Sincerely,
N.

[pushed] docs, analyzer: improvements to "Debugging the Analyzer"

[David Malcolm via Gcc-patches]

Successfully bootstrapped on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6859-gfdb06fe68253d2

gcc/ChangeLog:
* doc/analyzer.texi (Debugging the Analyzer): Add notes on useful
debugging options.
(Special Functions for Debugging the Analyzer): Convert to a
table, and rewrite in places.
(Other Debugging Techniques): Add notes on how to compare two
different exploded graphs.

Signed-off-by: David Malcolm 
---
 gcc/doc/analyzer.texi | 125 +++---
 1 file changed, 116 insertions(+), 9 deletions(-)

diff --git a/gcc/doc/analyzer.texi b/gcc/doc/analyzer.texi
index 0afd1143d4c..2692b0e3ece 100644
--- a/gcc/doc/analyzer.texi
+++ b/gcc/doc/analyzer.texi
@@ -437,13 +437,97 @@ than printing the underlying variable name.
 @cindex analyzer, debugging
 @cindex static analyzer, debugging
 
+When debugging the analyzer I normally use all of these options
+together:
+
+@smallexample
+./xgcc -B. \
+  -S \
+  -fanalyzer \
+  OTHER_GCC_ARGS \
+  -wrapper gdb,--args \
+  -fdump-analyzer-stderr \
+  -fanalyzer-fine-grained \
+  -fdump-ipa-analyzer=stderr
+@end smallexample
+
+where:
+
+@itemize @bullet
+@item @code{./xgcc -B.}
+is the usual way to invoke a self-built GCC from within the @file{BUILDDIR/gcc}
+subdirectory.
+
+@item @code{-S}
+so that the driver (@code{./xgcc}) invokes @code{cc1}, but doesn't bother
+running the assembler or linker (since the analyzer runs inside @code{cc1}).
+
+@item @code{-fanalyzer}
+enables the analyzer, obviously.
+
+@item @code{-wrapper gdb,--args}
+invokes @code{cc1} under the debugger so that I can debug @code{cc1} and
+set breakpoints and step through things.
+
+@item @code{-fdump-analyzer-stderr}
+so that the logging interface is enabled and goes to stderr, which often
+gives valuable context into what's happening when stepping through the
+analyzer
+
+@item @code{-fanalyzer-fine-grained}
+which splits the effect of every statement into its own
+exploded_node, rather than the default (which tries to combine
+successive stmts to reduce the size of the exploded_graph).  This makes
+it easier to see exactly where a particular change happens.
+
+@item @code{-fdump-ipa-analyzer=stderr}
+which dumps the GIMPLE IR seen by the analyzer pass to stderr
+
+@end itemize
+
+Other useful options:
+
+@itemize @bullet
+@item @code{-fdump-analyzer-exploded-graph}
+which dumps a @file{SRC.eg.dot} GraphViz file that I can look at (with
+python-xdot)
+
+@item @code{-fdump-analyzer-exploded-nodes-2}
+which dumps a @file{SRC.eg.txt} file containing the full @code{exploded_graph}.
+
+@end itemize
+
+Assuming that you have the
+@uref{https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html,,python
 support scripts for gdb}
+installed, you can use:
+
+@smallexample
+(gdb) break-on-saved-diagnostic
+@end smallexample
+
+to put a breakpoint at the place where a diagnostic is saved during
+@code{exploded_graph} exploration, to see where a particular diagnostic
+is being saved, and:
+
+@smallexample
+(gdb) break-on-diagnostic
+@end smallexample
+
+to put a breakpoint at the place where diagnostics are actually emitted.
+
 @subsection Special Functions for Debugging the Analyzer
 
 The analyzer recognizes various special functions by name, for use
-in debugging the analyzer.  Declarations can be seen in the testsuite
+in debugging the analyzer, and for use in DejaGnu tests.
+
+The declarations of these functions can be seen in the testsuite
 in @file{analyzer-decls.h}.  None of these functions are actually
-implemented.
+implemented in terms of code, merely as @code{known_function} subclasses
+(in @file{gcc/analyzer/kf-analyzer.cc}).
+
+@table @code
 
+@item __analyzer_break
 Add:
 @smallexample
   __analyzer_break ();
@@ -452,6 +536,7 @@ to the source being analyzed to trigger a breakpoint in the 
analyzer when
 that source is reached.  By putting a series of these in the source, it's
 much easier to effectively step through the program state as it's analyzed.
 
+@item __analyzer_describe
 The analyzer handles:
 
 @smallexample
@@ -462,6 +547,7 @@ by emitting a warning describing the 2nd argument (which 
can be of any
 type), at a verbosity level given by the 1st argument.  This is for use when
 debugging, and may be of use in DejaGnu tests.
 
+@item __analyzer_dump
 @smallexample
 __analyzer_dump ();
 @end smallexample
@@ -469,6 +555,7 @@ __analyzer_dump ();
 will dump the copious information about the analyzer's state each time it
 reaches the call in its traversal of the source.
 
+@item __analyzer_dump_capacity
 @smallexample
 extern void __analyzer_dump_capacity (const void *ptr);
 @end smallexample
@@ -476,6 +563,7 @@ extern void __analyzer_dump_capacity (const void *ptr);
 will emit a warning describing the capacity of the base region of
 the region pointed to by the 1st argument.
 
+@item __analyzer_dump_escaped
 @smallexample
 extern void __analyzer_dump_escaped (void);
 @end smallexample
@@ -484,16 +572,19 @@ will 

Re: Building gcc-12 on MacOS Ventura (aarch64)

[Chris Johns]

On 25/3/2023 10:07 am, Jonathan Wakely wrote:
> On Fri, 24 Mar 2023, 23:07 Jonathan Wakely,  > wrote:
> On Fri, 24 Mar 2023, 23:03 Chris Johns,  > wrote:
> 
> Hi,
> 
> I am sorting out some issues building RTEMS on MacOS including the M
> processors.
> The building gcc-12.2.1 for the few architectures I tested fail with 
> sig
> faults
> in xgcc when building the runtime. I tried arm, aarch64 and sparc. As 
> a
> result I
> wondered about bootstrapping gcc and using that to build the tools
> rather than
> clang from Xcode.
> 
> Is aarch64-apple-darwin supported?
> 
> No. Iain Sandoe has some personal branches with changes to support it, but
> the changes are not in the official gcc repo yet. If you search the
> gcc-h...@gcc.gnu.org  list you'll find links 
> to
> his code. I think Homebrew is his patches too.
> 
> *uses his patches too.
> 

I tried Iain's repo and it fails in the same way.

I have been building the tools on MacOS for over a decade with just the Apple
base to make sure we have a clean platform without any issues. To do that I
avoid MacPorts and Homebrew. I am fine with our users making use of those
packages however knowing a build works with just the Apple support makes our
support simpler.

Chris

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

--- Comment #9 from Andrew Pinski  ---
The comment in riscv.cc:
  /* We can't call gen_reg_rtx from a splitter, because this might realloc
 the regno_reg_rtx array, which would invalidate reg rtx pointers in the
 combine undo buffer.  */
  bool can_create_pseudo = can_create_pseudo_p () && ! in_splitter;

is no longer true after r12-8030-g61bee6aed26eb3

so you should be able to get rid of the `&& ! in_splitter` part.

[Bug c/106465] ICE for VLA in struct in parameter of nested function

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #4 from Martin Uecker  ---
This version works with 4.1.2

https://godbolt.org/z/x4v6aTv87

int h(void)
{
int g(int m, struct { char (*p)[m]; }* b) { return sizeof *b->p; }
return g(5, 0);
}

Re: [PATCH] PR target/105325, Make load/cmp fusion know about prefixed loads

[Michael Meissner via Gcc-patches]

On Thu, Mar 23, 2023 at 04:10:22PM +0800, Kewen.Lin wrote:
> Hi Mike,
> 
> Thanks for fixing this, some minor comments are inlined below.
> 
> on 2023/3/22 07:53, Michael Meissner wrote:
> > The issue with the bug is the power10 load GPR + cmpi -1/0/1 fusion
> > optimization generates illegal assembler code.
> > 
> > Ultimately the code was dying because the fusion load + compare -1/0/1 
> > patterns
> > did not handle the possibility that the load might be prefixed.
> > 
> > The main cause is the constraints for the individual loads in the fusion 
> > did not
> > match the machine.  In particular, LWA is a ds format instruction when it is
> > unprefixed.  The code did not also set the prefixed attribute correctly.
> > 
> > This patch rewrites the genfusion.pl script so that it will have more 
> > accurate
> > constraints for the LWA and LD instructions (which are DS instructions).  
> > The
> > updated genfusion.pl was then run to update fusion.md.  Finally, the code 
> > for
> > the "prefixed" attribute is modified so that it considers load + compare
> > immediate patterns to be like the normal load insns in checking whether
> > operand[1] is a prefixed instruction.
> > 
> > I have tested this patch on a little endian power10 system, on a little 
> > endian
> > power9 system, and a big endian power8 system (both -m32 and -m64 tested on
> > BE).  There were no regressions, can I check this into the trunk?
> > 
> > The same patch applies to the gcc-12 and gcc-11 branches.  Can I check this
> > patch into those branches also after a burn-in period?
> > 
> > 2023-03-21   Michael Meissner  
> >  Aaron Sawdey  
> > 
> > gcc/
> > 
> > PR target/105325
> > * gcc/config/rs6000/genfusion.pl (gen_ld_cmpi_p10): Improve generation
> > of the ld and lwa instructions which use the DS encoding instead of D.
> > Use the YZ constraint for these loads.  Handle prefixed loads better.
> > Set the sign_extend attribute as appropriate.
> > * gcc/config/rs6000/fusion.md: Regenerate.
> > * gcc/config/rs6000/rs6000.md (prefixed attribute): Add fused_load_cmpi
> > instructions to the list of instructions that might have a prefixed load
> > instruction.
> > 
> > gcc/testsuite/
> > 
> > PR target/105325
> > * g++.target/powerpc/pr105325.C: New test.
> > * gcc.target/powerpc/fusion-p10-ldcmpi.c: Adjust insn counts.
> > ---
> >  gcc/config/rs6000/genfusion.pl| 26 ---
> >  gcc/config/rs6000/fusion.md   | 17 +++-
> >  gcc/config/rs6000/rs6000.md   |  2 +-
> >  gcc/testsuite/g++.target/powerpc/pr105325.C   | 24 +
> >  .../gcc.target/powerpc/fusion-p10-ldcmpi.c|  4 +--
> >  5 files changed, 59 insertions(+), 14 deletions(-)
> >  create mode 100644 gcc/testsuite/g++.target/powerpc/pr105325.C
> > 
> > diff --git a/gcc/config/rs6000/genfusion.pl b/gcc/config/rs6000/genfusion.pl
> > index e4db352e0ce..4f367cadc52 100755
> > --- a/gcc/config/rs6000/genfusion.pl
> > +++ b/gcc/config/rs6000/genfusion.pl
> > @@ -56,7 +56,7 @@ sub mode_to_ldst_char
> >  sub gen_ld_cmpi_p10
> >  {
> >  my ($lmode, $ldst, $clobbermode, $result, $cmpl, $echr, $constpred,
> > -   $mempred, $ccmode, $np, $extend, $resultmode);
> > +   $mempred, $ccmode, $np, $extend, $resultmode, $constraint);
> >LMODE: foreach $lmode ('DI','SI','HI','QI') {
> >$ldst = mode_to_ldst_char($lmode);
> >$clobbermode = $lmode;
> > @@ -71,21 +71,34 @@ sub gen_ld_cmpi_p10
> >CCMODE: foreach $ccmode ('CC','CCUNS') {
> >   $np = "NON_PREFIXED_D";
> >   $mempred = "non_update_memory_operand";
> > + $constraint = "m";
> 
> The three assignments on $np $mempred $constraint can be moved
> to place (a) (see below) and add one explicit assignment for
> $constraint at place (b), since for the condition ccmode eq 'CC',
> HI/SI/DI have their own settings (btw QI is skipped), these
> assignments for default value can be moved to else arm (for CCUNS).

...

> we have broken it into two different arms for SI and DI, this
> comment can be removed?

...

> 
> ... and this comment.
> 

I have fixed these issues and reposted the patch as:

| Date: Fri, 24 Mar 2023 19:06:35 -0400
| From: Michael Meissner 
| Subject: [PATCH, V2] PR target/105325, Make load/cmp fusion know about 
prefixed load
| Message-ID: 

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

Re: Building gcc-12 on MacOS Ventura (aarch64)

[Jonathan Wakely via Gcc]

On Fri, 24 Mar 2023, 23:07 Jonathan Wakely,  wrote:

>
>
> On Fri, 24 Mar 2023, 23:03 Chris Johns,  wrote:
>
>> Hi,
>>
>> I am sorting out some issues building RTEMS on MacOS including the M
>> processors.
>> The building gcc-12.2.1 for the few architectures I tested fail with sig
>> faults
>> in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a
>> result I
>> wondered about bootstrapping gcc and using that to build the tools rather
>> than
>> clang from Xcode.
>>
>> Is aarch64-apple-darwin supported?
>
>
>
> No. Iain Sandoe has some personal branches with changes to support it, but
> the changes are not in the official gcc repo yet. If you search the
> gcc-h...@gcc.gnu.org list you'll find links to his code. I think Homebrew
> is his patches too.
>

*uses his patches too.


>
> I am seeing:
>>
>> *** Configuration aarch64-apple-darwin22.3.0 not supported
>>
>> Thanks
>> Chris
>>
>

Re: Building gcc-12 on MacOS Ventura (aarch64)

[Jonathan Wakely via Gcc]

On Fri, 24 Mar 2023, 23:03 Chris Johns,  wrote:

> Hi,
>
> I am sorting out some issues building RTEMS on MacOS including the M
> processors.
> The building gcc-12.2.1 for the few architectures I tested fail with sig
> faults
> in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a
> result I
> wondered about bootstrapping gcc and using that to build the tools rather
> than
> clang from Xcode.
>
> Is aarch64-apple-darwin supported?



No. Iain Sandoe has some personal branches with changes to support it, but
the changes are not in the official gcc repo yet. If you search the
gcc-h...@gcc.gnu.org list you'll find links to his code. I think Homebrew
is his patches too.


I am seeing:
>
> *** Configuration aarch64-apple-darwin22.3.0 not supported
>
> Thanks
> Chris
>

[PATCH, V2] PR target/105325, Make load/cmp fusion know about prefixed load

[Michael Meissner via Gcc-patches]

I posted a version of patch on March 21st.  This patch makes some code changes
suggested in the genfusion.pl code.  The only change is in genfusion.pl.  The
fusion.md that it makes is the same.

The issue with the bug is the power10 load GPR + cmpi -1/0/1 fusion
optimization generates illegal assembler code.

Ultimately the code was dying because the fusion load + compare -1/0/1 patterns
did not handle the possibility that the load might be prefixed.

The main cause is the constraints for the individual loads in the fusion did not
match the machine.  In particular, LWA is a ds format instruction when it is
unprefixed.  The code did not also set the prefixed attribute correctly.

This patch rewrites the genfusion.pl script so that it will have more accurate
constraints for the LWA and LD instructions (which are DS instructions).  The
updated genfusion.pl was then run to update fusion.md.  Finally, the code for
the "prefixed" attribute is modified so that it considers load + compare
immediate patterns to be like the normal load insns in checking whether
operand[1] is a prefixed instruction.

I am re-running the tests right now, but they should have the same results
since fsuion.md is the same, and only code in genfusion.pl that makes fusion.md
was modified.  Assuming these runs pass can I check this into the master
branch?

I will also need to check these same patches into GCC 11 and GCC 12 after a
waiting period (the patch applied to those branches as well).

2023-03-21   Michael Meissner  

gcc/

PR target/105325
* gcc/config/rs6000/genfusion.pl (gen_ld_cmpi_p10): Improve generation
of the ld and lwa instructions which use the DS encoding instead of D.
Use the YZ constraint for these loads.  Handle prefixed loads better.
Set the sign_extend attribute as appropriate.
* gcc/config/rs6000/fusion.md: Regenerate.
* gcc/config/rs6000/rs6000.md (prefixed attribute): Add fused_load_cmpi
instructions to the list of instructions that might have a prefixed load
instruction.

gcc/testsuite/

PR target/105325
* g++.target/powerpc/pr105325.C: New test.
* gcc.target/powerpc/fusion-p10-ldcmpi.c: Adjust insn counts.
---
 gcc/config/rs6000/fusion.md   | 17 ++
 gcc/config/rs6000/genfusion.pl| 32 +++
 gcc/config/rs6000/rs6000.md   |  2 +-
 gcc/testsuite/g++.target/powerpc/pr105325.C   | 24 ++
 .../gcc.target/powerpc/fusion-p10-ldcmpi.c|  4 +--
 5 files changed, 62 insertions(+), 17 deletions(-)
 create mode 100644 gcc/testsuite/g++.target/powerpc/pr105325.C

diff --git a/gcc/config/rs6000/fusion.md b/gcc/config/rs6000/fusion.md
index d45fb138a70..da9953d9ad9 100644
--- a/gcc/config/rs6000/fusion.md
+++ b/gcc/config/rs6000/fusion.md
@@ -22,7 +22,7 @@
 ;; load mode is DI result mode is clobber compare mode is CC extend is none
 (define_insn_and_split "*ld_cmpdi_cr0_DI_clobber_CC_none"
   [(set (match_operand:CC 2 "cc_reg_operand" "=x")
-(compare:CC (match_operand:DI 1 "ds_form_mem_operand" "m")
+(compare:CC (match_operand:DI 1 "ds_form_mem_operand" "YZ")
 (match_operand:DI 3 "const_m1_to_1_operand" "n")))
(clobber (match_scratch:DI 0 "=r"))]
   "(TARGET_P10_FUSION)"
@@ -43,7 +43,7 @@ (define_insn_and_split "*ld_cmpdi_cr0_DI_clobber_CC_none"
 ;; load mode is DI result mode is clobber compare mode is CCUNS extend is none
 (define_insn_and_split "*ld_cmpldi_cr0_DI_clobber_CCUNS_none"
   [(set (match_operand:CCUNS 2 "cc_reg_operand" "=x")
-(compare:CCUNS (match_operand:DI 1 "ds_form_mem_operand" "m")
+(compare:CCUNS (match_operand:DI 1 "ds_form_mem_operand" "YZ")
(match_operand:DI 3 "const_0_to_1_operand" "n")))
(clobber (match_scratch:DI 0 "=r"))]
   "(TARGET_P10_FUSION)"
@@ -64,7 +64,7 @@ (define_insn_and_split "*ld_cmpldi_cr0_DI_clobber_CCUNS_none"
 ;; load mode is DI result mode is DI compare mode is CC extend is none
 (define_insn_and_split "*ld_cmpdi_cr0_DI_DI_CC_none"
   [(set (match_operand:CC 2 "cc_reg_operand" "=x")
-(compare:CC (match_operand:DI 1 "ds_form_mem_operand" "m")
+(compare:CC (match_operand:DI 1 "ds_form_mem_operand" "YZ")
 (match_operand:DI 3 "const_m1_to_1_operand" "n")))
(set (match_operand:DI 0 "gpc_reg_operand" "=r") (match_dup 1))]
   "(TARGET_P10_FUSION)"
@@ -85,7 +85,7 @@ (define_insn_and_split "*ld_cmpdi_cr0_DI_DI_CC_none"
 ;; load mode is DI result mode is DI compare mode is CCUNS extend is none
 (define_insn_and_split "*ld_cmpldi_cr0_DI_DI_CCUNS_none"
   [(set (match_operand:CCUNS 2 "cc_reg_operand" "=x")
-(compare:CCUNS (match_operand:DI 1 "ds_form_mem_operand" "m")
+(compare:CCUNS (match_operand:DI 1 "ds_form_mem_operand" "YZ")
(match_operand:DI 3 "const_0_to_1_operand" "n")))
(set (match_operand:DI 0 "gpc_reg_operand" "=r") (match_dup 1))]
   

Building gcc-12 on MacOS Ventura (aarch64)

[Chris Johns]

Hi,

I am sorting out some issues building RTEMS on MacOS including the M processors.
The building gcc-12.2.1 for the few architectures I tested fail with sig faults
in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a result I
wondered about bootstrapping gcc and using that to build the tools rather than
clang from Xcode.

Is aarch64-apple-darwin supported? I am seeing:

*** Configuration aarch64-apple-darwin22.3.0 not supported

Thanks
Chris

[Bug c/109280] Very significant increase in code size (gcc-avr)

[dirkx-gcc-2001 at webweaving dot org via Gcc-bugs]

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

Dirk-Willem van Gulik  changed:

   What|Removed |Added

 Target||air
 CC||dirkx-gcc-2001 at webweaving 
dot o
   ||rg

--- Comment #1 from Dirk-Willem van Gulik  ---
Tried and tested code (https://github.com/gnea/grbl) grows from 28k to about
36k (so a 1/3 change) when going gcc version 7.3.0 (GCC) to gcc version 12.2.0
(GCC) for GCC-AVR. 

Size increase is across the board according to avr-nm -l --size-sort ; with
pretty much sensible flags provided:

avr-gcc -Wall -Os -mcall-prologues  -fdata-sections -ffunction-sections
-flto

gcc-11-20230324 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20230324 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20230324/
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 2055702e8d492be6e978fa93a7bfefd358d5d9e3

You'll find:

 gcc-11-20230324.tar.xz   Complete GCC

  SHA256=1a4fb184a8257e2d414e4646768b0133bc6a6e76185e38822b42b4f4dc30bad6
  SHA1=c045085ab914199e56f6218fd4ae7abb7135bad6

Diffs from 11-20230317 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 c/109280] New: Very significant increase in code size (gcc-avr)

[dirkx-gcc-2001 at webweaving dot org via Gcc-bugs]

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

Bug ID: 109280
   Summary: Very significant increase in code size (gcc-avr)
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dirkx-gcc-2001 at webweaving dot org
  Target Milestone: ---

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

--- Comment #8 from Andrew Pinski  ---
oh right this is because can_create_pseudo is false 

This code is just so broken ...

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

--- Comment #7 from Andrew Pinski  ---
riscv_split_integer does something similarlly to what I was suggesting but for
some reason it is not kicking in for this case ...

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-24
 Status|UNCONFIRMED |NEW
Summary|[13 Regression] RISC-V: |RISC-V: complex constants
   |complex constants   |synthesized should be
   |synthesized vs. fetching|improved
   |from constant pool  |
 Ever confirmed|0   |1

--- Comment #6 from Andrew Pinski  ---
Take:
long long f(void)
{
  return 0x0101010101010101ull;
}

 CUT 
This should be done as:
li  a0,16842752
addia0,a0,257
sllia1,a0,32
or  a0,a0,a1
Which is what this produces:
```
long long f(void)
{
  unsigned t = 16843009;
  long long t1 = t;
  long long t2 = ((unsigned long long )t) << 32;
  asm("":"+r"(t1));
  return t1 | t2;
}
```
I suspect: 0x0080402010080400ULL should be done as two 32bit with a shift/or
added too. Will definitely improve complex constants forming too.

Right now the backend does (const<<16+const)<<16+const... which is just so bad.

Re: [PATCH RFC] c-family: -Wsequence-point and COMPONENT_REF [PR107163]

[Jakub Jelinek via Gcc-patches]

On Fri, Mar 24, 2023 at 06:11:44PM -0400, Jason Merrill wrote:
> > When we touch this for COMPONENT_REF, shouldn't we then handle it as
> > unary given that the second operand is FIELD_DECL and third/fourth
> > will likely be NULL and even if not, aren't user expressions that should be
> > inspected?
> > So, instead of doing this do:
> >  case COMPONENT_REF:
> >x = TREE_OPERAND (x, 0);
> >writer = 0;
> >goto restart;
> > ?
> 
> Is clearing 'writer' what we want, since an access to COMPONENT_REF is an
> access to (a subobject of) its op0?

I've just mindlessly copied the unary op case.
writer is set for pre/post increments and lhs of MODIFY_EXPR, and it is
true that VIEW_CONVERT_EXPR doesn't clear it, but e.g. ARRAY_REF clears it
for all operands.

> Currently with the fix it takes <1s while gcc12 takes ~80s.

Perfect.

>   PR c++/107163
> 
> gcc/c-family/ChangeLog:
> 
>   * c-common.cc (verify_tree): Don't use sequenced handling
>   for COMPONENT_REF.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/template/recurse5.C: New test.

LGTM, thanks.  Maybe the testcase would be better as
warn/Wsequence-point-5.C, dunno.

Jakub

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Vineet Gupta from comment #4)
> But this is not so much about code bloat, we see 3.5% additional dynamic
> icount on qemu which will affect perf even if we didn't care about code size
> at all.

Again dynamic icount increase does not always equals worse performance;
especially when it comes to loading from memory. It is a much more complex
equation depending on the cache and such.
Now we should be able to form these constants better in the first place too.

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #4 from Vineet Gupta  ---
(In reply to Andrew Pinski from comment #2)
> If this was about -Os, then I would say yes this is a big code bloat but
> this is about -O2.

But this is not so much about code bloat, we see 3.5% additional dynamic icount
on qemu which will affect perf even if we didn't care about code size at all.

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #3 from Vineet Gupta  ---
We start off with following:

  (insn 18 17 19 2 (set (reg:DI 154)
 (mem/u/c:DI (reg/f:DI 155) [0  S8 A64])) "...":9:8 179 {*movdi_64bit}
 (expr_list:REG_DEAD (reg/f:DI 155)
(expr_list:REG_EQUAL (const_int [0x101010101010101])

cse1 matches the new pattern and converts mem to const_int.

   (insn 18 17 19 2 (set (reg:DI 154)
(const_int [0x101010101010101])) "...":9:8 177 {*mvconst_internal}
 (expr_list:REG_DEAD (reg/f:DI 155)
(expr_list:REG_EQUAL (const_int [0x101010101010101])

split1 then does its job, again using the introduced define_insn_and_split
"*mvconst_internal"

Splitting with gen_split_15 (riscv.md:1677)
deleting insn with uid = 18.

   (insn 47 15 48 2 (set (reg:DI 154)
(const_int 16842752 [0x101])) "...":9:8 -1

   (insn 48 47 49 2 (set (reg:DI 154)
(plus:DI (reg:DI 154)
(const_int 257 [0x101]))) "...":9:8 -1

   (insn 49 48 50 2 (set (reg:DI 154)
(ashift:DI (reg:DI 154)
(const_int 16 [0x10]))) "...":9:8 -1

   (insn 50 49 51 2 (set (reg:DI 154)
(plus:DI (reg:DI 154)
(const_int 257 [0x101]))) "...":9:8 -1

   (insn 51 50 52 2 (set (reg:DI 154)
(ashift:DI (reg:DI 154)
(const_int 16 [0x10]))) "...":9:8 -1

   (insn 52 51 19 2 (set (reg:DI 154)
(plus:DI (reg:DI 154)
(const_int 257 [0x101]))) "...":9:8 -1
 (expr_list:REG_EQUAL (const_int [0x101010101010101])

Re: [PATCH RFC] c-family: -Wsequence-point and COMPONENT_REF [PR107163]

[Jason Merrill via Gcc-patches]

On 3/23/23 17:03, Jakub Jelinek wrote:

On Thu, Mar 23, 2023 at 04:35:07PM -0400, Jason Merrill wrote:

Tested x86_64-pc-linux-gnu.  Jakub, does this make sense to you?  Do we have a
way of testing for compile-hog regressions?

-- 8< --

The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF
as sequenced in C++17, and COMPONENT_REF as well.  But this is unnecessary
for COMPONENT_REF, since the RHS is just a FIELD_DECL with no actual
evaluation, and in this testcase handling COMPONENT_REF as sequenced blows
up fast in a deep inheritance tree.

PR c++/107163

gcc/c-family/ChangeLog:

* c-common.cc (verify_tree): Don't use sequenced handling
for COMPONENT_REF.


When we touch this for COMPONENT_REF, shouldn't we then handle it as
unary given that the second operand is FIELD_DECL and third/fourth
will likely be NULL and even if not, aren't user expressions that should be
inspected?
So, instead of doing this do:
 case COMPONENT_REF:
   x = TREE_OPERAND (x, 0);
   writer = 0;
   goto restart;
?


Is clearing 'writer' what we want, since an access to COMPONENT_REF is 
an access to (a subobject of) its op0?



As for compile-hog, depends on how long it will take it to compile before
fix/after fix.  If before fix can be above the normal timeout on reasonably
fast matchines and after fix can take a few seconds, great


Currently with the fix it takes <1s while gcc12 takes ~80s.


if after fix
would take longer but still not horribly long, one way to do it is
guard the test with run_expensive_tests effective target.  Or another way
is have the test smaller in complexity normally and
// { dg-additional-options "-DEXPENSIVE" { target run_expensive_tests } }
and #ifdef EXPENSIVE make it more complex.


Curiously, making the recursion much deeper doesn't work for that; I 
guess at some point the -Wsequence-point code decides the expression is 
too complex and gives up?


But repeating the assignment brings it up over the timeout.

How about this?From bb302f97929df9b854f7f929093441da60305254 Mon Sep 17 00:00:00 2001
From: Jason Merrill 
Date: Thu, 23 Mar 2023 15:57:39 -0400
Subject: [PATCH] c-family: -Wsequence-point and COMPONENT_REF [PR107163]
To: gcc-patches@gcc.gnu.org

The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF
as sequenced in C++17, and COMPONENT_REF as well.  But this is unnecessary
for COMPONENT_REF, since the RHS is just a FIELD_DECL with no actual
evaluation, and in this testcase handling COMPONENT_REF as sequenced blows
up fast in a deep inheritance tree.  Instead, look through it.

	PR c++/107163

gcc/c-family/ChangeLog:

	* c-common.cc (verify_tree): Don't use sequenced handling
	for COMPONENT_REF.

gcc/testsuite/ChangeLog:

	* g++.dg/template/recurse5.C: New test.
---
 gcc/c-family/c-common.cc |  5 +++-
 gcc/testsuite/g++.dg/template/recurse5.C | 37 
 2 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/template/recurse5.C

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index bfb950e56db..07f7beac8fd 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -2154,12 +2154,15 @@ verify_tree (tree x, struct tlist **pbefore_sp, struct tlist **pno_sp,
 
 case LSHIFT_EXPR:
 case RSHIFT_EXPR:
-case COMPONENT_REF:
 case ARRAY_REF:
   if (cxx_dialect >= cxx17)
 	goto sequenced_binary;
   goto do_default;
 
+case COMPONENT_REF:
+  x = TREE_OPERAND (x, 0);
+  goto restart;
+
 default:
 do_default:
   /* For other expressions, simply recurse on their operands.
diff --git a/gcc/testsuite/g++.dg/template/recurse5.C b/gcc/testsuite/g++.dg/template/recurse5.C
new file mode 100644
index 000..0354ab09f53
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/recurse5.C
@@ -0,0 +1,37 @@
+// PR c++/107163
+// { dg-additional-options "-Wsequence-point" }
+
+struct BaseType  {
+  int i;
+};
+
+template< int Seq >
+class DerivedType : public DerivedType< Seq - 1 > { };
+
+template<>
+class DerivedType< -1 > : public BaseType { };
+
+int main() {
+  DerivedType< 400 > d;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  d.i = 42;
+  return d.i;
+}
-- 
2.31.1

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

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

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

--- Comment #2 from Andrew Pinski  ---
If this was about -Os, then I would say yes this is a big code bloat but this
is about -O2.

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

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

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

--- Comment #1 from Andrew Pinski  ---
Note I think this really depends on the micro-arch if loading from memory is
faster than doing instructions for constant forming.

[Bug target/109279] New: [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Bug ID: 109279
   Summary: [13 Regression] RISC-V: complex constants synthesized
vs. fetching from constant pool
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineet.gupta at linux dot dev
  Target Milestone: ---

This is code bloat regression since gcc 12.1, seen yet again in SPEC2017
deepsjeng. After 2e886eef7f2b5a ("RISC-V: Produce better code with complex
constants [PR95632] [PR106602]").

unsigned long long FileAttacks(unsigned long long occ, const unsigned int sq) {
unsigned int o;
unsigned int f = sq & 7;

occ   =   0x0101010101010101ULL & (occ   >> f);
o = ( 0x0080402010080400ULL *  occ ) >> 58;
return  ( aFileAttacks[o][sq>>3]) << f;
}

cc1 -O2 -march=rv64gc_zba_zbb_zbc_zbs -mabi=lp64d   # stage1 is enough

Before above commit
---
lui a4,%hi(.LC0)
ld  a4,%lo(.LC0)(a4)
andia3,a1,7
srl a5,a0,a3
and a5,a5,a4
lui a4,%hi(.LC1)
ld  a4,%lo(.LC1)(a4)
srliw   a1,a1,3
mul a5,a5,a4
lui a4,%hi(aFileAttacks)
addia4,a4,%lo(aFileAttacks)
srlia5,a5,58
sh3add  a5,a5,a1
sh3add  a5,a5,a4
ld  a0,0(a5)
sll a0,a0,a3
ret

.section.srodata.cst8,"aM",@progbits,8
.align  3
.LC0:
.dword  0x0101010101010101
.align  3
.LC1:
.dword  0x0080402010080400


With commit
---

   li  a5,16842752
addia5,a5,257
sllia5,a5,16
addia5,a5,257
andia3,a1,7
sllia5,a5,16
srl a4,a0,a3
addia5,a5,257
and a4,a4,a5
sllia5,a4,9
add a5,a5,a4
sllia5,a5,9
add a5,a5,a4
sllia4,a5,27
add a5,a5,a4
srlia5,a5,45
srliw   a1,a1,3
andia5,a5,504
lui a4,%hi(aFileAttacks)
add a5,a5,a1
addia4,a4,%lo(aFileAttacks)
sh3add  a5,a5,a4
ld  a0,0(a5)
sll a0,a0,a3
ret

[Bug middle-end/109258] [13 Regression] go.test/test/fixedbugs/bug207.go ICEs

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

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

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

https://gcc.gnu.org/g:0849a188d539d78101a32deea63db4cb39fb55ac

commit r13-6858-g0849a188d539d78101a32deea63db4cb39fb55ac
Author: Jakub Jelinek 
Date:   Fri Mar 24 23:02:08 2023 +0100

go: Fix up go.test/test/fixedbugs/bug207.go failure [PR109258]

The PR109086 r13-6690 inline_string_cmp change to
  if (diff != result)
emit_move_insn (result, diff);
regressed
FAIL: go.test/test/fixedbugs/bug207.go,  -O2 -g  (internal compiler error:
in emit_move_insn, at expr.cc:4224)
The problem is the Go FE doesn't mark __builtin_memcmp as pure as other
FEs,
so we ended up with
  __builtin_memcmp (whatever, whateverelse, somesize);
in the IL before expansion and the expansion ICEd on it.
As the builtin calls a library function which is pure or is inline expanded
as such, not marking it pure is an unnecessary pessimization from the FE
side, keeping such dead calls in the IL if they aren't needed will not help
anything.

The following patch fixes that.  Initially I've added just DECL_PURE_P to
it, but that unfortunately broke bootstrap, for __builtin_memcmp there is
also __builtin_memcmp_eq registered by the middle-end code if not
registered
earlier and that one is registered with the usual flags (pure, nothrow,
leaf), so if __builtin_memcmp from FE was just pure, it would appear in the
IL as that it can raise exceptions and when folded into __builtin_memcmp_eq
all of sudden it couldn't and we'd ICE in verification.

I think tons of functions should have builtin_nothrow as well, but changing
that wasn't necessary for this fix.

2023-03-24  Jakub Jelinek  

PR middle-end/109258
* go-gcc.cc (Gcc_backend): Add new static data members builtin_pure
and builtin_nothrow.
(Gcc_backend::Gcc_backend): Pass builtin_pure | builtin_nothrow for
BUILT_IN_MEMCMP.
(Gcc_backend::define_builtin): Handle builtin_pure and
builtin_nothrow
in flags.

[PATCH] aarch64, builtins: Include PR registers in FUNCTION_ARG_REGNO_P etc. [PR109254]

[Jakub Jelinek via Gcc-patches]

Hi!

The testcase in the PR (which unfortunately because of my lack of experience
with SVE I'm not able to turn into a runtime testcase that verifies it)
is miscompiled on aarch64-linux in the regname pass, because while the
function takes arguments in the p0 register, FUNCTION_ARG_REGNO_P doesn't
reflect that, so DF doesn't know the register is used in register passing.
It sees 2 chains with p1 register and wants to replace the second one and
as DF doesn't know p0 is live at the start of the function, it will happily
use p0 register even when it is used in subsequent instructions.

The following patch fixes that.  FUNCTION_ARG_REGNO_P returns non-zero
for p0-p3 (unconditionally, seems for the floating/vector registers it
doesn't conditionalize them on TARGET_FLOAT either, but if you want,
I can conditionalize p0-p3 on TARGET_SVE), similarly
targetm.calls.function_value_regno_p returns true for p0 register
if TARGET_SVE (again for consistency, that function conditionalizes
the float/vector on TARGET_FLOAT); looking at the AAPCS, seems p1-p3
could be also used to return values in case of homogenous aggregates,
but it doesn't seem GCC supports putting svbool_t as a member of a
structure.

Now, that change broke bootstrap in libobjc and some
__builtin_apply_args/__builtin_apply/__builtin_return tests.  The
aarch64_get_reg_raw_mode hook already documents that SVE scalable arg/return
passing is fundamentally incompatible with those builtins, but unlike
the floating/vector regs where it forces a fixed vector mode, I think
there is no fixed mode which could be used for p0-p3.  So, I have tweaked
the generic code so that it uses VOIDmode return from that hook to signal
that a register shouldn't be touched by
__builtin_apply_args/__builtin_apply/__builtin_return
despite being mentioned in FUNCTION_ARG_REGNO_P or
targetm.calls.function_value_regno_p.

Bootstrapped/regtested on aarch64-linux, ok for trunk?

Could somebody please turn the testcase from the PR into something that
can be included into the testsuite?

2023-03-24  Jakub Jelinek  

PR target/109254
* builtins.cc (apply_args_size): If targetm.calls.get_raw_arg_mode
returns VOIDmode, handle it like if the register isn't used for
passing arguments at all.
(apply_result_size): If targetm.calls.get_raw_result_mode returns
VOIDmode, handle it like if the register isn't used for returning
results at all.
* target.def (get_raw_result_mode, get_raw_arg_mode): Document what it
means to return VOIDmode.
* doc/tm.texi: Regenerated.
* config/aarch64/aarch64.cc (aarch64_function_value_regno_p): Return
TARGET_SVE for P0_REGNUM.
(aarch64_function_arg_regno_p): Also return true for p0-p3.
(aarch64_get_reg_raw_mode): Return VOIDmode for PR_REGNUM_P regs.

--- gcc/builtins.cc.jj  2023-03-24 10:38:40.185097837 +0100
+++ gcc/builtins.cc 2023-03-24 11:06:49.781725290 +0100
@@ -1446,18 +1446,19 @@ apply_args_size (void)
  {
fixed_size_mode mode = targetm.calls.get_raw_arg_mode (regno);
 
-   gcc_assert (mode != VOIDmode);
-
-   align = GET_MODE_ALIGNMENT (mode) / BITS_PER_UNIT;
-   if (size % align != 0)
- size = CEIL (size, align) * align;
-   size += GET_MODE_SIZE (mode);
-   apply_args_mode[regno] = mode;
+   if (mode != VOIDmode)
+ {
+   align = GET_MODE_ALIGNMENT (mode) / BITS_PER_UNIT;
+   if (size % align != 0)
+ size = CEIL (size, align) * align;
+   size += GET_MODE_SIZE (mode);
+   apply_args_mode[regno] = mode;
+ }
+   else
+ apply_args_mode[regno] = as_a  (VOIDmode);
  }
else
- {
-   apply_args_mode[regno] = as_a  (VOIDmode);
- }
+ apply_args_mode[regno] = as_a  (VOIDmode);
 }
   return size;
 }
@@ -1481,13 +1482,16 @@ apply_result_size (void)
  {
fixed_size_mode mode = targetm.calls.get_raw_result_mode (regno);
 
-   gcc_assert (mode != VOIDmode);
-
-   align = GET_MODE_ALIGNMENT (mode) / BITS_PER_UNIT;
-   if (size % align != 0)
- size = CEIL (size, align) * align;
-   size += GET_MODE_SIZE (mode);
-   apply_result_mode[regno] = mode;
+   if (mode != VOIDmode)
+ {
+   align = GET_MODE_ALIGNMENT (mode) / BITS_PER_UNIT;
+   if (size % align != 0)
+ size = CEIL (size, align) * align;
+   size += GET_MODE_SIZE (mode);
+   apply_result_mode[regno] = mode;
+ }
+   else
+ apply_result_mode[regno] = as_a  (VOIDmode);
  }
else
  apply_result_mode[regno] = as_a  (VOIDmode);
--- gcc/target.def.jj   2023-03-23 10:00:58.722094571 +0100
+++ gcc/target.def  2023-03-24 11:12:46.978585647 +0100
@@ -5324,7 +5324,8 @@ 

[Bug c++/109278] a note without a warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-03-24
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

Untested fix.

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

[Peter Bergner via Gcc-patches]

On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
 Is there a reason why REE cannot see that our (reg:QI 4) is a param 
 register
 and thus due to our ABI, already correctly sign/zero extended?
>>>
>>> I don't think REE has ever considered exploiting ABI constraints. Handling
>>> that might be a notable improvement on various targets.  It'd be a great
>>> place to do some experimentation.
>>
>> Ok, so sounds like a good follow-on project after this patch is reviewed
>> and committed (stage1).  Thanks for your input!
>
> Agreed.  I suspect that risc-v will benefit from such work as well. 
> With that in mind, if y'all start poking at this, please loop in Raphael
> (on cc) who's expressed an interest in this space.

Will do.  I suspect that it'll be best to come up with some generic interface
using target hooks like "param regs are sign/zero extended" or "call return
values are sign/zero extended", etc. that targets can conditionally opt into
depending on their ABI that is in effect.

Peter

[Bug c++/109278] a note without a warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Keywords|needs-reduction |

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase:
void foo (long double);

void
bar (_Float128 x)
{
  foo (x);
}

[Bug fortran/107560] ICE in gfc_get_derived_type, at fortran/trans-types.cc:2811

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
The BOZ memleak should be fixed with r13-6857-g833233a4aefc99.

There is another FE memleak which is the same for z1.f90 and z2.f90:

==16805== 48 bytes in 1 blocks are definitely lost in loss record 19 of 674
==16805==at 0x4C39571: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16805==by 0x2120D94: xcalloc (xmalloc.c:164)
==16805==by 0x9AB967: gfc_match_actual_arglist(int, gfc_actual_arglist**,
bool) (primary.cc:1870)
==16805==by 0x9AFEA2: gfc_match_rvalue(gfc_expr**) (primary.cc:3695)
==16805==by 0x95F6A6: match_primary(gfc_expr**) (matchexp.cc:157)
==16805==by 0x95F7C3: match_level_1(gfc_expr**) (matchexp.cc:211)
==16805==by 0x95F885: match_mult_operand(gfc_expr**) (matchexp.cc:267)
==16805==by 0x95FA90: match_add_operand(gfc_expr**) (matchexp.cc:356)
==16805==by 0x95FD50: match_level_2(gfc_expr**) (matchexp.cc:480)
==16805==by 0x95FEE2: match_level_3(gfc_expr**) (matchexp.cc:551)
==16805==by 0x95FFE6: match_level_4(gfc_expr**) (matchexp.cc:599)
==16805==by 0x960279: match_and_operand(gfc_expr**) (matchexp.cc:693)

[PATCH, committed] Fortran: fix FE memleak with BOZ expressions

[Harald Anlauf via Gcc-patches]

Dear all,

while looking at variations of testcases in pr107560, I discovered
a minor FE memleak that was introduced in the BOZ rework and is
fixed by the attached simple patch.

Regtested on x86_64-pc-linux-gnu on OK'ed in the PR by Steve.

Thanks,
Harald

From 833233a4aefc9981b671c1bda34676c20b76cc90 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Fri, 24 Mar 2023 22:07:37 +0100
Subject: [PATCH] Fortran: fix FE memleak with BOZ expressions.

gcc/fortran/ChangeLog:

	* expr.cc (free_expr0): Free also BOZ strings as part of an expression.
---
 gcc/fortran/expr.cc | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 4662328bf31..7fb33f81788 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -466,6 +466,10 @@ free_expr0 (gfc_expr *e)
 	  mpc_clear (e->value.complex);
 	  break;

+	case BT_BOZ:
+	  free (e->boz.str);
+	  break;
+
 	default:
 	  break;
 	}
--
2.35.3

[Bug c++/85775] False positive with -Wparentheses

[markus-t314 at gmx dot de via Gcc-bugs]

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

--- Comment #3 from markus  ---
Worked until 7.5, fails since 8.1 and still fails in 12.2

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #8 from Jonathan Wakely  ---
Yes, looks undefined at first glance. We don't have to diagnose bad uses of
type traits (but we don't have to ignore them either, which means both gcc 12
and gcc 13 are correct).

The question is whether the trait instantiation is supposed to happen here, or
if it should be ok to name the incomplete type as long as its not used before
it's complete.

[Bug fortran/107560] ICE in gfc_get_derived_type, at fortran/trans-types.cc:2811

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Yep. It was missed by the guy that did the BOZ rework. ;-)

I think the BOZ rework was a greater step for mankind than the missing fix ...

> If it passed regtesting, it's ok to commit.

It did.  Will commit.

[Bug c++/85775] False positive with -Wparentheses

[markus-t314 at gmx dot de via Gcc-bugs]

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

markus  changed:

   What|Removed |Added

 CC||markus-t314 at gmx dot de

--- Comment #2 from markus  ---
Maybe a simpler example:

struct Foo {
int num;
};

struct S {
static Foo f;
};

// error: 'S' in 'struct Foo' does not name a type
//Foo ::S::f = Foo{23};

// warning: unnecessary parentheses in declaration of 'f' [-Wparentheses]
Foo (::S::f) = Foo{23};


Parantheses are necessary if global scope resolution is wanted/needed,
otherwise they would refer to the class Foo.

https://godbolt.org/z/7d39rbv7o

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #7 from Andrew Pinski  ---
Note I filed the note without a warning at PR 109278.

[Bug c++/109278] a note without a warning

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 54751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54751=edit
compressed preprocessed source

Semi reduced testcase, just removing what was afterwards rather than anything
else.

[Bug fortran/107560] ICE in gfc_get_derived_type, at fortran/trans-types.cc:2811

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-03-24
 CC||kargl at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> This used to fail, but appears to have been fixed in the meantime.
> A possible candidate for variant z2.f90 seems the fix for pr103413.
> 
> While looking at valgrind output with current trunk, I see a memleak
> for the BOZ case that is obviously plugged by:
> 
> diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
> index 4662328bf31..7fb33f81788 100644
> --- a/gcc/fortran/expr.cc
> +++ b/gcc/fortran/expr.cc
> @@ -466,6 +466,10 @@ free_expr0 (gfc_expr *e)
>   mpc_clear (e->value.complex);
>   break;
>  
> +   case BT_BOZ:
> + free (e->boz.str);
> + break;
> +
> default:
>   break;
> }
> 
> This might have been overseen during the BOZ rework.
> Regtesting ...

Yep. It was missed by the guy that did the BOZ rework. ;-)

If it passed regtesting, it's ok to commit.

[Bug c++/109278] a note without a warning

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

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

--- Comment #1 from Andrew Pinski  ---
Sorry the compressed source is still too big.

[Bug c++/109278] New: a note without a warning

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

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

Bug ID: 109278
   Summary: a note without a warning
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic, needs-reduction
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

the attached unreduced testcase when compiled with -w -std=c++20, gives:
t.cc: In static member function ‘static int
__iseqsig_type<_Float128>::__call(_Float128, _Float128)’:
t.cc:90092:36: note:   initializing argument 1 of ‘int __iseqsigl(long double,
long double)’
90092 | extern int __iseqsigl (long double __x, long double __y) noexcept
(true);
  |^~~
t.cc:90092:53: note:   initializing argument 2 of ‘int __iseqsigl(long double,
long double)’
90092 | extern int __iseqsigl (long double __x, long double __y) noexcept
(true);
  | ^~~


Which is wrong as the warnings are supressed but still providing the note.

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #6 from Andrew Pinski  ---
I know cppreference is not the standard but usually it has a good summary.

From: https://en.cppreference.com/w/cpp/types/is_convertible :
```
>From and To shall each be a complete type, (possibly cv-qualified) void, or an
array of unknown bound. Otherwise, the behavior is undefined.
```

So someone who understands the C++ standard better than me should be able to
answer if this is in fact illformed code.

[Bug fortran/107560] ICE in gfc_get_derived_type, at fortran/trans-types.cc:2811

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||11.3.1, 12.2.1, 13.0
 CC||anlauf at gcc dot gnu.org
  Known to fail||11.3.0, 12.2.0

--- Comment #1 from anlauf at gcc dot gnu.org ---
This used to fail, but appears to have been fixed in the meantime.
A possible candidate for variant z2.f90 seems the fix for pr103413.

While looking at valgrind output with current trunk, I see a memleak
for the BOZ case that is obviously plugged by:

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 4662328bf31..7fb33f81788 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -466,6 +466,10 @@ free_expr0 (gfc_expr *e)
  mpc_clear (e->value.complex);
  break;

+   case BT_BOZ:
+ free (e->boz.str);
+ break;
+
default:
  break;
}

This might have been overseen during the BOZ rework.
Regtesting ...

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #5 from Andrew Pinski  ---
Reduced testcase that shows the compiling difference between GCC 12 and 13:
```
#include 
struct a;
struct b{};
bool c = std::is_convertible::value;
```

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> The difference is is_convertible definition.
> 12:
>   template
> struct is_convertible
> : public __is_convertible_helper<_From, _To>::type
> { };
> 
> 
> 13:
>   template
> struct is_convertible
> : public __bool_constant<__is_convertible(_From, _To)>
> { };
> 
> So it might be a front-end issue after all.

and yes that is definitely the difference here. If I add back the
__is_convertible_helper and use that for is_convertible to the GCC 13
preprocessed source, the code then compiles.

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #3 from Andrew Pinski  ---
Though the code might be undefined ...

20.15.6/5 says:
```
The predicate condition for a template specialization is_convertible
shall be satisfied if and
only if the return expression in the following code would be well-formed,
including any implicit conversions
to the return type of the function:
To test() {
return declval();
}
[Note: This requirement gives well-defined results for reference types, void
types, array types, and function
types. — end note] Access checking is performed in a context unrelated to To
and From. Only the validity
of the immediate context of the expression of the return statement (8.7.3)
(including initialization of the
returned object or reference) is considered. [Note: The initialization can
result in side effects such as
the instantiation of class template specializations and function template
specializations, the generation of
implicitly-defined functions, and so on. Such side effects are not in the
“immediate context” and can result in
the program being ill-formed. — end note]

```
I am not 100% sure but I suspect this is just ill-formed code which was not
rejected before but is now using the builtin rather than the template form ...

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
   |a/show_bug.cgi?id=96592 |a/show_bug.cgi?id=107049
  Component|libstdc++   |c++

--- Comment #2 from Andrew Pinski  ---
The difference is is_convertible definition.
12:
  template
struct is_convertible
: public __is_convertible_helper<_From, _To>::type
{ };


13:
  template
struct is_convertible
: public __bool_constant<__is_convertible(_From, _To)>
{ };

So it might be a front-end issue after all.

[Bug libstdc++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #1 from Andrew Pinski  ---
The GCC 12 preprocessed source works (with a minor change of
s/__remove_cv/__remove_cv1/ ) so this is definitely due to a libstdc++ change.

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
   Target Milestone|--- |13.0
 Ever confirmed|1   |0

[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]

[jan.wassenberg at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Jan Wassenberg  ---
Thanks, I will be changing the code to add a nullptr check.

Re: Should -ffp-contract=off the default on GCC?

[Andrew Pinski via Gcc-patches]

On Fri, Mar 24, 2023 at 1:14 AM Fangrui Song via Gcc-patches
 wrote:
>
> On Wed, Mar 22, 2023 at 8:52 AM Qing Zhao via Gcc-patches
>  wrote:
> >
> >
> >
> > > On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches 
> > >  wrote:
> > >
> > > On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov  
> > > wrote:
> > >>
> > >>
> > >> On Wed, 22 Mar 2023, Richard Biener wrote:
> > >>
> > >>> I think it's even less realistic to expect users to know the details of
> > >>> floating-point math.  So I doubt any such sentence will be helpful
> > >>> besides spreading some FUD?
> > >>
> > >> I think it's closer to "fundamental notions" rather than "details". For
> > >> users who bother to read the GCC manual there's a decent chance it 
> > >> wouldn't
> > >> be for naught.
> > >>
> > >> For documentation, I was thinking
> > >>
> > >>  Together with -fexcess-precision=standard, -ffp-contract=off
> > >>  is necessary to ensure that rounding of intermediate results to 
> > >> precision
> > >>  implied by the source code and the FLT_EVAL_METHOD macro is not
> > >>  omitted by the compiler.
> > >
> > > that sounds good to me
> >
> > Shall we add such clarification to our Gcc13 doc? That should be helpful if 
> > we keep the currently default.
> >
> > Qing
> > >
> > >> Alexander
> >
>
> While updating the documentation, consider adding information that
> #pragma STDC FP_CONTRACT OFF is ignored with -ffp-contract=fast.
>
> This surprising behavior motivated Clang to add
> -Xclang=-ffp-contract=fast-honor-pragmas
> (https://discourse.llvm.org/t/fp-contract-fast-and-pragmas/58529).

`#pragma STDC FP_CONTRACT OFF` is not even implemented yet in GCC.
Rather we should document that :).
It does not matter what clang does here really since GCC does not even
implement the pragma.

Thanks,
Andrew Pinski


>
>
>
> --
> 宋方睿

[Bug fortran/109275] Bad error messages for interfaces describing surrounding program unit

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-03-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-03-24
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org

[Bug c++/109277] New: [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Bug ID: 109277
   Summary: [13 Regression] type_traits:1417:30: error: invalid
use of incomplete type ‘class v8::internal::WasmArray’
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---

Reduced from chromium, gcc-12 accepts the code:

GCC 13 pre-processed source code:
https://gist.githubusercontent.com/marxin/377cbc8221f7c36e87aebe48a55b52ba/raw/b80443940faf20f6f5db124fb6a56d9bee994fee/promise13.ii

$ g++ -std=gnu++20 promise13.ii -c -w
In file included from /usr/include/math.h:398,
 from /usr/include/c++/13/cmath:47,
 from ../v8/src/utils/utils.h:12,
 from ../v8/src/zone/zone.h:15,
 from ../v8/src/handles/handles.h:14,
 from ../v8/src/ast/ast-value-factory.h:36,
 from ../v8/src/ast/ast.h:10,
 from
gen/v8/torque-generated/src/builtins/promise-all-element-closure-tq-csa.cc:1:
/usr/include/bits/mathcalls-helper-functions.h: In static member function
‘static int __iseqsig_type<_Float128>::__call(_Float128, _Float128)’:
/usr/include/bits/mathcalls-helper-functions.h:41:36: note:   initializing
argument 1 of ‘int __iseqsigl(long double, long double)’
   41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y),
iseqsig);
  |^~~
/usr/include/bits/mathcalls-helper-functions.h:41:53: note:   initializing
argument 2 of ‘int __iseqsigl(long double, long double)’
   41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y),
iseqsig);
  | ^~~
In file included from /usr/include/c++/13/bits/move.h:57,
 from /usr/include/c++/13/bits/new_allocator.h:36,
 from
/usr/include/c++/13/aarch64-suse-linux/bits/c++allocator.h:33,
 from /usr/include/c++/13/bits/allocator.h:46,
 from /usr/include/c++/13/memory:65,
 from ../v8/src/ast/ast.h:8:
/usr/include/c++/13/type_traits: In instantiation of ‘struct
std::is_convertible’:
../v8/src/codegen/tnode.h:273:72:   required from ‘const bool
v8::internal::is_subtype::value’
../v8/src/codegen/tnode.h:361:75:   required by substitution of ‘template::value, int>::type  >
v8::internal::TNode::TNode(const
v8::internal::TNode&) [with U = v8::internal::WasmArray; typename
std::enable_if::value,
int>::type  = ]’
/usr/include/c++/13/tuple:188:12:   required from ‘struct std::_Head_base<0,
v8::internal::TNode, false>’
/usr/include/c++/13/tuple:259:12:   required from ‘struct std::_Tuple_impl<0,
v8::internal::TNode,
v8::internal::TNode,
v8::internal::TNode >’
/usr/include/c++/13/tuple:746:11:   required from ‘class
std::tuple,
v8::internal::TNode,
v8::internal::TNode >’
gen/v8/torque-generated/csa-types.h:487:80:   required from here
/usr/include/c++/13/type_traits:1417:30: error: invalid use of incomplete type
‘class v8::internal::WasmArray’
 1417 | : public __bool_constant<__is_convertible(_From, _To)>
  |  ^~~~
In file included from ../v8/src/heap/factory-base.h:15,
 from ../v8/src/heap/factory.h:18,
 from ../v8/src/ast/ast.h:18:
gen/v8/torque-generated/class-forward-declarations.h:291:7: note: forward
declaration of ‘class v8::internal::WasmArray’
In file included from ../v8/src/codegen/interface-descriptors.h:13,
 from ../v8/src/codegen/callable.h:8,
 from ../v8/src/codegen/code-factory.h:8,
 from ../v8/src/codegen/code-stub-assembler.h:12,
 from ../v8/src/builtins/builtins-array-gen.h:8,
 from
gen/v8/torque-generated/src/builtins/promise-all-element-closure-tq-csa.cc:2:
../v8/src/codegen/tnode.h: In instantiation of ‘const bool
v8::internal::is_subtype::value’:
../v8/src/codegen/tnode.h:361:75:   required by substitution of ‘template::value, int>::type  >
v8::internal::TNode::TNode(const
v8::internal::TNode&) [with U = v8::internal::WasmArray; typename
std::enable_if::value,
int>::type  = ]’
/usr/include/c++/13/tuple:188:12:   required from ‘struct std::_Head_base<0,
v8::internal::TNode, false>’
/usr/include/c++/13/tuple:259:12:   required from ‘struct std::_Tuple_impl<0,
v8::internal::TNode,
v8::internal::TNode,
v8::internal::TNode >’
/usr/include/c++/13/tuple:746:11:   required from ‘class
std::tuple,
v8::internal::TNode,
v8::internal::TNode >’
gen/v8/torque-generated/csa-types.h:487:80:   required from here
../v8/src/codegen/tnode.h:273:72: error: ‘value’ is not a member of
‘std::is_convertible’

GCC 12 pre-processed source 

[Bug c++/106969] [12 Regression] member function constness incorrectly propagates to local class member function return type deduction

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[12/13 Regression] member   |[12 Regression] member
   |function constness  |function constness
   |incorrectly propagates to   |incorrectly propagates to
   |local class member function |local class member function
   |return type deduction   |return type deduction

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 13 so far

[Bug c++/106969] [12/13 Regression] member function constness incorrectly propagates to local class member function return type deduction

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

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

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

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

commit r13-6856-gbbf2424c57c2e13d1a972c4ef4e871c3119b9cb4
Author: Patrick Palka 
Date:   Fri Mar 24 14:51:24 2023 -0400

c++: outer 'this' leaking into local class [PR106969]

Here when resolving the implicit object for '' within the
local class Foo, we expect to obtain a dummy object of type Foo& since
there's no 'this' available in this context.  And yet at this point
current_class_ref still corresponds to the outer class Context (and is
const), which confuses maybe_dummy_object into propagating the cv-quals
of current_class_ref and returning an object of type const Foo&.  Thus
decltype() wrongly yields const int* instead of int*.

The problem ultimately seems to be that the 'this' from the enclosing
class appears available for use when parsing the local class, but 'this'
shouldn't persist across classes like that.  This patch fixes this by
clearing current_class_ptr/ref before parsing a class definition.

After this change, for the test name-clash11.C in C++98 mode we would
now complain about an invalid use of 'this' in e.g.

  ASSERT (sizeof (this->A) == 16);

due to the way the test defines the ASSERT macro via a local class.
This patch redefines the macro using a local typedef instead.

PR c++/106969

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_specifier): Clear current_class_ptr
and current_class_ref sooner, before parsing a class definition.

gcc/testsuite/ChangeLog:

* g++.dg/lookup/name-clash11.C: Fix ASSERT macro definition in
C++98 mode.
* g++.dg/lookup/this2.C: New test.

[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]

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

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

--- Comment #6 from Andrew Pinski  ---
Reduced all the way removing all of the classes showing exactly what I thought
it was:
```
void *ao();
float *aq(long t) {
  if (t)
return nullptr;
  return static_cast(ao());
}
float v;
void at(long t) {
  long a = sizeof(0), i = 0;
  auto b = aq(t);
  for (; i < a; ++i)
b[i] = v;
  for (; i < t; ++i)
b[i] = 0.0f;
}
```

Notice how there is no check for null on aq.

[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #16 from anlauf at gcc dot gnu.org ---
Fixed on all affected branches.  Closing.

Thanks for the report!

[Bug fortran/32630] [meta-bug] ISO C binding

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
Bug 32630 depends on bug 85877, which changed state.

Bug 85877 Summary: [10/11/12/13 Regression] ICE in fold_convert_loc, at 
fold-const.c:2449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85877

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11265-gb9f6e7e234bab6ef8b5425c3e8b88bf8dfbc5089
Author: Harald Anlauf 
Date:   Sun Mar 19 21:29:46 2023 +0100

Fortran: simplification of NEAREST for large argument [PR109186]

gcc/fortran/ChangeLog:

PR fortran/109186
* simplify.c (gfc_simplify_nearest): Fix off-by-one error in
setting
up real kind-specific maximum exponent for mpfr.

gcc/testsuite/ChangeLog:

PR fortran/109186
* gfortran.dg/nearest_6.f90: New test.

(cherry picked from commit 4410a08b80cc40342eeaa5b6af824cd4352b218c)

[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11264-gdca8e28c990547648543175de9b6e05356f77e8a
Author: Harald Anlauf 
Date:   Fri Mar 17 22:24:49 2023 +0100

Fortran: procedures with BIND(C) attribute require explicit interface
[PR85877]

gcc/fortran/ChangeLog:

PR fortran/85877
* resolve.c (resolve_fl_procedure): Check for an explicit interface
of procedures with the BIND(C) attribute (F2018:15.4.2.2).

gcc/testsuite/ChangeLog:

PR fortran/85877
* gfortran.dg/pr85877.f90: New test.

(cherry picked from commit 5426ab34643d9e6502f3ee572891a03471fa33ed)

[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #14 from anlauf at gcc dot gnu.org ---
Fixed on all affected branches.  Closing.

Thanks for the report!

[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699

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

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

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

https://gcc.gnu.org/g:2055702e8d492be6e978fa93a7bfefd358d5d9e3

commit r11-10596-g2055702e8d492be6e978fa93a7bfefd358d5d9e3
Author: Harald Anlauf 
Date:   Tue Mar 21 19:58:31 2023 +0100

Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036]

gcc/fortran/ChangeLog:

PR fortran/99036
* decl.c (gfc_match_modproc): Reject MODULE PROCEDURE if not in a
generic module interface.

gcc/testsuite/ChangeLog:

PR fortran/99036
* gfortran.dg/pr99036.f90: New test.

(cherry picked from commit dd282b16bfd3c6e218dffb7798a375365b10ae22)

[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-10595-g4b722050fe8e7f06a3e653f290a39ccdc4d03174
Author: Harald Anlauf 
Date:   Sun Mar 19 21:29:46 2023 +0100

Fortran: simplification of NEAREST for large argument [PR109186]

gcc/fortran/ChangeLog:

PR fortran/109186
* simplify.c (gfc_simplify_nearest): Fix off-by-one error in
setting
up real kind-specific maximum exponent for mpfr.

gcc/testsuite/ChangeLog:

PR fortran/109186
* gfortran.dg/nearest_6.f90: New test.

(cherry picked from commit 4410a08b80cc40342eeaa5b6af824cd4352b218c)

[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:0257ba766443f11cf61c52db9b480337e44b48c8

commit r11-10594-g0257ba766443f11cf61c52db9b480337e44b48c8
Author: Harald Anlauf 
Date:   Fri Mar 17 22:24:49 2023 +0100

Fortran: procedures with BIND(C) attribute require explicit interface
[PR85877]

gcc/fortran/ChangeLog:

PR fortran/85877
* resolve.c (resolve_fl_procedure): Check for an explicit interface
of procedures with the BIND(C) attribute (F2018:15.4.2.2).

gcc/testsuite/ChangeLog:

PR fortran/85877
* gfortran.dg/pr85877.f90: New test.

(cherry picked from commit 5426ab34643d9e6502f3ee572891a03471fa33ed)

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

--- Comment #10 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #7)
> This started to ICE with r11-508-gdfa4fcdba374ed44 in the newly added pass
> there,
> and since r11-2259-g0a9d711df36b42b6494b73 it ICEs similarly like on the
> trunk.

The new pass should just stack alignment requirements when alignment of
stack variable is increased.

[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]

[malat at debian dot org via Gcc-bugs]

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

--- Comment #5 from Mathieu Malaterre  ---
c-reduce(d) ugly version:

% cat demo3.cc
struct d {
  using b = float &;
};
template  using c = d::b;
struct e {
  using b = c;
};
template  struct j;
template  using h = typename j::b;
template  struct p;
template  struct p<0, k, l...> { using b = k; };
template  class m;
template  struct aa {
  aa(n t) : o(t) {}
  static n ab(aa t) { return t.o; }
  n o;
};
template  struct q;
template 
struct q : q<1, s...>, aa {
  q(n t, s... ac) : q<1, s...>(ac...), aa(t) {}
};
template  struct q : aa {
  q(n t) : aa(t) {}
};
template  class m : public q<0, ad, ae> {
public:
  m(ad t, ae ac) : q<0, ad, ae>(t, ac) {}
};
template  struct j> {
  using b = typename p::b;
};
template  n ag(q t) {
  return q::ab(t);
}
template  h> ai(m t) { return ag(t);
}
class u {
  struct aj {
using b = float *;
  };

public:
  using ak = aj::b;
  u(ak t, int) : al(t, long()) {}
  ak w() { return ai<0>(al); }
  m al;
};
struct x : u {
  using u::u;
};
class y {
  x al;

public:
  using ak = u::ak;
  using am = int;
  template  y(an t, am ac) : al(t, ac) {}
  e::b operator[](long t) { return z()[t]; }
  ak z() { return al.w(); }
};
void *ao();
template  ap *aq(long t) {
  if (t)
return nullptr;
  return static_cast(ao());
}
template  using ar = y;
template  ar as(long t, void *) {
  return ar(aq(t), int());
}
template  ar as(long t) { return as(t, nullptr); }
float v;
void at(long t) {
  long a = sizeof(0), i = 0;
  auto b = as(t);
  for (; i < a; ++i)
b[i] = v;
  for (; i < t; ++i)
b[i] = 0.0f;
}

 % /usr/lib/gcc-snapshot/bin/g++ -Wall -O2 -o t.o -c demo3.cc
demo3.cc: In function 'void at(long int)':
demo3.cc:79:10: warning: 'void* __builtin_memset(void*, int, long unsigned
int)' writing 4 or more bytes into a region of size 0 overflows the destination
[-Wstringop-overflow=]
   79 | b[i] = 0.0f;
cc1plus: note: destination object is likely at address zero

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-03-24

--- Comment #9 from Andrew Pinski  ---
Confirmed.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

--- Comment #8 from Andrew Pinski  ---
A workaround is to do:
long long int digit __attribute__((aligned(8)));

Note manually setting the digit alignment to 4 does not cause an ICE for GCC
10.4 either.

Re: [PATCH v2] C, ObjC: Add -Wunterminated-string-initialization

[David Malcolm via Gcc-patches]

On Fri, 2023-03-24 at 18:45 +0100, Alejandro Colomar wrote:
> Hi David,
> 
> On 3/24/23 15:53, David Malcolm wrote:
> > On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-
> > patches
> > wrote:
> > > Warn about the following:
> > > 
> > >     char  s[3] = "foo";
> > > 
> [...]
> 
> > > ---
> > > 
> > > Hi,
> > 
> > Hi Alex, thanks for the patch.
> 
> :)
> 
> > 
> > > 
> > > I sent v1 to the wrong list.  This time I've made sure to write
> > > to
> > > gcc-patches@.
> > 
> > Note that right now we're deep in bug-fixing/stabilization for GCC
> > 13
> > (and trunk is still tracking that effort), so your patch might be
> > more
> > suitable for GCC 14.
> 
> Sure, no problem.  Do you have a "next" branch where you pick patches
> for after the release, or should I resend after the release?  

We don't; resending it after release is probably best.

> Is
> discussion of a patch reasonable now, or is it too much distracting
> from your stabilization efforts?

FWIW I'd prefer to postpone the discussion until after we branch for
the release.

> 
> > 
> > > 
> > > v2 adds some draft of a test, as suggested by Martin.  However, I
> > > don't
> > > know yet how to write those, so the test is just a draft.  But I
> > > did
> > > test the feature, by compiling GCC and compiling some small
> > > program
> > > with
> > > it.
> > 
> > Unfortunately the answer to the question "how do I run just one
> > testcase in GCC's testsuite" is rather non-trivial; FWIW I've
> > written
> > up some notes on working with the GCC testsuite here:
> > https://gcc-newbies-guide.readthedocs.io/en/latest/working-with-the-testsuite.html
> 
> Hmm, I'll try following that; thanks!  Is there anything obvious that
> I might have missed, at first glance?

The main thing is that there's a difference between compiling the test
case "by hand", versus doing it through the test harness - the latter
sets up the environment in a particular way, injects a particular set
of flags, etc etc.

Dave

Re: [PATCH] [rs6000] adjust return_pc debug attrs

[Segher Boessenkool]

Hi!

On Thu, Mar 23, 2023 at 12:06:39AM -0300, Alexandre Oliva wrote:
> On Mar 13, 2023, Segher Boessenkool  wrote:
> > Yes.  On most architectures you can get multiple machine instructions of
> > course (for long calls for example), but on rs6000 (with some ABIs, in
> > some circumstances) we generate a nop insn after calls, so that the
> > linker has a spot to insert fixup code after calls (typically to restore
> > the r2 contents, but it could be anything).
> 
> Thanks.  I wasn't entirely sure that the linker would never ever relax
> the call sequence, moving the bl to the second instruction in the pair,

That would give headaches with maximal offsets, but more importantly
perhaps, many tools depend on knowing exactly where the branches are,
and some actual (assembler) code as well.  It's best not to toy with
branches :-)

> or that no 64-bit call variant existed or would come into existence.

64-bit offsets will not fit in the opcode of course, not even with
prefixes.  And a normal indirect branch *is* to a 64 bit address too.

Making prefixed branch instructions would get us in much the same hot
water (but everywhere instead of just in select cases), and our (I-form)
branches reach 32MB in either direction already (for relative branches;
and you can reach to the low or high 32MB of the address space too, but
not much code uses that at all anyway.  Terrible shame, not in the least
because the extended mnemonics for that are "ba" and "bla").

> > Subtracting 4 from what we currently return is very fragile.
> 
> Agreed.

Very glad we agree on that!

> > The actual return address is *always* the address of the branch insn
> > plus 4, can't you use that?
> 
> Yup, given this piece of knowledge I didn't have, I agree that's a far
> saner approach.

It is the same in any other arch I have seen that has an LR or RA reg.

> I'll post a new version of the patch, now broken up
> into rs6000-specific and machine-independent, momentarily.

Looking forward to it.

> > (Does the GCC code handle delay slots here, btw?
> 
> It does, in that the label is output after the insn sequence.
> 
> >> This patch introduces infrastructure for targets to add an offset to
> >> the label issued after the call_insn to set the call_return_pc
> >> attribute, and uses that on rs6000 to account for nop and l opcodes
> >> issued after actual call opcode as part of call insns output patterns.
> 
> > What is an "l opcode"?
> 
> I have a vague recollection of seeing call sequences ended by loads.
> Ah, yes, rs6000_indirect_call_template_1 outputs ld or lwz, depending on
> TARGET_64BIT, in both speculate and non-speculate cases after the branch
> in ABI_AIX and ABI_ELFv2 calls.  I understand the l in ld and lwz stands
> for 'load', and so I meant 'load' updates, but I guess in the context of
> calls the 'l' can indeed be misleading.  Anyway, that complexity is gone
> thanks to your suggestion.

Ah, "l%s", I see.  On the old POWER ("RIOS") architecture we *did* have
an actual "l" instruction.  There also is the "@l" relocation syntax.
I wasn't quite sure what you were talking about :-)

> >> +/* Return the offset to be added to the label output after CALL_INSN
> >> +   to compute the address to be placed in DW_AT_call_return_pc.  Some
> >> +   call insns output nop or l after bl, so the return address would be
> >> +   wrong without this offset.  */
> >> +
> >> +static int
> >> +rs6000_call_offset_return_label (rtx_insn *call_insn)
> >> +{
> >> +  /* We don't expect SEQUENCEs in this port.  */
> >> +  gcc_checking_assert (GET_CODE (call_insn) == CALL_INSN);
> 
> > That is not doing what the comment says.
> 
> It is.  The documented interface, in the .def file, states that it must
> be either a CALL_INSN or a SEQUENCE.

Ah, in that sense.  But that is more confusing than just not saying
anything imo.

> My rationale to put it in was to (i) confirm that the case of SEQUENCEs
> was considered and needs not be handled in this port, and (ii) should
> someone take inspiration from this implementation of the hook for a port
> that supported delay slots, it would have to be handled.

Yeah.  Blindly copying code from annother port is a recipe for disaster
always.  It is much nicer to not say anything / to not have to say
anything, just let the code speak for itself?


Segher

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
This started to ICE with r11-508-gdfa4fcdba374ed44 in the newly added pass
there,
and since r11-2259-g0a9d711df36b42b6494b73 it ICEs similarly like on the trunk.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.1.0, 13.0
Summary|ICE: in |[11/12/13 Regression] ICE:
   |assign_stack_local_1, at|in assign_stack_local_1, at
   |function.cc:429 with|function.cc:429 with
   |-mpreferred-stack-boundary= |-mpreferred-stack-boundary=
   |2   |2
   Target Milestone|--- |11.4
   Keywords||ice-on-valid-code
  Known to work||10.1.0, 10.4.0, 9.5.0

Re: [PATCH v2] C, ObjC: Add -Wunterminated-string-initialization

[Alejandro Colomar via Gcc-patches]

Hi David,

On 3/24/23 15:53, David Malcolm wrote:
> On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-patches
> wrote:
>> Warn about the following:
>>
>>     char  s[3] = "foo";
>>
[...]

>> ---
>>
>> Hi,
> 
> Hi Alex, thanks for the patch.

:)

> 
>>
>> I sent v1 to the wrong list.  This time I've made sure to write to
>> gcc-patches@.
> 
> Note that right now we're deep in bug-fixing/stabilization for GCC 13
> (and trunk is still tracking that effort), so your patch might be more
> suitable for GCC 14.

Sure, no problem.  Do you have a "next" branch where you pick patches
for after the release, or should I resend after the release?  Is
discussion of a patch reasonable now, or is it too much distracting
from your stabilization efforts?

> 
>>
>> v2 adds some draft of a test, as suggested by Martin.  However, I
>> don't
>> know yet how to write those, so the test is just a draft.  But I did
>> test the feature, by compiling GCC and compiling some small program
>> with
>> it.
> 
> Unfortunately the answer to the question "how do I run just one
> testcase in GCC's testsuite" is rather non-trivial; FWIW I've written
> up some notes on working with the GCC testsuite here:
> https://gcc-newbies-guide.readthedocs.io/en/latest/working-with-the-testsuite.html

Hmm, I'll try following that; thanks!  Is there anything obvious that
I might have missed, at first glance?

> 
> Hope this is helpful

Yup.  Thanks!

> Dave

Cheers,
Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

Max Aehle  changed:

   What|Removed |Added

  Attachment #54745|0   |1
is obsolete||

--- Comment #6 from Max Aehle  ---
Comment on attachment 54745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54745
verbose output, preprocessed source, .i and .s file

I submitted the zip archive because I though that only a single file could be
attached. Afterwards, I attached all files in the archive to this bug report
individually.

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #5 from Max Aehle  ---
Created attachment 54750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54750=edit
produced with -save-temps

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #4 from Max Aehle  ---
Created attachment 54749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54749=edit
produces with -save-temps

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #3 from Max Aehle  ---
Created attachment 54748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54748=edit
preprocessed source produced with -freport-bug

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #2 from Max Aehle  ---
Created attachment 54747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54747=edit
output with additional flag -v

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #1 from Max Aehle  ---
Created attachment 54746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54746=edit
source code of minimal example

[Bug rtl-optimization/109276] New: ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

Bug ID: 109276
   Summary: ICE: in assign_stack_local_1, at function.cc:429 with
-mpreferred-stack-boundary=2
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: max.aehle at scicomp dot uni-kl.de
  Target Milestone: ---

Created attachment 54745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54745=edit
verbose output, preprocessed source, .i and .s file

Compiling the attached bug.c with GCC 12.2.0 via

gcc -m32 -O0 -c bug.c -mpreferred-stack-boundary=2

prints

during RTL pass: split1
bug.c: In function 'fun':
bug.c:23:1: internal compiler error: in assign_stack_local_1, at
function.cc:429
   23 | }
  | ^
0x6d3b9b assign_stack_local_1(machine_mode, poly_int<1u, long>, int, int)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/function.cc:429
0xf81d50 assign_386_stack_local(machine_mode, ix86_stack_slot)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.cc:16558
0x13bdd87 gen_split_65(rtx_insn*, rtx_def**)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.md:5471
0x17d3e0a split_insns(rtx_def*, rtx_insn*)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.md:15646
0x9295fe try_split(rtx_def*, rtx_insn*, int)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/emit-rtl.cc:3795
0xc01fb1 split_insn
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:3384
0xc072f2 split_all_insns()
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:3488
0xc073e8 execute
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:4406
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.

We have attached:
- the stdout/stderr output with the additional flag -v,
- the preprocessed source produced with -freport-bug, 
- the files bug.i and bug.s produced with -save-temps.

The GCC 12.2.0 build was configured only with a --prefix option. gcc -v shows

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/ramdisk/aehle/gcc/gcc-install/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/configure
--prefix=/ramdisk/aehle/gcc/gcc-obj/../gcc-install
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC) 

uname -a says "Linux  5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22
15:00:31 UTC 2022 x86_64 GNU/Linux". /proc/cpuinfo shows a list of 96 cores
with the model name "AMD EPYC 7F72 24-Core Processor". All of the above
commands were executed in a Singularity container based on Debian 11.3.

The source file is a minimal example condensed from Valgrind's m_libcbase.c.

Re: [PATCH] go: Fix up go.test/test/fixedbugs/bug207.go failure [PR109258]

[Ian Lance Taylor]

Jakub Jelinek  writes:

> 2023-03-24  Jakub Jelinek  
>
>   PR middle-end/109258
>   * go-gcc.cc (Gcc_backend): Add new static data members builtin_pure
>   and builtin_nothrow.
>   (Gcc_backend::Gcc_backend): Pass builtin_pure | builtin_nothrow for
>   BUILT_IN_MEMCMP.
>   (Gcc_backend::define_builtin): Handle builtin_pure and builtin_nothrow
>   in flags.

This is OK.  Thanks.  Go ahead and commit.

Ian

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #36 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #34)
> What is the state of this PR?  I see patches posted in August, but don't see
> anything committed...

I've seen some patch submissions and pings in February and it looks like it
just needs a review.  I'll work with the team to get this reviewed.

[Bug libgcc/108891] libatomic: AArch64 SEQ_CST 16-byte load missing barrier

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

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

Wilco  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Wilco  ---
Fixed

[Bug libgcc/108891] libatomic: AArch64 SEQ_CST 16-byte load missing barrier

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Wilco Dijkstra :

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

commit r13-6855-g1f641d6aba284e0c277e6684cd6b2c73591cd14d
Author: Wilco Dijkstra 
Date:   Fri Feb 10 17:41:05 2023 +

libatomic: Fix SEQ_CST 128-bit atomic load [PR108891]

The LSE2 ifunc for 16-byte atomic load requires a barrier before the LDP -
without it, it effectively has Load-AcquirePC semantics similar to LDAPR,
which is less restrictive than what __ATOMIC_SEQ_CST requires.  This patch
fixes this and adds comments to make it easier to see which sequence is
used for each case.  Use a load/store exclusive loop for store to simplify
testing memory ordering is correct (it is slightly faster too).

libatomic/
PR libgcc/108891
* config/linux/aarch64/atomic_16.S: Fix libat_load_16_i1.
Add comments describing the memory order.

[committed] libgomp.texi: Fix wording in GCN offload specifics

[Tobias Burnus]

Stumbled over 'Reverse offload are', fixed by changing it to 'Reverse
offload regions are'.

Committed as r13-6854

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 243fa4883cf6fccaaafddcc82e6b58843c82fb30
Author: Tobias Burnus 
Date:   Fri Mar 24 17:32:59 2023 +0100

libgomp.texi: Fix wording in GCN offload specifics

libgomp/
* libgomp.texi (Offload-Target Specifics): Grammar fix.

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 5bcb84a1d6f..dc6b4aca38b 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -4454,7 +4454,7 @@ The implementation remark:
 @item I/O within OpenMP target regions and OpenACC parallel/kernels is supported
   using the C library @code{printf} functions and the Fortran
   @code{print}/@code{write} statements.
-@item Reverse offload (i.e. @code{target} regions with
+@item Reverse offload regions (i.e. @code{target} regions with
   @code{device(ancestor:1)}) are processed serially per @code{target} region
   such that the next reverse offload region is only executed after the previous
   one returned.

Re: [PATCH] PR tree-optimization/109274 - Don't interpret contents of a value_relation record.

[Jakub Jelinek via Gcc-patches]

On Fri, Mar 24, 2023 at 11:52:30AM -0400, Andrew MacLeod wrote:
> Thanks.. Ive incorporated it into my commit  too.

Note, both my earlier version of the patch and your patch regress:
FAIL: gcc.dg/tree-ssa/vrp-float-3a.c scan-tree-dump-not evrp "link_error"
FAIL: gcc.dg/tree-ssa/vrp-float-4a.c scan-tree-dump-not evrp "link_error"

Jakub

[og12] Add 'libgomp.c/alloc-ompx_host_mem_alloc-1.c'

[Thomas Schwinge]

Hi!

This had fallen out of some earlier work of mine; I've now pushed to
devel/omp/gcc-12 branch commit ae2dca26602678f8b70e22da1bce8302c0751b75
"Add 'libgomp.c/alloc-ompx_host_mem_alloc-1.c'", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From ae2dca26602678f8b70e22da1bce8302c0751b75 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 15 Feb 2023 11:27:55 +0100
Subject: [PATCH] Add 'libgomp.c/alloc-ompx_host_mem_alloc-1.c'

OpenMP 'ompx_host_mem_alloc' is available for host and nvptx offloading as of
og12 commit 84914e197d91a67b3d27db0e4c69a433462983a5
"openmp, nvptx: ompx_unified_shared_mem_alloc", and for GCN offloading as of
og12 commit c77c45a641fedc3fe770e909cc010fb1735bdbbd
"amdgcn, libgomp: low-latency allocator".

	libgomp/
	* testsuite/libgomp.c/alloc-ompx_host_mem_alloc-1.c: New.
---
 libgomp/ChangeLog.omp |  2 +
 .../libgomp.c/alloc-ompx_host_mem_alloc-1.c   | 77 +++
 2 files changed, 79 insertions(+)
 create mode 100644 libgomp/testsuite/libgomp.c/alloc-ompx_host_mem_alloc-1.c

diff --git a/libgomp/ChangeLog.omp b/libgomp/ChangeLog.omp
index ef957e3d2d8..6b816e46cd2 100644
--- a/libgomp/ChangeLog.omp
+++ b/libgomp/ChangeLog.omp
@@ -1,5 +1,7 @@
 2023-03-24  Thomas Schwinge  
 
+	* testsuite/libgomp.c/alloc-ompx_host_mem_alloc-1.c: New.
+
 	* config/gcn/allocator.c (gcn_memspace_free): Explicitly handle
 	'memspace == ompx_host_mem_space'.
 
diff --git a/libgomp/testsuite/libgomp.c/alloc-ompx_host_mem_alloc-1.c b/libgomp/testsuite/libgomp.c/alloc-ompx_host_mem_alloc-1.c
new file mode 100644
index 000..683b7aff3d4
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c/alloc-ompx_host_mem_alloc-1.c
@@ -0,0 +1,77 @@
+/* Verify that on the host we can but on a device we cannot allocate 'ompx_host_mem_alloc' memory.  */
+
+/* { dg-additional-options -DOFFLOAD_DEVICE { target offload_device } } */
+
+#include 
+
+#pragma omp requires dynamic_allocators
+
+int main()
+{
+#pragma omp target
+  {
+char *c, *c_;
+
+c = omp_alloc(1, ompx_host_mem_alloc);
+#ifdef OFFLOAD_DEVICE
+if (c)
+  __builtin_abort ();
+#else
+if (!c)
+  __builtin_abort ();
+#endif
+omp_free(c, ompx_host_mem_alloc);
+
+c = omp_aligned_alloc(128, 256, ompx_host_mem_alloc);
+#ifdef OFFLOAD_DEVICE
+if (c)
+  __builtin_abort ();
+#else
+if (!c)
+  __builtin_abort ();
+#endif
+omp_free(c, omp_null_allocator);
+
+c = omp_calloc(1, 1, ompx_host_mem_alloc);
+#ifdef OFFLOAD_DEVICE
+if (c)
+  __builtin_abort ();
+#else
+if (!c)
+  __builtin_abort ();
+#endif
+c_ = omp_realloc(c, 2, ompx_host_mem_alloc, ompx_host_mem_alloc);
+#ifdef OFFLOAD_DEVICE
+if (c_)
+  __builtin_abort ();
+#else
+if (!c_)
+  __builtin_abort ();
+#endif
+c = omp_realloc(c_, 0, ompx_host_mem_alloc, ompx_host_mem_alloc);
+if (c)
+  __builtin_abort ();
+
+c = omp_aligned_calloc(64, 1, 512, ompx_host_mem_alloc);
+#ifdef OFFLOAD_DEVICE
+if (c)
+  __builtin_abort ();
+#else
+if (!c)
+  __builtin_abort ();
+#endif
+c_ = omp_realloc(c, 2, c ? omp_null_allocator : ompx_host_mem_alloc, omp_null_allocator);
+#ifdef OFFLOAD_DEVICE
+if (c_)
+  __builtin_abort ();
+#else
+if (!c_)
+  __builtin_abort ();
+#endif
+c = omp_realloc(c_, 0, omp_null_allocator, omp_null_allocator);
+if (c)
+  __builtin_abort ();
+  }
+
+  return 0;
+}
-- 
2.25.1

[Bug c++/105481] [10/11/12/13 Regression] ICE: unexpected expression of kind template_parm_index

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

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

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r13-6853-g4e2cdb1ddb5f6ace909358775e94bfe23046ad5a
Author: Jason Merrill 
Date:   Thu Mar 23 18:20:52 2023 -0400

c++: default template arg, partial ordering [PR105481]

The default argument code in type_unification_real was assuming that all
targs we've deduced by that point are non-dependent, but that's not the
case
for partial ordering.

PR c++/105481

gcc/cp/ChangeLog:

* pt.cc (type_unification_real): Adjust for partial ordering.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/fntmpdefarg-partial1.C: New test.

[pushed] c++: default template arg, partial ordering [PR105481]

[Jason Merrill via Gcc-patches]

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

The default argument code in type_unification_real was assuming that all
targs we've deduced by that point are non-dependent, but that's not the case
for partial ordering.

PR c++/105481

gcc/cp/ChangeLog:

* pt.cc (type_unification_real): Adjust for partial ordering.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/fntmpdefarg-partial1.C: New test.
---
 gcc/cp/pt.cc   | 18 ++
 .../g++.dg/cpp0x/fntmpdefarg-partial1.C|  8 
 2 files changed, 22 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/fntmpdefarg-partial1.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 40deedc9ba9..3bb98ebeac1 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -23304,14 +23304,24 @@ type_unification_real (tree tparms,
  return unify_parameter_deduction_failure (explain_p, tparm);
}
 
+  /* During partial ordering, we deduce dependent template args.  */
+  bool any_dependent_targs = false;
+
   /* Now substitute into the default template arguments.  */
   for (i = 0; i < ntparms; i++)
{
  tree targ = TREE_VEC_ELT (targs, i);
  tree tparm = TREE_VEC_ELT (tparms, i);
 
- if (targ || tparm == error_mark_node)
+ if (targ)
+   {
+ if (!any_dependent_targs && dependent_template_arg_p (targ))
+   any_dependent_targs = true;
+ continue;
+   }
+ if (tparm == error_mark_node)
continue;
+
  tree parm = TREE_VALUE (tparm);
  tree arg = TREE_PURPOSE (tparm);
  reopen_deferring_access_checks (*checks);
@@ -23347,9 +23357,9 @@ type_unification_real (tree tparms,
 do this substitution without processing_template_decl.  This
 is important if the default argument contains something that
 might be instantiation-dependent like access (87480).  */
- processing_template_decl_sentinel s;
+ processing_template_decl_sentinel s (!any_dependent_targs);
  tree substed = NULL_TREE;
- if (saw_undeduced == 1)
+ if (saw_undeduced == 1 && !any_dependent_targs)
{
  /* First instatiate in template context, in case we still
 depend on undeduced template parameters.  */
@@ -23372,7 +23382,7 @@ type_unification_real (tree tparms,
 complain, i, NULL_TREE);
  else if (saw_undeduced == 1)
arg = NULL_TREE;
- else
+ else if (!any_dependent_targs)
arg = error_mark_node;
}
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg-partial1.C 
b/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg-partial1.C
new file mode 100644
index 000..2a6783e566b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg-partial1.C
@@ -0,0 +1,8 @@
+// PR c++/105481
+// { dg-do compile { target c++11 } }
+
+template struct uint;
+template uint f(const uint &);
+template> uint f(T);
+using X = uint<1>;
+X (*fp)(X const &) = f;

base-commit: c4792bd1de0621932a47fb86aca09fafafdb2972
-- 
2.31.1

Pending OpenMP patches

[Tobias Burnus]

Just to keep track myself, the following OpenMP are pending review - either
by Jakub or by me. It does not look as if any of those will get into GCC 13,
but who knows. I think the first three could:


[Doc patch - will go into GCC 13, still comments are welcome:]
[patch V2] Docs, OpenMP: Correct internal documentation of OMP_FOR
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614392.html


libgomp: Simplify OpenMP reverse offload host <-> device memory copy 
implementation
   (was: [Patch] libgomp/nvptx: Prepare for reverse-offload callback handling)
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614569.html

[Patch,v4] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length 
strings
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614472.html

[PATCH] openmp: Add support for 'present' modifier
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611299.html

[PATCH 0/3] OpenMP 5.0: Strided updates and array shape-operator support (C++)
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613785.html

[PATCH 0/7] openmp: OpenMP 5.1 loop transformation directives
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614564.html

[Patch] Fortran/OpenMP: Add parsing support for allocators/allocate directive
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608904.html

Complete patch set was just re-submitted by Julian, overview patch is
[PATCH v6 00/11] OpenMP: C/C++ lvalue parsing, C/C++/Fortran "declare mapper" 
support
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/thread.html#609031
- with follow up for 10/11 -
[PATCH v6 10/11] OpenMP: Support OpenMP 5.0 "declare mapper" directives for C
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609566.html

Plus some more pending patches, some of which require re-diffing
or checking the backlog. Others are to be expected soon...

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955