Re: Question on patch -fprofile-partial-training

2023-05-09 Thread Martin Liška

On 5/4/23 15:37, Qing Zhao wrote:




On May 4, 2023, at 9:05 AM, Martin Liška  wrote:

On 5/4/23 14:54, Qing Zhao wrote:




On May 4, 2023, at 4:30 AM, Martin Liška  wrote:

On 5/3/23 21:10, Qing Zhao via Gcc-patches wrote:

Hi, Jan,

You added the following patch into gcc10:

 From 34fbe3f0946f88828765184ed6581bda62cdf49f Mon Sep 17 00:00:00 2001
From: Jan Hubicka 
Date: Thu, 5 Dec 2019 19:12:51 +0100
Subject: [PATCH] cgraphclones.c (localize_profile): New function.

   * cgraphclones.c (localize_profile): New function.
   (cgraph_node::create_clone): Use it for partial profiles.
   * common.opt (fprofile-partial-training): New flag.
   * doc/invoke.texi (-fprofile-partial-training): Document.
   * ipa-cp.c (update_profiling_info): For partial profiles do not
   set function profile to zero.
   * profile.c (compute_branch_probabilities): With partial profile
   watch if edge count is zero and turn all probabilities to guessed.
   (compute_branch_probabilities): For partial profiles do not apply
   profile when entry count is zero.
   * tree-profile.c (tree_profiling): Only do value_profile_transformations
   when profile is read.

My question is:


Hello.

Why would anybody backport such change to unsupported code-stream of GCC 8?
Generally speaking, I discourage from doing that.


Yes, I agree.
However, many users still use GCC8 right now, and some of them are asking for 
more performance
from PGO recently. That’s the reason I am studying this right now.


I understand there are products that are based on GCC8, but as the branch is 
officially unsupported, I don't
see a reason to backport a new feature from newer release. It's just asking for 
troubles. If your clients are
interested in more performance, then they should use a recent supported release.

We are trying to persuade them to use newer GCC, but it’s quite hard...




 From my understanding, -fprofile-partial-training is one important option for 
PGO performance.


I don't think so, speed benefit would be rather small I guess.

I saw some articles online to introduce this option for gcc10,
https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html#sec-gcc10-pgo


Hi.

Ah, I see.


And also based on my previous experience in Studio compiler, I guess that this 
one might have
Some good performance impact on PGO.  Is there any old performance data on this 
option? (I cannot find online)


Maybe Honza can chime in here? Or Martin who is the author of the white paper.

Martin



thanks.

Qing




I’d like
to see any big technique difficult to prevent it from being back ported to GCC8.


There might be of course some patch dependencies and I don't see a point why 
should we waste
time with that.

Cheers,
Martin



Thanks.

Qing



Martin



Can this patch be back ported to GCC8 easily? I am wondering any significant
Change between GCC8 and GCC10 that might make the backporting very hard>
Thanks a lot for your help.

Qing






Re: Question on patch -fprofile-partial-training

2023-05-04 Thread Martin Liška
On 5/4/23 14:54, Qing Zhao wrote:
> 
> 
>> On May 4, 2023, at 4:30 AM, Martin Liška  wrote:
>>
>> On 5/3/23 21:10, Qing Zhao via Gcc-patches wrote:
>>> Hi, Jan,
>>>
>>> You added the following patch into gcc10:
>>>
>>> From 34fbe3f0946f88828765184ed6581bda62cdf49f Mon Sep 17 00:00:00 2001
>>> From: Jan Hubicka 
>>> Date: Thu, 5 Dec 2019 19:12:51 +0100
>>> Subject: [PATCH] cgraphclones.c (localize_profile): New function.
>>>
>>>* cgraphclones.c (localize_profile): New function.
>>>(cgraph_node::create_clone): Use it for partial profiles.
>>>* common.opt (fprofile-partial-training): New flag.
>>>* doc/invoke.texi (-fprofile-partial-training): Document.
>>>* ipa-cp.c (update_profiling_info): For partial profiles do not
>>>set function profile to zero.
>>>* profile.c (compute_branch_probabilities): With partial profile
>>>watch if edge count is zero and turn all probabilities to guessed.
>>>(compute_branch_probabilities): For partial profiles do not apply
>>>profile when entry count is zero.
>>>* tree-profile.c (tree_profiling): Only do 
>>> value_profile_transformations
>>>when profile is read.
>>>
>>> My question is:
>>
>> Hello.
>>
>> Why would anybody backport such change to unsupported code-stream of GCC 8?
>> Generally speaking, I discourage from doing that.
> 
> Yes, I agree.
> However, many users still use GCC8 right now, and some of them are asking for 
> more performance
> from PGO recently. That’s the reason I am studying this right now. 

I understand there are products that are based on GCC8, but as the branch is 
officially unsupported, I don't
see a reason to backport a new feature from newer release. It's just asking for 
troubles. If your clients are
interested in more performance, then they should use a recent supported release.

> 
> From my understanding, -fprofile-partial-training is one important option for 
> PGO performance.

I don't think so, speed benefit would be rather small I guess.

> I’d like
> to see any big technique difficult to prevent it from being back ported to 
> GCC8. 

There might be of course some patch dependencies and I don't see a point why 
should we waste
time with that.

Cheers,
Martin

> 
> Thanks.
> 
> Qing
> 
>>
>> Martin
>>
>>>
>>> Can this patch be back ported to GCC8 easily? I am wondering any significant
>>> Change between GCC8 and GCC10 that might make the backporting very hard> 
>>> Thanks a lot for your help.
>>>
>>> Qing
> 



Re: [PATCH] gcov: add info about "calls" to JSON output format

2023-05-04 Thread Martin Liška
Hello.

After discussion with the consumers of the format:
https://github.com/gcovr/gcovr/issues/282#issuecomment-1534239536

I'm going to push a patch that prints JSON version in gcov -v.

Thanks,
MartinFrom d879d68eb309561d266ddf734ab8c69f4fef3874 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 4 May 2023 10:27:55 +0200
Subject: [PATCH] gcov: add GCOV format version to gcov -v

gcc/ChangeLog:

	* gcov.cc (GCOV_JSON_FORMAT_VERSION): New definition.
	(print_version): Use it.
	(generate_results): Likewise.
---
 gcc/gcov.cc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index d96b4f77e3b..2fad6aa7ede 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -58,6 +58,8 @@ using namespace std;
 #include "gcov-io.h"
 #include "gcov-io.cc"
 
+#define GCOV_JSON_FORMAT_VERSION "2"
+
 /* The gcno file is generated by -ftest-coverage option. The gcda file is
generated by a program compiled with -fprofile-arcs. Their formats
are documented in gcov-io.h.  */
@@ -964,6 +966,7 @@ static void
 print_version (void)
 {
   fnotice (stdout, "gcov %s%s\n", pkgversion_string, version_string);
+  fnotice (stdout, "JSON format version: %s\n", GCOV_JSON_FORMAT_VERSION);
   fprintf (stdout, "Copyright %s 2023 Free Software Foundation, Inc.\n",
 	   _("(C)"));
   fnotice (stdout,
@@ -1546,7 +1549,7 @@ generate_results (const char *file_name)
   gcov_intermediate_filename = get_gcov_intermediate_filename (file_name);
 
   json::object *root = new json::object ();
-  root->set ("format_version", new json::string ("2"));
+  root->set ("format_version", new json::string (GCOV_JSON_FORMAT_VERSION));
   root->set ("gcc_version", new json::string (version_string));
 
   if (bbg_cwd != NULL)
-- 
2.40.1



Re: Question on patch -fprofile-partial-training

2023-05-04 Thread Martin Liška
On 5/3/23 21:10, Qing Zhao via Gcc-patches wrote:
> Hi, Jan,
> 
> You added the following patch into gcc10:
> 
> From 34fbe3f0946f88828765184ed6581bda62cdf49f Mon Sep 17 00:00:00 2001
> From: Jan Hubicka 
> Date: Thu, 5 Dec 2019 19:12:51 +0100
> Subject: [PATCH] cgraphclones.c (localize_profile): New function.
> 
> * cgraphclones.c (localize_profile): New function.
> (cgraph_node::create_clone): Use it for partial profiles.
> * common.opt (fprofile-partial-training): New flag.
> * doc/invoke.texi (-fprofile-partial-training): Document.
> * ipa-cp.c (update_profiling_info): For partial profiles do not
> set function profile to zero.
> * profile.c (compute_branch_probabilities): With partial profile
> watch if edge count is zero and turn all probabilities to guessed.
> (compute_branch_probabilities): For partial profiles do not apply
> profile when entry count is zero.
> * tree-profile.c (tree_profiling): Only do 
> value_profile_transformations
> when profile is read.
> 
> My question is:

Hello.

Why would anybody backport such change to unsupported code-stream of GCC 8?
Generally speaking, I discourage from doing that.

Martin

> 
> Can this patch be back ported to GCC8 easily? I am wondering any significant
> Change between GCC8 and GCC10 that might make the backporting very hard> 
> Thanks a lot for your help.
> 
> Qing



[PATCH (pushed)] riscv: fix error: control reaches end of non-void function

2023-05-03 Thread Martin Liška
It's pre-approved by Jakub.

Cheers,
Martin

Fixes:
gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function 
[-Werror=return-type]
66 |   [(set (attr "length") (const_int 4))])
   | ^

PR target/109713

gcc/ChangeLog:

* config/riscv/sync.md: Add gcc_unreachable to a switch.
---
 gcc/config/riscv/sync.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/config/riscv/sync.md b/gcc/config/riscv/sync.md
index 6e7c762ac57..9fc626267de 100644
--- a/gcc/config/riscv/sync.md
+++ b/gcc/config/riscv/sync.md
@@ -62,6 +62,8 @@ (define_insn "mem_thread_fence_1"
return "fence\tr,rw";
 else if (model == MEMMODEL_RELEASE)
return "fence\trw,w";
+else
+   gcc_unreachable ();
   }
   [(set (attr "length") (const_int 4))])
 
-- 
2.40.1



Re: [PATCH v5 09/11] RISC-V: Weaken mem_thread_fence

2023-05-03 Thread Martin Liška
On 5/3/23 14:18, Andreas Schwab via Gcc-patches wrote:
> ../../gcc/config/riscv/sync.md: In function 'const char* 
> output_479(rtx_def**, rtx_insn*)':
> ../../gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void 
> function [-Werror=return-type]
>66 |   [(set (attr "length") (const_int 4))])
>   | ^
> 

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


[PATCH (pushed)] clang warning: warning: private field 'm_gc' is not used [-Wunused-private-field]

2023-05-03 Thread Martin Liška
Pushed to master as obvious.

Martin

PR tree-optimization/109693

gcc/ChangeLog:

* value-range-storage.cc (vrange_allocator::vrange_allocator):
Remove unused field.
* value-range-storage.h: Likewise.
---
 gcc/value-range-storage.cc | 1 -
 gcc/value-range-storage.h  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/gcc/value-range-storage.cc b/gcc/value-range-storage.cc
index 7d2de5e8384..14bec500dbc 100644
--- a/gcc/value-range-storage.cc
+++ b/gcc/value-range-storage.cc
@@ -80,7 +80,6 @@ public:
 };
 
 vrange_allocator::vrange_allocator (bool gc)
-  : m_gc (gc)
 {
   if (gc)
 m_alloc = new vrange_ggc_alloc;
diff --git a/gcc/value-range-storage.h b/gcc/value-range-storage.h
index 4ec0da73059..a90b64b2bf0 100644
--- a/gcc/value-range-storage.h
+++ b/gcc/value-range-storage.h
@@ -38,7 +38,6 @@ public:
 private:
   DISABLE_COPY_AND_ASSIGN (vrange_allocator);
   class vrange_internal_alloc *m_alloc;
-  bool m_gc;
 };
 
 // Efficient memory storage for a vrange.
-- 
2.40.1



[PATCH (pushed)] docs: port documentation of VRP params

2023-05-02 Thread Martin Liška

gcc/ChangeLog:

* doc/invoke.texi: Update documentation based on param.opt file.
---
 gcc/doc/invoke.texi | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2f40c58b21c..b92b8576027 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15988,15 +15988,9 @@ The maximum number of may-defs we analyze when looking 
for a must-def
 specifying the dynamic type of an object that invokes a virtual call
 we may be able to devirtualize speculatively.
 
-@item evrp-sparse-threshold

-Maximum number of basic blocks before EVRP uses a sparse cache.
-
 @item ranger-debug
 Specifies the type of debug output to be issued for ranges.
 
-@item evrp-switch-limit

-Specifies the maximum number of switch cases before EVRP ignores a switch.
-
 @item unroll-jam-min-percent
 The minimum percentage of memory references that must be optimized
 away for the unroll-and-jam transformation to be considered profitable.
@@ -16055,6 +16049,15 @@ this parameter.  The default value of this parameter 
is 50.
 @item vect-induction-float
 Enable loop vectorization of floating point inductions.
 
+@item vrp-sparse-threshold

+Maximum number of basic blocks before VRP uses a sparse bitmap cache.
+
+@item vrp-switch-limit
+Maximum number of outgoing edges in a switch before VRP will not process it.
+
+@item vrp-vector-threshold
+Maximum number of basic blocks for VRP to use a basic cache vector.
+
 @item avoid-fma-max-bits
 Maximum number of bits for which we avoid creating FMAs.
 
--

2.40.1



[PATCH (pushed)] hwasan: adjust wording in expected output in tests

2023-04-30 Thread Martin Liška
gcc/testsuite/ChangeLog:

* c-c++-common/hwasan/asan-pr70541.c: Adjust wording of expected
output.
* c-c++-common/hwasan/heap-overflow.c: Likewise.
* c-c++-common/hwasan/sanity-check-pure-c.c: Likewise.
* c-c++-common/hwasan/use-after-free.c: Likewise.
---
 gcc/testsuite/c-c++-common/hwasan/asan-pr70541.c| 2 +-
 gcc/testsuite/c-c++-common/hwasan/heap-overflow.c   | 4 ++--
 gcc/testsuite/c-c++-common/hwasan/sanity-check-pure-c.c | 4 ++--
 gcc/testsuite/c-c++-common/hwasan/use-after-free.c  | 4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/hwasan/asan-pr70541.c 
b/gcc/testsuite/c-c++-common/hwasan/asan-pr70541.c
index ba2ed496e6e..be534dfd231 100644
--- a/gcc/testsuite/c-c++-common/hwasan/asan-pr70541.c
+++ b/gcc/testsuite/c-c++-common/hwasan/asan-pr70541.c
@@ -33,4 +33,4 @@ int main() {
 /* { dg-output "HWAddressSanitizer: tag-mismatch on address 0x\[0-9a-f\]*.*" } 
*/
 /* { dg-output "READ of size 4 at 0x\[0-9a-f\]* tags: 
\[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\] \\(ptr/mem\\) 
in thread T0.*" } */
 /* { dg-output "freed by thread T0 here:.*" } */
-/* { dg-output "previously allocated here:" } */
+/* { dg-output "previously allocated by thread T0 here:" } */
diff --git a/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c 
b/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c
index a5a37715925..e424d8bcb12 100644
--- a/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c
+++ b/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c
@@ -24,6 +24,6 @@ int main(int argc, char **argv) {
 
 /* { dg-output "HWAddressSanitizer: tag-mismatch on address 0x\[0-9a-f\]*.*" } 
*/
 /* { dg-output "READ of size 1 at 0x\[0-9a-f\]* tags: 
\[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\].* 
\\(ptr/mem\\) in thread T0.*" } */
-/* { dg-output "located 0 bytes after 10-byte region.*" } */
-/* { dg-output "allocated here:.*" } */
+/* { dg-output "located 0 bytes after a 10-byte region.*" } */
+/* { dg-output "allocated by thread T0 here:.*" } */
 /* { dg-output "#1 0x\[0-9a-f\]+ +in _*main \[^\n\r]*heap-overflow.c:18" } */
diff --git a/gcc/testsuite/c-c++-common/hwasan/sanity-check-pure-c.c 
b/gcc/testsuite/c-c++-common/hwasan/sanity-check-pure-c.c
index a42921bb44c..4e557000458 100644
--- a/gcc/testsuite/c-c++-common/hwasan/sanity-check-pure-c.c
+++ b/gcc/testsuite/c-c++-common/hwasan/sanity-check-pure-c.c
@@ -20,6 +20,6 @@ int main() {
 
 /* { dg-output "HWAddressSanitizer: tag-mismatch on address 0x\[0-9a-f\]*.*" } 
*/
 /* { dg-output "READ of size 1 at 0x\[0-9a-f\]* tags: 
\[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\] \\(ptr/mem\\) 
in thread T0.*" } */
-/* { dg-output "located 5 bytes inside of 10-byte region.*" } */
+/* { dg-output "located 5 bytes inside a 10-byte region.*" } */
 /* { dg-output "freed by thread T0 here:.*" } */
-/* { dg-output "previously allocated here:" } */
+/* { dg-output "previously allocated by thread T0 here:" } */
diff --git a/gcc/testsuite/c-c++-common/hwasan/use-after-free.c 
b/gcc/testsuite/c-c++-common/hwasan/use-after-free.c
index 41a356999aa..b058982935f 100644
--- a/gcc/testsuite/c-c++-common/hwasan/use-after-free.c
+++ b/gcc/testsuite/c-c++-common/hwasan/use-after-free.c
@@ -21,8 +21,8 @@ int main() {
 
 /* { dg-output "HWAddressSanitizer: tag-mismatch on address 0x\[0-9a-f\]*.*" } 
*/
 /* { dg-output "READ of size 1 at 0x\[0-9a-f\]* tags: 
\[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\] \\(ptr/mem\\) 
in thread T0.*" } */
-/* { dg-output "is located 5 bytes inside of 10-byte region.*" } */
+/* { dg-output "is located 5 bytes inside a 10-byte region.*" } */
 /* { dg-output "freed by thread T0 here:.*" } */
 /* { dg-output "#1\[^\n\r]*main\[^\n\r]*use-after-free.c:17.*" } */
-/* { dg-output "previously allocated here:.*" } */
+/* { dg-output "previously allocated by thread T0 here:.*" } */
 /* { dg-output "#1\[^\n\r]*main\[^\n\r]*use-after-free.c:16" } */
-- 
2.40.1



[PATCH (pushed)] libsanitizer: link hwasan against lsan library

2023-04-30 Thread Martin Liška
Similarly to libasan.so, libhwasan.so also utilizes some
of the symbols from lsan library.

PR sanitizer/109674

libsanitizer/ChangeLog:

* hwasan/Makefile.am: Depend on liblsan.
* hwasan/Makefile.in: Re-generate.
---
 libsanitizer/hwasan/Makefile.am | 2 +-
 libsanitizer/hwasan/Makefile.in | 6 --
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/libsanitizer/hwasan/Makefile.am b/libsanitizer/hwasan/Makefile.am
index 5a89189f6d8..bb7f8fa0b7b 100644
--- a/libsanitizer/hwasan/Makefile.am
+++ b/libsanitizer/hwasan/Makefile.am
@@ -38,7 +38,7 @@ hwasan_files = \
hwasan_type_test.cpp
 
 libhwasan_la_SOURCES = $(hwasan_files)
-libhwasan_la_LIBADD = $(top_builddir)/sanitizer_common/libsanitizer_common.la
+libhwasan_la_LIBADD = $(top_builddir)/sanitizer_common/libsanitizer_common.la 
$(top_builddir)/lsan/libsanitizer_lsan.la
 if !USING_MAC_INTERPOSE
 libhwasan_la_LIBADD += $(top_builddir)/interception/libinterception.la
 endif
diff --git a/libsanitizer/hwasan/Makefile.in b/libsanitizer/hwasan/Makefile.in
index 4240aa90147..58bc26b44b9 100644
--- a/libsanitizer/hwasan/Makefile.in
+++ b/libsanitizer/hwasan/Makefile.in
@@ -148,7 +148,8 @@ LTLIBRARIES = $(toolexeclib_LTLIBRARIES)
 am__DEPENDENCIES_1 =
 libhwasan_la_DEPENDENCIES =  \
$(top_builddir)/sanitizer_common/libsanitizer_common.la \
-   $(am__append_1) $(am__append_2) $(am__DEPENDENCIES_1)
+   $(top_builddir)/lsan/libsanitizer_lsan.la $(am__append_1) \
+   $(am__append_2) $(am__DEPENDENCIES_1)
 am__objects_1 = hwasan_allocation_functions.lo hwasan_allocator.lo \
hwasan.lo hwasan_dynamic_shadow.lo hwasan_exceptions.lo \
hwasan_fuchsia.lo hwasan_globals.lo hwasan_interceptors.lo \
@@ -444,7 +445,8 @@ hwasan_files = \
 libhwasan_la_SOURCES = $(hwasan_files)
 libhwasan_la_LIBADD =  \
$(top_builddir)/sanitizer_common/libsanitizer_common.la \
-   $(am__append_1) $(am__append_2) $(LIBSTDCXX_RAW_CXX_LDFLAGS)
+   $(top_builddir)/lsan/libsanitizer_lsan.la $(am__append_1) \
+   $(am__append_2) $(LIBSTDCXX_RAW_CXX_LDFLAGS)
 libhwasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` 
$(link_libhwasan)
 
 # Work around what appears to be a GNU make bug handling MAKEFLAGS
-- 
2.40.1



Re: libsanitizer: sync from master

2023-04-30 Thread Martin Liška
On 4/28/23 11:23, Florian Weimer wrote:
> * Martin Liška:
> 
>> On 4/26/23 20:31, Florian Weimer wrote:
>>> * Martin Liška:
>>>
>>>> On 11/15/22 16:47, Martin Liška wrote:
>>>>> Hi.
>>>>>
>>>>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>>>>> ppc64le-linux systems.
>>>>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>>>>> abidiff.
>>>>
>>>> Hello.
>>>>
>>>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
>>>
>>> So … we have the issue that involves interceptors outside of libc.so.6,
>>> namely crypt, crypt_r, and I posted an upstream patch for this:
>>>
>>>   sanitizers: Disable crypt, crypt_r interceptors for glibc
>>>   <https://reviews.llvm.org/D144073>
>>>
>>> Can we just apply this downstream for now?  It blocks various folks from
>>> using the sanitizers in their projects.
>>
>> Hello.
>>
>> Your upstream revision has been already accepted, so please apply it
>> and I'm going to do one more merge from upstream in the following
>> days. Does it work for you?
> 
> It's moving in a different direction now: <https://reviews.llvm.org/D149403>
> 
> But that's okay for me as well.
> 
> Thanks,
> Florian
> 

Hello.

I've just pushed merged libsanitizer that contains both crypt-related changes
and x32 fix from H.J.

Cheers,
Martin


Re: libsanitizer: sync from master

2023-04-30 Thread Martin Liška
On 4/28/23 11:23, Florian Weimer wrote:
> * Martin Liška:
> 
>> On 4/26/23 20:31, Florian Weimer wrote:
>>> * Martin Liška:
>>>
>>>> On 11/15/22 16:47, Martin Liška wrote:
>>>>> Hi.
>>>>>
>>>>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>>>>> ppc64le-linux systems.
>>>>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>>>>> abidiff.
>>>>
>>>> Hello.
>>>>
>>>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
>>>
>>> So … we have the issue that involves interceptors outside of libc.so.6,
>>> namely crypt, crypt_r, and I posted an upstream patch for this:
>>>
>>>   sanitizers: Disable crypt, crypt_r interceptors for glibc
>>>   <https://reviews.llvm.org/D144073>
>>>
>>> Can we just apply this downstream for now?  It blocks various folks from
>>> using the sanitizers in their projects.
>>
>> Hello.
>>
>> Your upstream revision has been already accepted, so please apply it
>> and I'm going to do one more merge from upstream in the following
>> days. Does it work for you?
> 
> It's moving in a different direction now: <https://reviews.llvm.org/D149403>
> 
> But that's okay for me as well.
> 
> Thanks,
> Florian
> 

Hello.

I've just pushed merged libsanitizer that contains both crypt-related changes
and x32 fix from H.J.

Cheers,
Martin


[PATCH (pushed)] contrib: port doxygen script to Python3

2023-04-28 Thread Martin Liška
Pushed to master as obvious.

Martin

contrib/ChangeLog:

* filter_gcc_for_doxygen: Use python3 and not python2.
* filter_params.py: Likewise.
---
 contrib/filter_gcc_for_doxygen | 2 +-
 contrib/filter_params.py   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/filter_gcc_for_doxygen b/contrib/filter_gcc_for_doxygen
index d1109a50c88..d3670604b01 100755
--- a/contrib/filter_gcc_for_doxygen
+++ b/contrib/filter_gcc_for_doxygen
@@ -8,5 +8,5 @@
 # process is put on stdout.
 
 dir=`dirname $0`
-python $dir/filter_params.py $1
+env python3 $dir/filter_params.py $1
 exit 0
diff --git a/contrib/filter_params.py b/contrib/filter_params.py
index a82a8d5728c..359d28b07d2 100644
--- a/contrib/filter_params.py
+++ b/contrib/filter_params.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python3
 """
 Filters out some of the #defines used throughout the GCC sources:
 - GTY(()) marks declarations for gengtype.c
-- 
2.40.0



Re: [PATCH] libsanitizer: cherry-pick commit 05551c658269 from upstream

2023-04-27 Thread Martin Liška
On 4/27/23 04:32, H.J. Lu via Gcc-patches wrote:
> cherry-pick:

Can you please wait a few days before it? I'm going to merge again
in the near future after https://reviews.llvm.org/D144073 got handled.

Martin

> 
> 05551c658269 [sanitizer] Correct alignment of x32 __sanitizer_siginfo
> 
>   * sanitizer_common/sanitizer_platform_limits_posix.h
>   (__sanitizer_siginfo_pad): Use u64 to align x32
>   __sanitizer_siginfo to 8 bytes.
> ---
>  .../sanitizer_common/sanitizer_platform_limits_posix.h   | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
> b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> index cfca7bdedbe..e6f298c26e1 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> @@ -578,8 +578,13 @@ struct __sanitizer_sigset_t {
>  #endif
>  
>  struct __sanitizer_siginfo_pad {
> +#if SANITIZER_X32
> +  // x32 siginfo_t is aligned to 8 bytes.
> +  u64 pad[128 / sizeof(u64)];
> +#else
>// Require uptr, because siginfo_t is always pointer-size aligned on Linux.
>uptr pad[128 / sizeof(uptr)];
> +#endif
>  };
>  
>  #if SANITIZER_LINUX



Re: [COMMITTED 3/5] Add sbr_lazy_vector and adjust (e)vrp sparse cache

2023-04-27 Thread Martin Liška
On 4/26/23 21:26, Andrew MacLeod via Gcc-patches wrote:
> This implements a sparse vector class for rangers cache and uses it bey 
> default except when the CFG is very small, in qhich case the original full 
> vectors are faster.  It works like a normal vector cache (in fact it inherits 
> from it), but uses a sparse bitmap to determine whether a vector element is 
> set or not.  This provide better performance for clearing the vector, as well 
> as during initialization.
> 
> A new param is added for this transition "vrp_vector_threshold" which 
> defaults to 250.  Anything function with fewer than 250 basic blocks will use 
> the simple vectors.  Various timing runs have indicated this is about the 
> sweet spot where using the sparse bitmap overtakes the time required to clear 
> the vector initially. Should we make ranger live across functions in the 
> future, we'll probably want to lower this value again as clearing is 
> significantly cheaper.
> 
> This patch also rename the "evrp_*" params to "vrp_*" as there really is not 
> a serperate EVRP pass any more, its all one vrp pass.   Eventually we'll 
> probably want to change it to vrp1, vrp2 and vrp3 rather than evrp, vrp1  and 
> vrp2.    But thats a task for later, perhaps when we reconsider pass 
> orderings..
> 
> Bootstrapped on x86_64-pc-linux-gnu with no regressions.  Pushed.
> 
> Andrew

Hello.

Please adjust also the documentation for the params in gcc/doc/invoke.texi.

Thanks,
Martin


Re: libsanitizer: sync from master

2023-04-26 Thread Martin Liška
On 4/26/23 20:31, Florian Weimer wrote:
> * Martin Liška:
> 
>> On 11/15/22 16:47, Martin Liška wrote:
>>> Hi.
>>>
>>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>>> ppc64le-linux systems.
>>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>>> abidiff.
>>
>> Hello.
>>
>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
> 
> So … we have the issue that involves interceptors outside of libc.so.6,
> namely crypt, crypt_r, and I posted an upstream patch for this:
> 
>   sanitizers: Disable crypt, crypt_r interceptors for glibc
>   <https://reviews.llvm.org/D144073>
> 
> Can we just apply this downstream for now?  It blocks various folks from
> using the sanitizers in their projects.

Hello.

Your upstream revision has been already accepted, so please apply it and I'm 
going to do
one more merge from upstream in the following days. Does it work for you?

Cheers,
Martin

> 
> Thanks,
> Florian
> 



Re: libsanitizer: sync from master

2023-04-26 Thread Martin Liška
On 4/26/23 20:31, Florian Weimer wrote:
> * Martin Liška:
> 
>> On 11/15/22 16:47, Martin Liška wrote:
>>> Hi.
>>>
>>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>>> ppc64le-linux systems.
>>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>>> abidiff.
>>
>> Hello.
>>
>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
> 
> So … we have the issue that involves interceptors outside of libc.so.6,
> namely crypt, crypt_r, and I posted an upstream patch for this:
> 
>   sanitizers: Disable crypt, crypt_r interceptors for glibc
>   <https://reviews.llvm.org/D144073>
> 
> Can we just apply this downstream for now?  It blocks various folks from
> using the sanitizers in their projects.

Hello.

Your upstream revision has been already accepted, so please apply it and I'm 
going to do
one more merge from upstream in the following days. Does it work for you?

Cheers,
Martin

> 
> Thanks,
> Florian
> 



Re: libsanitizer: sync from master

2023-04-26 Thread Martin Liška
On 4/26/23 21:23, H.J. Lu wrote:
> On Wed, Apr 26, 2023 at 6:52 AM Martin Liška  wrote:
>>
>> On 11/15/22 16:47, Martin Liška wrote:
>>> Hi.
>>>
>>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>>> ppc64le-linux systems.
>>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>>> abidiff.
>>
>> Hello.
>>
>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
> 
> It caused the bootstrap failure:
> 
> https://gcc.gnu.org/pipermail/gcc-regression/2023-April/077674.html

Can you see what's the build error in the build log? I can't see it from the
sent link?

Martin

> 
>> Martin
>>
>>>
>>> Pushed as r13-4068-g3037f11fb86eda.
>>>
>>> Cheers,
>>> Martin
>>
> 
> 



Re: libsanitizer: sync from master

2023-04-26 Thread Martin Liška
On 4/26/23 21:23, H.J. Lu wrote:
> On Wed, Apr 26, 2023 at 6:52 AM Martin Liška  wrote:
>>
>> On 11/15/22 16:47, Martin Liška wrote:
>>> Hi.
>>>
>>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>>> ppc64le-linux systems.
>>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>>> abidiff.
>>
>> Hello.
>>
>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
> 
> It caused the bootstrap failure:
> 
> https://gcc.gnu.org/pipermail/gcc-regression/2023-April/077674.html

Can you see what's the build error in the build log? I can't see it from the
sent link?

Martin

> 
>> Martin
>>
>>>
>>> Pushed as r13-4068-g3037f11fb86eda.
>>>
>>> Cheers,
>>> Martin
>>
> 
> 



Re: libsanitizer: sync from master

2023-04-26 Thread Martin Liška
On 11/15/22 16:47, Martin Liška wrote:
> Hi.
> 
> I've just pushed libsanitizer update that was tested on x86_64-linux and 
> ppc64le-linux systems.
> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
> abidiff.

Hello.

And I've done the same now and merged upstream version 3185e47b5a8444e9fd.

Martin

> 
> Pushed as r13-4068-g3037f11fb86eda.
> 
> Cheers,
> Martin



Re: libsanitizer: sync from master

2023-04-26 Thread Martin Liška
On 11/15/22 16:47, Martin Liška wrote:
> Hi.
> 
> I've just pushed libsanitizer update that was tested on x86_64-linux and 
> ppc64le-linux systems.
> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
> abidiff.

Hello.

And I've done the same now and merged upstream version 3185e47b5a8444e9fd.

Martin

> 
> Pushed as r13-4068-g3037f11fb86eda.
> 
> Cheers,
> Martin



Re: [PATCH] gcov: add info about "calls" to JSON output format

2023-04-25 Thread Martin Liška
On 4/14/23 14:34, Jan Hubicka wrote:
>> On 4/11/23 11:23, Richard Biener wrote:
>>> On Thu, Apr 6, 2023 at 3:58 PM Martin Liška  wrote:
>>>>
>>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>>
>>>> Ready to be installed after stage1 opens?
>>>
>>> Did we release a compiler with version 1?  If not we might want to sneak
>>
>> Yes, all compilers starting with 9.1 emit version 1.
>>
>>> this in before 13.1 ...
>>
>> Yep, I would welcome sneaking in.
>>
>>>
>>> Up to Honza.
>>
>> PING: Honza!
> 
> THe motivation is for external tools to effectively track execution
> counts after function calls that does not return normally?

Yes, they wanted basically equal information as we present in the human-readable
format.

> What about other cases we produce fake edges for, like trapping
> statements or volatile asms (via stmt_can_terminate_bb_p). Are those
> handled as branches with "throw" flag?

That's probably something for future. There was not demand for it right now.

> 
> Calls not returning is just one of special cases where control of
> function may terminate.  Also do we want to handle function returning
> twice (fork and setjmp?)

Similarly here.

Anyway, I'm going to commit a bit enhanced version where I:
- added blocks_ids for each line number
- for each branch and call source and destination block is added
- in human-readable format I change block::index to block::id as the
  index does not makes sense much

Martin

> 
> Patch looks OK.
> Honza
>>
>> Thanks,
>> Martin
>>
>>>
>>> Thanks,
>>> Richard.
>>>
>>>> Thanks,
>>>> Martin
>>>>
>>>> gcc/ChangeLog:
>>>>
>>>> * doc/gcov.texi: Document the new "calls" field and document
>>>> the API bump.
>>>> * gcov.cc (output_intermediate_json_line): Output info about
>>>> calls.
>>>> (generate_results): Bump version to 2.
>>>>
>>>> gcc/testsuite/ChangeLog:
>>>>
>>>> * g++.dg/gcov/gcov-17.C: Add call to a noreturn function.
>>>> * g++.dg/gcov/test-gcov-17.py: Cover new format.
>>>> * lib/gcov.exp: Add options for gcov that emit the extra info.
>>>> ---
>>>>  gcc/doc/gcov.texi | 27 +--
>>>>  gcc/gcov.cc   | 12 +-
>>>>  gcc/testsuite/g++.dg/gcov/gcov-17.C   |  7 ++
>>>>  gcc/testsuite/g++.dg/gcov/test-gcov-17.py | 17 ++
>>>>  gcc/testsuite/lib/gcov.exp|  2 +-
>>>>  5 files changed, 57 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
>>>> index d39cce3a683..6739ebb3643 100644
>>>> --- a/gcc/doc/gcov.texi
>>>> +++ b/gcc/doc/gcov.texi
>>>> @@ -195,7 +195,7 @@ Structure of the JSON is following:
>>>>  @{
>>>>"current_working_directory": "foo/bar",
>>>>"data_file": "a.out",
>>>> -  "format_version": "1",
>>>> +  "format_version": "2",
>>>>"gcc_version": "11.1.1 20210510"
>>>>"files": ["$file"]
>>>>  @}
>>>> @@ -214,6 +214,12 @@ a compilation unit was compiled
>>>>  @item
>>>>  @var{format_version}: semantic version of the format
>>>>
>>>> +Changes in version @emph{2}:
>>>> +@itemize @bullet
>>>> +@item
>>>> +@var{calls}: information about function calls is added
>>>> +@end itemize
>>>> +
>>>>  @item
>>>>  @var{gcc_version}: version of the GCC compiler
>>>>  @end itemize
>>>> @@ -292,6 +298,7 @@ Each @var{line} has the following form:
>>>>  @smallexample
>>>>  @{
>>>>"branches": ["$branch"],
>>>> +  "calls": ["$call"],
>>>>"count": 2,
>>>>"line_number": 15,
>>>>"unexecuted_block": false,
>>>> @@ -299,7 +306,7 @@ Each @var{line} has the following form:
>>>>  @}
>>>>  @end smallexample
>>>>
>>>> -Branches are present only with @var{-b} option.
>>>> +Branches and calls are present only

[PATCH (pushed)] MAINTAINERS: fix sorting of names

2023-04-24 Thread Martin Liška

ChangeLog:

* MAINTAINERS: Fix sorting.
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8822d9642f7..b76e1a131d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -319,6 +319,7 @@ from other maintainers or reviewers.
Write After Approval(last name alphabetical order)
 
 Mark G. Adams	

+Ajit Kumar Agarwal 
 Pedro Alves
 Paul-Antoine Arras 
 Arsen Arsenović
@@ -474,7 +475,6 @@ Andreas Jaeger  

 Harsha Jagasia 
 Fariborz Jahanian  
 Surya Kumari Jangala   
-Ajit Kumar Agarwal 
 Haochen Jiang  
 Qian Jianhua   
 Janis Johnson  
--
2.40.0



[PATCH (pushed)] ada: bump Library_Version to 14.

2023-04-17 Thread Martin Liška

gcc/ada/ChangeLog:

* gnatvsn.ads: Bump Library_Version to 14.
---
 gcc/ada/gnatvsn.ads | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ada/gnatvsn.ads b/gcc/ada/gnatvsn.ads
index b6edc9dabed..a0e61e1b189 100644
--- a/gcc/ada/gnatvsn.ads
+++ b/gcc/ada/gnatvsn.ads
@@ -32,7 +32,7 @@ package Gnatvsn is
--  Static string identifying this version, that can be used as an argument
--  to e.g. pragma Ident.
 
-   Library_Version : constant String := "13";

+   Library_Version : constant String := "14";
--  Library version. It needs to be updated whenever the major version
--  number is changed.
--
--
2.40.0



Re: [PATCH] gcov: add info about "calls" to JSON output format

2023-04-12 Thread Martin Liška
On 4/11/23 11:23, Richard Biener wrote:
> On Thu, Apr 6, 2023 at 3:58 PM Martin Liška  wrote:
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed after stage1 opens?
> 
> Did we release a compiler with version 1?  If not we might want to sneak

Yes, all compilers starting with 9.1 emit version 1.

> this in before 13.1 ...

Yep, I would welcome sneaking in.

> 
> Up to Honza.

PING: Honza!

Thanks,
Martin

> 
> Thanks,
> Richard.
> 
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>> * doc/gcov.texi: Document the new "calls" field and document
>> the API bump.
>> * gcov.cc (output_intermediate_json_line): Output info about
>> calls.
>> (generate_results): Bump version to 2.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * g++.dg/gcov/gcov-17.C: Add call to a noreturn function.
>> * g++.dg/gcov/test-gcov-17.py: Cover new format.
>> * lib/gcov.exp: Add options for gcov that emit the extra info.
>> ---
>>  gcc/doc/gcov.texi | 27 +--
>>  gcc/gcov.cc   | 12 +-
>>  gcc/testsuite/g++.dg/gcov/gcov-17.C   |  7 ++
>>  gcc/testsuite/g++.dg/gcov/test-gcov-17.py | 17 ++
>>  gcc/testsuite/lib/gcov.exp|  2 +-
>>  5 files changed, 57 insertions(+), 8 deletions(-)
>>
>> diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
>> index d39cce3a683..6739ebb3643 100644
>> --- a/gcc/doc/gcov.texi
>> +++ b/gcc/doc/gcov.texi
>> @@ -195,7 +195,7 @@ Structure of the JSON is following:
>>  @{
>>"current_working_directory": "foo/bar",
>>"data_file": "a.out",
>> -  "format_version": "1",
>> +  "format_version": "2",
>>"gcc_version": "11.1.1 20210510"
>>"files": ["$file"]
>>  @}
>> @@ -214,6 +214,12 @@ a compilation unit was compiled
>>  @item
>>  @var{format_version}: semantic version of the format
>>
>> +Changes in version @emph{2}:
>> +@itemize @bullet
>> +@item
>> +@var{calls}: information about function calls is added
>> +@end itemize
>> +
>>  @item
>>  @var{gcc_version}: version of the GCC compiler
>>  @end itemize
>> @@ -292,6 +298,7 @@ Each @var{line} has the following form:
>>  @smallexample
>>  @{
>>"branches": ["$branch"],
>> +  "calls": ["$call"],
>>"count": 2,
>>"line_number": 15,
>>"unexecuted_block": false,
>> @@ -299,7 +306,7 @@ Each @var{line} has the following form:
>>  @}
>>  @end smallexample
>>
>> -Branches are present only with @var{-b} option.
>> +Branches and calls are present only with @var{-b} option.
>>  Fields of the @var{line} element have following semantics:
>>
>>  @itemize @bullet
>> @@ -341,6 +348,22 @@ Fields of the @var{branch} element have following 
>> semantics:
>>  @var{throw}: true when the branch is an exceptional branch
>>  @end itemize
>>
>> +Each @var{call} has the following form:
>> +
>> +@smallexample
>> +@{
>> +  "returned": 11,
>> +@}
>> +@end smallexample
>> +
>> +Fields of the @var{call} element have following semantics:
>> +
>> +@itemize @bullet
>> +@item
>> +@var{returned}: number of times a function call returned (call count is 
>> equal
>> +to @var{line::count})
>> +@end itemize
>> +
>>  @item -H
>>  @itemx --human-readable
>>  Write counts in human readable format (like 24.6k).
>> diff --git a/gcc/gcov.cc b/gcc/gcov.cc
>> index 2ec7248cc0e..88324143640 100644
>> --- a/gcc/gcov.cc
>> +++ b/gcc/gcov.cc
>> @@ -1116,6 +1116,9 @@ output_intermediate_json_line (json::array *object,
>>json::array *branches = new json::array ();
>>lineo->set ("branches", branches);
>>
>> +  json::array *calls = new json::array ();
>> +  lineo->set ("calls", calls);
>> +
>>vector::const_iterator it;
>>if (flag_branches)
>>  for (it = line->branches.begin (); it != line->branches.end ();
>> @@ -1130,6 +1133,13 @@ output_intermediate_json_line (json::array *object,
>>  new json::literal ((*it)->fall_through));
>> branches->append (branch);
>>   }
>> +

[PATCH] gcov: add info about "calls" to JSON output format

2023-04-06 Thread Martin Liška
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed after stage1 opens?

Thanks,
Martin

gcc/ChangeLog:

* doc/gcov.texi: Document the new "calls" field and document
the API bump.
* gcov.cc (output_intermediate_json_line): Output info about
calls.
(generate_results): Bump version to 2.

gcc/testsuite/ChangeLog:

* g++.dg/gcov/gcov-17.C: Add call to a noreturn function.
* g++.dg/gcov/test-gcov-17.py: Cover new format.
* lib/gcov.exp: Add options for gcov that emit the extra info.
---
 gcc/doc/gcov.texi | 27 +--
 gcc/gcov.cc   | 12 +-
 gcc/testsuite/g++.dg/gcov/gcov-17.C   |  7 ++
 gcc/testsuite/g++.dg/gcov/test-gcov-17.py | 17 ++
 gcc/testsuite/lib/gcov.exp|  2 +-
 5 files changed, 57 insertions(+), 8 deletions(-)

diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index d39cce3a683..6739ebb3643 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -195,7 +195,7 @@ Structure of the JSON is following:
 @{
   "current_working_directory": "foo/bar",
   "data_file": "a.out",
-  "format_version": "1",
+  "format_version": "2",
   "gcc_version": "11.1.1 20210510"
   "files": ["$file"]
 @}
@@ -214,6 +214,12 @@ a compilation unit was compiled
 @item
 @var{format_version}: semantic version of the format
 
+Changes in version @emph{2}:
+@itemize @bullet
+@item
+@var{calls}: information about function calls is added
+@end itemize
+
 @item
 @var{gcc_version}: version of the GCC compiler
 @end itemize
@@ -292,6 +298,7 @@ Each @var{line} has the following form:
 @smallexample
 @{
   "branches": ["$branch"],
+  "calls": ["$call"],
   "count": 2,
   "line_number": 15,
   "unexecuted_block": false,
@@ -299,7 +306,7 @@ Each @var{line} has the following form:
 @}
 @end smallexample
 
-Branches are present only with @var{-b} option.
+Branches and calls are present only with @var{-b} option.
 Fields of the @var{line} element have following semantics:
 
 @itemize @bullet
@@ -341,6 +348,22 @@ Fields of the @var{branch} element have following 
semantics:
 @var{throw}: true when the branch is an exceptional branch
 @end itemize
 
+Each @var{call} has the following form:
+
+@smallexample
+@{
+  "returned": 11,
+@}
+@end smallexample
+
+Fields of the @var{call} element have following semantics:
+
+@itemize @bullet
+@item
+@var{returned}: number of times a function call returned (call count is equal
+to @var{line::count})
+@end itemize
+
 @item -H
 @itemx --human-readable
 Write counts in human readable format (like 24.6k).
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 2ec7248cc0e..88324143640 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -1116,6 +1116,9 @@ output_intermediate_json_line (json::array *object,
   json::array *branches = new json::array ();
   lineo->set ("branches", branches);
 
+  json::array *calls = new json::array ();
+  lineo->set ("calls", calls);
+
   vector::const_iterator it;
   if (flag_branches)
 for (it = line->branches.begin (); it != line->branches.end ();
@@ -1130,6 +1133,13 @@ output_intermediate_json_line (json::array *object,
 new json::literal ((*it)->fall_through));
branches->append (branch);
  }
+   else if ((*it)->is_call_non_return)
+ {
+   json::object *call = new json::object ();
+   gcov_type returns = (*it)->src->count - (*it)->count;
+   call->set ("returned", new json::integer_number (returns));
+   calls->append (call);
+ }
   }
 
   object->append (lineo);
@@ -1523,7 +1533,7 @@ generate_results (const char *file_name)
   gcov_intermediate_filename = get_gcov_intermediate_filename (file_name);
 
   json::object *root = new json::object ();
-  root->set ("format_version", new json::string ("1"));
+  root->set ("format_version", new json::string ("2"));
   root->set ("gcc_version", new json::string (version_string));
 
   if (bbg_cwd != NULL)
diff --git a/gcc/testsuite/g++.dg/gcov/gcov-17.C 
b/gcc/testsuite/g++.dg/gcov/gcov-17.C
index d11883cfd39..efe019599a5 100644
--- a/gcc/testsuite/g++.dg/gcov/gcov-17.C
+++ b/gcc/testsuite/g++.dg/gcov/gcov-17.C
@@ -15,6 +15,11 @@ private:
 template class Foo;
 template class Foo;
 
+static void noret()
+{
+  __builtin_exit (0);
+}
+
 int
 main (void)
 {
@@ -34,6 +39,8 @@ main (void)
 __builtin_printf ("Failure\n");
   else
 __builtin_printf ("Success\n");
+
+  noret ();
   return 0;
 }
 
diff --git a/gcc/testsuite/g++.dg/gcov/test-gcov-17.py 
b/gcc/testsuite/g++.dg/gcov/test-gcov-17.py
index ec5df3dec03..a0b8b09b85c 100644
--- a/gcc/testsuite/g++.dg/gcov/test-gcov-17.py
+++ b/gcc/testsuite/g++.dg/gcov/test-gcov-17.py
@@ -12,7 +12,7 @@ def test_basics(gcov):
 files = gcov['files']
 assert len(files) == 1
 functions = files[0]['functions']
-assert len(functions) == 5
+assert len(functions) == 6
 
 
 def 

[PATCH] ipa: propagate attributes for target attribute clones

2023-04-03 Thread Martin Liška

Hi.

The patch propagates noreturn attribute for MV functions. However, I noticed
we've got the following ICE when we do the same for TREE_READONLY attr:

$ cat tc.c
double bar() __attribute__((target_clones("avx,avx2,avx512f,default")));
double bar() { return 1.2f; }

int foo() { return (int)bar(); }

$ ./xgcc -B. ~/Programming/testcases/tc.c -O3 -c -fprofile-generate
/home/marxin/Programming/testcases/tc.c: In function ‘foo’:
/home/marxin/Programming/testcases/tc.c:4:5: error: virtual definition of 
statement not up to date
4 | int foo() { return (int)bar(); }
  | ^~~
_1 = bar ();
during GIMPLE pass: fixup_cfg

Thus my ambition is to propagate only noreturn attr.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR ipa/106816

gcc/ChangeLog:

* config/i386/i386-features.cc (ix86_get_function_versions_dispatcher):
Propagate function attributes for clones.

gcc/testsuite/ChangeLog:

* g++.target/i386/pr106816.C: New test.

Co-Authored-By: H.J. Lu 
---
 gcc/config/i386/i386-features.cc |  1 +
 gcc/testsuite/g++.target/i386/pr106816.C | 23 +++
 2 files changed, 24 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/i386/pr106816.C

diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc
index c09abf8fc20..f2b0d59a73c 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -3379,6 +3379,7 @@ ix86_get_function_versions_dispatcher (void *decl)
   /* Right now, the dispatching is done via ifunc.  */
   dispatch_decl = make_dispatcher_decl (default_node->decl);
   TREE_NOTHROW (dispatch_decl) = TREE_NOTHROW (fn);
+  TREE_THIS_VOLATILE (dispatch_decl) = TREE_THIS_VOLATILE (fn);
 
   dispatcher_node = cgraph_node::get_create (dispatch_decl);

   gcc_assert (dispatcher_node != NULL);
diff --git a/gcc/testsuite/g++.target/i386/pr106816.C 
b/gcc/testsuite/g++.target/i386/pr106816.C
new file mode 100644
index 000..0f5cc1f13dd
--- /dev/null
+++ b/gcc/testsuite/g++.target/i386/pr106816.C
@@ -0,0 +1,23 @@
+// PR ipa/106816
+
+// { dg-do compile }
+// { dg-require-ifunc "" }
+// { dg-options "-O2 -fdump-tree-optimized" }
+
+__attribute__((noreturn, target("default"))) void f()
+{
+  for (;;) {}
+}
+
+__attribute__((noreturn, target("sse4.2,bmi"))) void f()
+{
+  for (;;) {}
+}
+
+int main()
+{
+  f();
+  return 12345;
+}
+
+/* { dg-final { scan-tree-dump-not "12345" "optimized" } } */
--
2.40.0



[PATCH][stage1] gcov: respect -fprofile-prefix-map when it comes to output of .gcda file

2023-04-03 Thread Martin Liška

Respect the profile prefix map and save .gcda files to a path that is
also translated with -fprofile-prefix-map option (if provided).

It's a stage 1 material, if you are interested in the fix, please install it,
I won't be able to take care of it at that time.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Thanks,
Martin

PR gcov-profile/105063

gcc/ChangeLog:

* coverage.cc (coverage_init): Combine strings with concat and
respect profile path mapping.
---
 gcc/coverage.cc | 24 +++-
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/gcc/coverage.cc b/gcc/coverage.cc
index 7ed3a5d4ceb..3fd7f6e8e76 100644
--- a/gcc/coverage.cc
+++ b/gcc/coverage.cc
@@ -112,7 +112,7 @@ static char *bbg_file_name;
 static unsigned bbg_file_stamp;
 
 /* Name of the count data (gcda) file.  */

-static char *da_file_name;
+static const char *da_file_name;
 
 /* The names of merge functions for counters.  */

 #define STR(str) #str
@@ -1259,8 +1259,6 @@ coverage_init (const char *filename)
 #else
   const char *separator = "/";
 #endif
-  int len = strlen (filename);
-  int prefix_len = 0;
 
   /* Since coverage_init is invoked very early, before the pass

  manager, we need to set up the dumping explicitly. This is
@@ -1289,26 +1287,19 @@ coverage_init (const char *filename)
 "prefix %qs", filename, profile_prefix_path);
}
  filename = mangle_path (filename);
- len = strlen (filename);
}
   else
profile_data_prefix = getpwd ();
 }
 
-  if (profile_data_prefix)

-prefix_len = strlen (profile_data_prefix);
-
   /* Name of da file.  */
-  da_file_name = XNEWVEC (char, len + strlen (GCOV_DATA_SUFFIX)
- + prefix_len + 2);
-
   if (profile_data_prefix)
-{
-  memcpy (da_file_name, profile_data_prefix, prefix_len);
-  da_file_name[prefix_len++] = *separator;
-}
-  memcpy (da_file_name + prefix_len, filename, len);
-  strcpy (da_file_name + prefix_len + len, GCOV_DATA_SUFFIX);
+da_file_name = concat (profile_data_prefix, separator, filename,
+  GCOV_DATA_SUFFIX, NULL);
+  else
+da_file_name = concat (filename, GCOV_DATA_SUFFIX, NULL);
+
+  da_file_name = remap_profile_filename (da_file_name);
 
   bbg_file_stamp = local_tick;

   if (flag_auto_profile)
@@ -1385,7 +1376,6 @@ coverage_finish (void)
   coverage_obj_finish (fn_ctor, object_checksum);
 }
 
-  XDELETEVEC (da_file_name);

   da_file_name = NULL;
 }
 
--

2.40.0



[PATCH] driver: drop flag_var_tracking_assignments flag

2023-04-03 Thread Martin Liška

The revision r13-259-g76db543db88727 moved a condition from one
file to another, but now we do not drop x_flag_var_tracking_assignments
as it was done before the mentioned revision.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR driver/108241

gcc/ChangeLog:

* opts.cc (finish_options): Drop also
  x_flag_var_tracking_assignments.

gcc/testsuite/ChangeLog:

* gcc.dg/pr108241.c: New test.
* gcc.dg/pr79570.c: Add also -g option.
---
 gcc/opts.cc |  1 +
 gcc/testsuite/gcc.dg/pr108241.c | 63 +
 gcc/testsuite/gcc.dg/pr79570.c  |  2 +-
 3 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr108241.c

diff --git a/gcc/opts.cc b/gcc/opts.cc
index f102c1328b9..fb2e5388ab1 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -1384,6 +1384,7 @@ finish_options (struct gcc_options *opts, struct 
gcc_options *opts_set,
}
   opts->x_flag_var_tracking = 0;
   opts->x_flag_var_tracking_uninit = 0;
+  opts->x_flag_var_tracking_assignments = 0;
 }
 
   /* One could use EnabledBy, but it would lead to a circular dependency.  */

diff --git a/gcc/testsuite/gcc.dg/pr108241.c b/gcc/testsuite/gcc.dg/pr108241.c
new file mode 100644
index 000..06d210fae68
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108241.c
@@ -0,0 +1,63 @@
+/* PR driver/108241 */
+/* { dg-options "-Os -frounding-math -fvar-tracking-assignments -fno-dce 
-fno-trapping-math -fno-tree-dce -fno-tree-dse" } */
+
+long int n1;
+int n2, n3, n4;
+char n5;
+
+void
+foo (long int x1, long int x2, int x3, int x4, int x5, char x6, char x7)
+{
+  char a01 = n2, a02 = x4, a03 = 0;
+  short int a04;
+  unsigned short int a05 = x5;
+  int a06, a07, a08 = a05, a09 = x3, a10 = 0;
+  long int a11, a12 = x4;
+
+  if (x1)
+{
+  a07 = x6 + (float)0x101;
+  a03 = a12 = a01 = a06 = ~0;
+
+  if (x5)
+   a11 = n5;
+}
+  else
+{
+  a10 = x3 = n3;
+  if (n3)
+   a06 = a05 = x7;
+}
+
+  if (n3 < n5)
+{
+  n4 = (x2 == x4) + !n1;
+  if (n4 % (n1 % x3))
+   {
+ a04 = n4;
+ a02 = n2;
+   }
+
+  if (x3)
+   {
+ a05 = !n1 % n2;
+ a08 = n1;
+ a04 = x5 + a06;
+   }
+
+  if (a12)
+   a09 = n3 + n4;
+
+  a12 = a07;
+  n3 = a11 % x1;
+  n5 += x6;
+  n1 = a04;
+}
+
+  n4 = x2 % x5 % a11;
+  a06 = a10 + a08 % a02 == n4;
+  a09 = a09 == a01 * x7;
+  n4 = x4;
+  a12 += x4 / 0xc000 + !a03;
+  a03 = !a05;
+}
diff --git a/gcc/testsuite/gcc.dg/pr79570.c b/gcc/testsuite/gcc.dg/pr79570.c
index 00841b9487a..a15be9f201d 100644
--- a/gcc/testsuite/gcc.dg/pr79570.c
+++ b/gcc/testsuite/gcc.dg/pr79570.c
@@ -1,6 +1,6 @@
 /* PR target/79570 */
 /* { dg-do compile { target powerpc*-*-* ia64-*-* i?86-*-* x86_64-*-* } } */
-/* { dg-options "-O2 -fselective-scheduling2 -fvar-tracking-assignments" } */
+/* { dg-options "-O2 -fselective-scheduling2 -fvar-tracking-assignments -g" } 
*/
 /* { dg-warning "changes selective scheduling" "" { target *-*-* } 0 } */
 
 #include "pr69956.c"

--
2.40.0



[PATCH (pushed)] param: document ranger-recompute-depth

2023-04-03 Thread Martin Liška

gcc/ChangeLog:

* doc/invoke.texi: Document new param.
---
 gcc/doc/invoke.texi | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index def2df4584b..c9482886c5a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -16170,6 +16170,10 @@ per supernode, before terminating analysis.
 Maximum depth of logical expression evaluation ranger will look through
 when evaluating outgoing edge ranges.
 
+@item ranger-recompute-depth

+Maximum depth of instruction chains to consider for recomputation
+in the outgoing range calculator.
+
 @item relation-block-limit
 Maximum number of relations the oracle will register in a basic block.
 
--

2.40.0



Re: [PATCH] configure: deprecate --enable-link-mutex option

2023-03-29 Thread Martin Liška
On 3/29/23 15:05, Richard Biener wrote:
> I wonder if we can simply alias --enable-link-mutex to
> --enable-link-serialization though.

Sure, we can. Do you want it for gcc-13 as well?

Cheers,
Martin


Re: [PATCH] configure: deprecate --enable-link-mutex option

2023-03-29 Thread Martin Liška
On 3/29/23 15:02, Andreas Schwab wrote:
> On Mär 29 2023, Martin Liška wrote:
> 
>> diff --git a/gcc/configure.ac b/gcc/configure.ac
>> index 120151c474a..13c1a85851c 100644
>> --- a/gcc/configure.ac
>> +++ b/gcc/configure.ac
>> @@ -7013,6 +7013,7 @@ AC_MSG_RESULT($do_link_mutex)
>>  
>>  if test "$do_link_mutex" = "yes"; then
>> DO_LINK_MUTEX=true
>> +   echo gcc/configure: WARNING: --enable-link-mutex is deprecated and will 
>> be removed in the next release, use --enable-link-serialization instead 1>&2
> 
> Please use AC_MSG_WARN.
> 

Good point Andreas, installed as 8b2766e87db.

Thanks,
Martin


[PATCH] configure: deprecate --enable-link-mutex option

2023-03-29 Thread Martin Liška
Ready to be installed?
Thanks,
Martin

PR bootstrap/109310

gcc/ChangeLog:

* configure.ac: Emit a warning for deprecated option
--enable-link-mutex.
* configure: Regenerate.
---
 gcc/configure| 1 +
 gcc/configure.ac | 1 +
 2 files changed, 2 insertions(+)

diff --git a/gcc/configure b/gcc/configure
index 15086578533..09ae93ade1a 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -31468,6 +31468,7 @@ $as_echo "$do_link_mutex" >&6; }
 
 if test "$do_link_mutex" = "yes"; then
DO_LINK_MUTEX=true
+   echo gcc/configure: WARNING: --enable-link-mutex is deprecated and will be 
removed in the next release, use --enable-link-serialization instead 1>&2
 else
DO_LINK_MUTEX=false
 fi
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 120151c474a..13c1a85851c 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -7013,6 +7013,7 @@ AC_MSG_RESULT($do_link_mutex)
 
 if test "$do_link_mutex" = "yes"; then
DO_LINK_MUTEX=true
+   echo gcc/configure: WARNING: --enable-link-mutex is deprecated and will be 
removed in the next release, use --enable-link-serialization instead 1>&2
 else
DO_LINK_MUTEX=false
 fi
-- 
2.40.0



[PATCH (pushed)] fix: pytest error

2023-03-27 Thread Martin Liška
Fixes:
gcc/testsuite/lib/verify-sarif-file.py:10:27: Q000 Double quotes found but 
single quotes preferred

gcc/testsuite/ChangeLog:

* lib/verify-sarif-file.py: Use apostrophes instead
of double quotes.
---
 gcc/testsuite/lib/verify-sarif-file.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/verify-sarif-file.py 
b/gcc/testsuite/lib/verify-sarif-file.py
index f1833f3016e..eb6236f564c 100644
--- a/gcc/testsuite/lib/verify-sarif-file.py
+++ b/gcc/testsuite/lib/verify-sarif-file.py
@@ -7,5 +7,5 @@ import sys
 sys.tracebacklimit = 0
 
 fname = sys.argv[1]
-with open(fname, encoding="utf-8") as f:
+with open(fname, encoding='utf-8') as f:
 json.load(f)
-- 
2.40.0



Re: [PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file

2023-03-16 Thread Martin Liška
PING^5

On 2/27/23 10:49, Martin Liška wrote:
> PING^4
> 
> On 2/17/23 15:52, Martin Liška wrote:
>> PING^3
>>
>> On 2/1/23 14:13, Martin Liška wrote:
>>> PING^2
>>>
>>> On 1/24/23 14:34, Martin Liška wrote:
>>>> PING^1
>>>>
>>>> On 1/10/23 16:10, Martin Liška wrote:
>>>>> On 1/6/23 14:21, David Malcolm wrote:
>>>>>> On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:
>>>>>>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>>>>>>> tests.
>>>>>>
>>>>>> Thanks for the patch.
>>>>>>
>>>>>> I noticed that you marked PR 108307 as a dup of this, which covers
>>>>>> -fdiagnostics-format=sarif-file (and a .S file as input).
>>>>>>
>>>>>> The patch doesn't add any test coverage (for either of the diagnostic
>>>>>> formats).
>>>>>>
>>>>>> If we try to emit a diagnostic and base_file_name is NULL, and the user
>>>>>> requested one of -fdiagnostics-format={json,sarif}-file, where do the
>>>>>> diagnostics go?  Where should they go?
>>>>>
>>>>> Hey.
>>>>>
>>>>> I've done a new version of the patch where I utilize 
>>>>> x_main_input_basename.
>>>>>
>>>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>>>
>>>>> Ready to be installed?
>>>>> Thanks,
>>>>> Martin
>>>>
>>>
>>
> 



Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores

2023-03-08 Thread Martin Liška
On 3/3/23 12:12, Richard Biener via Gcc-patches wrote:
> On Fri, Mar 3, 2023 at 9:30 AM Alexandre Oliva  wrote:
>>
>> On Feb 17, 2023, Richard Biener  wrote:
>>
 * gimple-ssa-warn-access.cc
 (pass_waccess::check_dangling_stores): Skip non-stores.

 for  gcc/testsuite/ChangeLog

 * g++.dg/warn/Wdangling-pointer.C (warn_init_ref_member): Add
 two new variants, one fixed, one xfailed.
 * c-c++-common/Wdangling-pointer-5.c
 (nowarn_store_arg_store_arg): Add now-expected warnings.
>>
>> Ping?
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612186.html
> 
> I was hoping Martin would chime in, but he didn't.
> 
> So - OK.
> 
> Thanks,
> Richard.
> 
>>
>> --
>> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>>Free Software Activist   GNU Toolchain Engineer
>> Disinformation flourishes because many people care deeply about injustice
>> but very few check the facts.  Ask me about 

Hi.

I've just noticed this change triggered one more warning for qemu 7.1.0:

cc -m64 -mcx16 -Ilibqemuutil.a.p -I. -I.. -Isubprojects/libvhost-user 
-I../subprojects/libvhost-user -Iqapi -Itrace -Iui -Iui/shader 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/p11-kit-1 
-I/usr/include/pixman-1 -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror 
-std=gnu11 -O2 -isystem /home/abuild/rpmbuild/BUILD/qemu-7.1.0/linux-headers 
-isystem linux-headers -iquote . -iquote /home/abuild/rpmbuild/BUILD/qemu-7.1.0 
-iquote /home/abuild/rpmbuild/BUILD/qemu-7.1.0/include -iquote 
/home/abuild/rpmbuild/BUILD/qemu-7.1.0/tcg/i386 -pthread -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration 
-Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels 
-Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs 
-Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -O2 -Wall 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fstack-clash-protection -Werror=return-type -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=2 -fPIE -MD -MQ libqemuutil.a.p/util_async.c.o -MF 
libqemuutil.a.p/util_async.c.o.d -o libqemuutil.a.p/util_async.c.o -c 
../util/async.c
In file included from 
/home/abuild/rpmbuild/BUILD/qemu-7.1.0/include/qemu/coroutine.h:18,
 from 
/home/abuild/rpmbuild/BUILD/qemu-7.1.0/include/block/aio.h:20,
 from ../util/async.c:28:
../util/async.c: In function 'aio_bh_poll':
/home/abuild/rpmbuild/BUILD/qemu-7.1.0/include/qemu/queue.h:303:22: error: 
storing the address of local variable 'slice' in '*ctx.bh_slice_list.sqh_last' 
[-Werror=dangling-pointer=]
  303 | (head)->sqh_last = &(elm)->field.sqe_next;  
\
  | ~^~~~
../util/async.c:161:5: note: in expansion of macro 'QSIMPLEQ_INSERT_TAIL'
  161 | QSIMPLEQ_INSERT_TAIL(>bh_slice_list, , next);
  | ^~~~
../util/async.c:156:17: note: 'slice' declared here
  156 | BHListSlice slice;
  | ^
../util/async.c:156:17: note: 'ctx' declared here

which I reduced to:

$ cat util_async.i
typedef struct BHListSlice BHListSlice;
struct BHListSlice {
  struct {
BHListSlice *sqe_next;
  } next;
} *aio_bh_poll_s;
struct AioContext {
  struct {
BHListSlice *sqh_first;
BHListSlice **sqh_last;
  } bh_slice_list;
} aio_bh_dequeue();
int aio_bh_poll_bh;
int aio_bh_poll(struct AioContext *ctx) {
  BHListSlice slice;
  (>bh_slice_list)->sqh_last = &(slice.next.sqe_next);
  while (aio_bh_poll_s) {
unsigned flags;
aio_bh_dequeue();
if (aio_bh_poll_bh) {
  (>bh_slice_list)->sqh_last = &(>bh_slice_list)->sqh_first;
  continue;
}
  }
  return 0;
}

$ gcc util_async.i -c -Werror=dangling-pointer
util_async.i: In function ‘aio_bh_poll’:
util_async.i:16:35: error: storing the address of local variable ‘slice’ in 
‘*ctx.bh_slice_list.sqh_last’ [-Werror=dangling-pointer=]
   16 |   (>bh_slice_list)->sqh_last = &(slice.next.sqe_next);
  |   ^~~~
util_async.i:15:15: note: ‘slice’ declared here
   15 |   BHListSlice slice;
  |   ^
util_async.i:15:15: note: ‘ctx’ declared here
cc1: some warnings being treated as errors

Is the emitted warning correct?

Thank you,
Martin


Re: Stepping down as gcov maintainer and callgraph reviewer

2023-03-07 Thread Martin Liška
On 2/16/23 20:46, Jan Hubicka wrote:
> I am sad to hear this news and will definitely miss you as coleague
> and co-maintaner.  Thank you for all the work on GCC!

Thank you all for the nice words! And especially to Honza, who was my diploma
thesis supervisor and showed me the community.

Actually there's a funny story about the thesis: I was seeking for a topic for 
diploma thesis
somewhen in 2011 and so I wrote to Honza. And as we know Honza, he didn't reply 
in a couple
of weeks. However, as I was returning from a pub right before Christmas this 
year, I met him
near the university campus (Malostranske namesti) and I reminded him the email. 
He replied
and that's how it all began.

Life is full of wonderful moments of coincidence.

Martin

> 
> Honza



Re: Ping: [PATCH 1/2] testsuite: Provide means to regexp in multiline patterns

2023-03-07 Thread Martin Liška
On 3/7/23 01:32, Hans-Peter Nilsson wrote:
>> From: Mike Stump 
>> Date: Mon, 6 Mar 2023 02:05:35 -0800
> 
>> Ok
> 
> Thanks!  The server-side hook didn't like my ChangeLog
> entry:
> 
> * lib/multiline.exp (_build_multiline_regex): Map
> "{re:" to "(", ":re}" to ")" and ":re?}" to ")?".
> 
> It seems I forgot to validate that patch by
> contrib/gcc-changelog/git_check_commit.py, which complains:
> 
> Checking c0debd6f586ef76f1ceabfed11d7eaf8f6d1b110: FAILED
> ERR: bad wrapping of parenthesis: "   "{re:" to "(", ":re}" to ")" and 
> ":re?}" to ")?"."

Hello.

Yeah, that's quite interesting problem ;)


> 
> I gave in and took the easy way out; not fixing the bug in
> that script, but instead "wrapped the parenthesis" to:
> 
>   * lib/multiline.exp (_build_multiline_regex): Map
>   "{re:" to "(", similarly ")?" from ":re?}" and the
>   same without question mark.
> 
> I hope to make amends by fixing git_check_commit.py, if
> given guidance.

Sure, you can take a look at:
contrib/gcc-changelog/git_commit.py::process_parentheses
where we might want to skip the stack push/pop if the character is wrapper
in apostrophes or double quotes.

Martin

> 
> brgds, H-P



Re: [wwwdocs] gcc-13/porting_to.html: Document C++ -fexcess-precision=standard

2023-03-02 Thread Martin Liška
On 3/2/23 11:32, Jakub Jelinek wrote:
> Hi!
> 
> On Fri, Feb 10, 2023 at 10:06:03AM +0100, Gerald Pfeifer wrote:
>> Yes, thank you! Two minor suggestions/questions below:
>>
>>> --- a/htdocs/gcc-13/changes.html
>>> +++ b/htdocs/gcc-13/changes.html
>>> +  -fexcess-precision=fast.  The option affects mainly
>>
>> Here I'd say "mainly affects".
>>
>>> +  IA-32/x86-64 where when defaulting to x87 math and in some cases on
>>> +  Motorola 68000 float and double expressions
>>> +  are evaluated in long double precision and S/390, 
>>> System z,
>>> +  IBM z Systems where float expressions are evaluated in
>>> +  double precision.
>>
>> The "where when" part proved a bit tricky for my brain. :-) 
>>
>> I think it is precise, but am wondering whether
>>
>>   ...IA-32/x64 using x87 math and in some cases on Motorola 68000, where
>>   float and double expressions are evaluated...
>>
>> might work? What do you think?
> 
> Thanks, committed with those tweaks.
> 
> Martin would like to see some note in porting_to.html for it too,
> here is my attempt to do so:

I like the suggested wording. Thanks for it.

Martin

> 
> diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
> index 9a9a3147..5cbeefb6 100644
> --- a/htdocs/gcc-13/porting_to.html
> +++ b/htdocs/gcc-13/porting_to.html
> @@ -120,5 +120,29 @@ the operand as an lvalue.
> }
>  
>  
> +Excess precision changes
> +GCC 13 implements in C++ excess precision 
> support
> +which has been implemented just in the C front-end before.  The new behavior 
> is
> +enabled by default in -std=c++NN modes and when
> +FLT_EVAL_METHOD is 1 or 2 affects behavior of floating point
> +constants and expressions.  E.g. for FLT_EVAL_METHOD equal
> +to 2 on ia32:
> +
> +
> +#include 
> +void foo (void) { if (1.1f + 3.3f != 1.1L + 3.3L) abort (); }
> +void bar (void) { double d = 4.2; if (d == 4.2) abort (); }
> +
> +
> +will not abort with standard excess precision, because constants and 
> expressions
> +in float or double are evaluated in precision of
> +long double and demoted only on casts or assignments, but will
> +abort with fast excess precision, where whether something is evaluated in
> +precision of long double or not depends on what evaluations are
> +done in the i387 floating point stack or are spilled from it.
> +
> +The -fexcess-precision=fast option can be used to request the
> +previous behavior.
> +
>  
>  
> 
> 
>   Jakub
> 



Re: [PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file

2023-02-27 Thread Martin Liška

PING^4

On 2/17/23 15:52, Martin Liška wrote:

PING^3

On 2/1/23 14:13, Martin Liška wrote:

PING^2

On 1/24/23 14:34, Martin Liška wrote:

PING^1

On 1/10/23 16:10, Martin Liška wrote:

On 1/6/23 14:21, David Malcolm wrote:

On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:

Patch can bootstrap on x86_64-linux-gnu and survives regression
tests.


Thanks for the patch.

I noticed that you marked PR 108307 as a dup of this, which covers
-fdiagnostics-format=sarif-file (and a .S file as input).

The patch doesn't add any test coverage (for either of the diagnostic
formats).

If we try to emit a diagnostic and base_file_name is NULL, and the user
requested one of -fdiagnostics-format={json,sarif}-file, where do the
diagnostics go?  Where should they go?


Hey.

I've done a new version of the patch where I utilize x_main_input_basename.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin










Re: [PATCH] asan: adjust module name for global variables

2023-02-24 Thread Martin Liška
On 2/24/23 10:07, Jakub Jelinek wrote:
> On Fri, Feb 24, 2023 at 10:00:01AM +0100, Martin Liška wrote:
>> As mentioned in the PR, when we use LTO, we wrongly use ltrans output
>> file name as a module name of a global variable. That leads to a
>> non-reproducible output.
>>
>> After the suggested change, we emit context name of normal global
>> variables. And for artificial variables (like .Lubsan_data3), we use
>> aux_base_name (e.g. "./a.ltrans0.ltrans").
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>>
>>  PR asan/108834
>>
>> gcc/ChangeLog:
>>
>>  * asan.cc (asan_add_global): Use proper TU name for normal
>>global variables (and aux_base_name for the artificial one).
>>
>> gcc/testsuite/ChangeLog:
>>
>>  * c-c++-common/asan/global-overflow-1.c: Test line and column
>>  info for a global variable.
>> ---
>>  gcc/asan.cc | 7 ++-
>>  gcc/testsuite/c-c++-common/asan/global-overflow-1.c | 2 +-
>>  2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/gcc/asan.cc b/gcc/asan.cc
>> index f56d084bc7a..245abb14388 100644
>> --- a/gcc/asan.cc
>> +++ b/gcc/asan.cc
>> @@ -3287,7 +3287,12 @@ asan_add_global (tree decl, tree type, 
>> vec *v)
>>  pp_string (_pp, "");
>>str_cst = asan_pp_string (_pp);
>>  
>> -  pp_string (_name_pp, main_input_filename);
>> +  const_tree tu = get_ultimate_context ((const_tree)decl);
>> +  if (tu != NULL_TREE)
>> +pp_string (_name_pp, IDENTIFIER_POINTER (DECL_NAME (tu)));
>> +  else
>> +pp_string (_name_pp, aux_base_name);
> 
> I think for !in_lto_p we don't need to bother with get_ultimate_context
> and should just use main_input_filename as before.

All right, pushed with that change.

Thanks,
Martin

> 
> Otherwise LGTM.
> 
>   Jakub
> 



[PATCH] asan: adjust module name for global variables

2023-02-24 Thread Martin Liška
As mentioned in the PR, when we use LTO, we wrongly use ltrans output
file name as a module name of a global variable. That leads to a
non-reproducible output.

After the suggested change, we emit context name of normal global
variables. And for artificial variables (like .Lubsan_data3), we use
aux_base_name (e.g. "./a.ltrans0.ltrans").

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR asan/108834

gcc/ChangeLog:

* asan.cc (asan_add_global): Use proper TU name for normal
  global variables (and aux_base_name for the artificial one).

gcc/testsuite/ChangeLog:

* c-c++-common/asan/global-overflow-1.c: Test line and column
info for a global variable.
---
 gcc/asan.cc | 7 ++-
 gcc/testsuite/c-c++-common/asan/global-overflow-1.c | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/gcc/asan.cc b/gcc/asan.cc
index f56d084bc7a..245abb14388 100644
--- a/gcc/asan.cc
+++ b/gcc/asan.cc
@@ -3287,7 +3287,12 @@ asan_add_global (tree decl, tree type, 
vec *v)
 pp_string (_pp, "");
   str_cst = asan_pp_string (_pp);
 
-  pp_string (_name_pp, main_input_filename);
+  const_tree tu = get_ultimate_context ((const_tree)decl);
+  if (tu != NULL_TREE)
+pp_string (_name_pp, IDENTIFIER_POINTER (DECL_NAME (tu)));
+  else
+pp_string (_name_pp, aux_base_name);
+
   module_name_cst = asan_pp_string (_name_pp);
 
   if (asan_needs_local_alias (decl))
diff --git a/gcc/testsuite/c-c++-common/asan/global-overflow-1.c 
b/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
index b97801da2b7..7e167cee67a 100644
--- a/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
+++ b/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
@@ -26,4 +26,4 @@ int main() {
 /* { dg-output "READ of size 1 at 0x\[0-9a-f\]+ thread T0.*(\n|\r\n|\r)" } */
 /* { dg-output "#0 0x\[0-9a-f\]+ +(in _*main 
(\[^\n\r]*global-overflow-1.c:20|\[^\n\r]*:0|\[^\n\r]*\\+0x\[0-9a-z\]*)|\[(\])\[^\n\r]*(\n|\r\n|\r).*"
 } */
 /* { dg-output "0x\[0-9a-f\]+ is located 0 bytes after global variable" } */
-/* { dg-output ".*YYY\[^\n\r]* of size 10\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output ".*YYY\[^\n\r]*asan/global-overflow-1.c:15:15'\[^\n\r]*of size 
10\[^\n\r]*(\n|\r\n|\r)" } */
-- 
2.39.2



[PATCH (pushed)] libsanitizer: cherry-pick commit 8f5962b1ccb5fcd4d4544121d43efb860ac3cc6d from upstream

2023-02-24 Thread Martin Liška
ASAN: keep support for Global::location

We as GCC still emit __asan_global_source_location for global variables
and we would like to use it in the future. On other hand, we don't
support llvm-symbolizer and the default libbacktraace symbolizer
does not support location info.
---
 libsanitizer/asan/asan_globals.cpp  | 9 +
 libsanitizer/asan/asan_interface_internal.h | 7 ---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/libsanitizer/asan/asan_globals.cpp 
b/libsanitizer/asan/asan_globals.cpp
index 8f3491f0199..01a243927ca 100644
--- a/libsanitizer/asan/asan_globals.cpp
+++ b/libsanitizer/asan/asan_globals.cpp
@@ -92,6 +92,10 @@ static void ReportGlobal(const Global , const char 
*prefix) {
   if (info.line != 0) {
 Report("  location: name=%s, %d\n", info.file, 
static_cast(info.line));
   }
+  else if (g.gcc_location != 0) {
+// Fallback to Global::gcc_location
+Report("  location: name=%s, %d\n", g.gcc_location->filename, 
g.gcc_location->line_no);
+  }
 }
 
 static u32 FindRegistrationSite(const Global *g) {
@@ -283,6 +287,11 @@ void PrintGlobalLocation(InternalScopedString *str, const 
__asan_global ) {
 
   if (info.line != 0) {
 str->append("%s:%d", info.file, static_cast(info.line));
+  } else if (g.gcc_location != 0) {
+// Fallback to Global::gcc_location
+str->append("%s", g.gcc_location->filename ? g.gcc_location->filename : 
g.module_name);
+if (g.gcc_location->line_no) str->append(":%d", g.gcc_location->line_no);
+if (g.gcc_location->column_no) str->append(":%d", 
g.gcc_location->column_no);
   } else {
 str->append("%s", g.module_name);
   }
diff --git a/libsanitizer/asan/asan_interface_internal.h 
b/libsanitizer/asan/asan_interface_internal.h
index 987f855c0f9..a9982637802 100644
--- a/libsanitizer/asan/asan_interface_internal.h
+++ b/libsanitizer/asan/asan_interface_internal.h
@@ -53,9 +53,10 @@ extern "C" {
 const char *module_name; // Module name as a C string. This pointer is a
  // unique identifier of a module.
 uptr has_dynamic_init;   // Non-zero if the global has dynamic initializer.
-uptr windows_padding;// TODO: Figure out how to remove this padding
- // that's simply here to make the MSVC incremental
- // linker happy...
+__asan_global_source_location *gcc_location;  // Source location of a 
global,
+  // used by GCC compiler. 
LLVM uses
+  // llvm-symbolizer that 
relies
+  // on DWARF debugging info.
 uptr odr_indicator;  // The address of the ODR indicator symbol.
   };
 
-- 
2.39.2



Re: Using __gnu_lto_slim to detect -fno-fat-lto-objects

2023-02-23 Thread Martin Liška
On 2/22/23 09:28, Florian Weimer via Gcc wrote:
> * Richard Biener:
> 
>> On Wed, Feb 22, 2023 at 9:19 AM Florian Weimer via Gcc  
>> wrote:
>>>
>>> Can we use the COMMON symbol __gnu_lto_slim to detect
>>> -fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker
>>> plugin)?
>>
>> Yes.
> 
> Great, thanks.
> 
>>> We currently build the distribution with -ffat-lto-objects, and I want
>>> to switch away from that.  Packages will need to opt in to
>>> -ffat-lto-objects if static objects they build escape the buildroot.

Hello.

We use the same approach where only a selected packages enable FAT lto objects.
You can take a look at our META bug where such packages are linked (in most 
cases):
https://bugzilla.opensuse.org/show_bug.cgi?id=1133084

Or one can easily grep it from here:
https://github.com/bmwiedemann/openSUSE

$ git grep 'fat-lto-objects'
(see attachment)

>>> And to make sure that this opt-in happens, I want to fail the build if
>>> there would be any -fno-fat-lto-objects objects leaking.
>>
>> For SUSE we're checking that no LTO bytecode leaks instead, thus we check
>> for __gnu_lto_v? (I think).  The reason is that even for static libraries
>> we do not want to ship LTO bytecode.
> 
> We build with -ffat-lto-objects, and this means we can create perfectly
> fine object files by stripping the LTO data:
> 
> 

We strip this way:
https://github.com/openSUSE/brp-check-suse/blob/2f7add6f0b7f5c2e9698d180a4761a10fb808482/brp-15-strip-debug#L38

> 
> This means that so far, we only had to fix LTO compilation problems in
> the packages, but not teach individual packages about LTO and non-LTO
> object files.  Of course it's wasteful because few packages actually
> install the object files (without a final link into a program or shared
> object), and that's what I want to fix.

And we integrated a rpmlint check that checks we don't ship a LTO bytecode:
https://github.com/rpm-software-management/rpmlint/blob/aa1f710c1b3ff409e42068c2b067ab2eee200b1d/rpmlint/checks/BinariesCheck.py#L277-L283

and there's one related check where we look if a static library contains 
something:
https://github.com/rpm-software-management/rpmlint/blob/aa1f710c1b3ff409e42068c2b067ab2eee200b1d/rpmlint/checks/BinariesCheck.py#L230-L255

it can happen that it only contained bytecode that was eventually striped.

Cheers,
Martin

> 
> Florian
> 
packages/a/ade/ade.changes:- Use -ffat-lto-objects to provide a proper static 
library.
packages/a/ade/ade.spec:%global _lto_cflags %{_lto_cflags} -ffat-lto-objects
packages/a/adios/.rev:- Fix aarch64 LTO build with -ffat-lto-objects flag
packages/a/adios/adios.changes:- Fix aarch64 LTO build with -ffat-lto-objects 
flag
packages/a/adios/adios.spec:%global _lto_cflags %{?_lto_cflags} 
-ffat-lto-objects
packages/a/aircrack-ng/aircrack-ng.spec:export CFLAGS="-ffat-lto-objects 
-fcommon"
packages/a/antlr/antlr-bootstrap.spec:%global _lto_cflags %{_lto_cflags} 
-ffat-lto-objects
packages/a/antlr/antlr.spec:%global _lto_cflags %{_lto_cflags} -ffat-lto-objects
packages/a/attr/attr.spec:%global _lto_cflags %{_lto_cflags} -ffat-lto-objects
packages/b/barcode/barcode.changes:- Build using -ffat-lto-objects
packages/b/barcode/barcode.spec:%global _lto_cflags %{_lto_cflags} 
-ffat-lto-objects
packages/b/binutils/.rev:- Use -ffat-lto-objects in order to 
provide assembly for static libs
packages/b/binutils/binutils.changes:- Use -ffat-lto-objects in order to 
provide assembly for static libs
packages/b/bison/bison.spec:%global _lto_cflags %{_lto_cflags} -ffat-lto-objects
packages/b/boinc-client/.rev:- Build boinc-client using 
-ffat-lto-objects
packages/b/boinc-client/boinc-client.changes:- Build boinc-client using 
-ffat-lto-objects
packages/b/boinc-client/boinc-client.spec:%global _lto_cflags %{_lto_cflags} 
-ffat-lto-objects
packages/b/bridge-utils/bridge-utils.changes:- Use -ffat-lto-objects when 
building static libraries.
packages/b/bridge-utils/bridge-utils.spec:%global _lto_cflags %{_lto_cflags} 
-ffat-lto-objects
packages/c/Catch2/Catch2.spec:%global _lto_cflags %{?_lto_cflags} 
-ffat-lto-objects
packages/c/carla/carla.changes:  * Do not use -ffat-lto-objects
packages/c/cgns/cgns.spec:%global _lto_cflags %{_lto_cflags} -ffat-lto-objects
packages/c/coturn/coturn.spec:%global _lto_cflags %{?_lto_cflags} 
-ffat-lto-objects
packages/c/criu/criu.changes:- Fix build on Tumbleweed: Add -ffat-lto-objects 
to lto cflags.
packages/d/dhcp/dhcp.spec:%global _lto_cflags %{_lto_cflags} -ffat-lto-objects
packages/d/dpkg/dpkg.spec:%global _lto_cflags %{_lto_cflags} -ffat-lto-objects
packages/d/dpkg/update-alternatives.spec:%global _lto_cflags %{_lto_cflags} 
-ffat-lto-objects
packages/e/e2fsprogs/e2fsprogs.spec:%global _lto_cflags %{_lto_cflags} 
-ffat-lto-objects
packages/e/elfutils/.rev:[  123s] created with -ffat-lto-objects option.
packages/e/elfutils/.rev:  And adding -ffat-lto-objects breaks 

Re: [PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file

2023-02-17 Thread Martin Liška
PING^3

On 2/1/23 14:13, Martin Liška wrote:
> PING^2
> 
> On 1/24/23 14:34, Martin Liška wrote:
>> PING^1
>>
>> On 1/10/23 16:10, Martin Liška wrote:
>>> On 1/6/23 14:21, David Malcolm wrote:
>>>> On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:
>>>>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>>>>> tests.
>>>>
>>>> Thanks for the patch.
>>>>
>>>> I noticed that you marked PR 108307 as a dup of this, which covers
>>>> -fdiagnostics-format=sarif-file (and a .S file as input).
>>>>
>>>> The patch doesn't add any test coverage (for either of the diagnostic
>>>> formats).
>>>>
>>>> If we try to emit a diagnostic and base_file_name is NULL, and the user
>>>> requested one of -fdiagnostics-format={json,sarif}-file, where do the
>>>> diagnostics go?  Where should they go?
>>>
>>> Hey.
>>>
>>> I've done a new version of the patch where I utilize x_main_input_basename.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>
>>> Ready to be installed?
>>> Thanks,
>>> Martin
>>
> 



Stepping down as gcov maintainer and callgraph reviewer

2023-02-16 Thread Martin Liška
Hello GCC community.

After spending last decade (including my diploma thesis even more)
of my life working on GCC, I decided to leave the project and try
a different job. I would like to thank all the community members I had
change to interact with, I learned so much and enjoyed the journey!
I'll be leaving somewhen at the beginning of May.

That said, I'm stepping down from my 2 positions as I won't have a time
for proper patch review and bugs in the area I'm responsible for.

I wish the project all the best!

Cheers,
MartinFrom bb3aee20cdeeb6399ca77ac05cd8093d66256df3 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 16 Feb 2023 16:50:38 +0100
Subject: [PATCH] MAINTAINERS: stepping down from my positions

ChangeLog:

	* MAINTAINERS: I'm stepping down from my positions.
---
 MAINTAINERS | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 18edc86df67..a61d3ae06df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -230,7 +230,6 @@ docstring relicensing	Gerald Pfeifer		
 docstring relicensing	Joseph Myers		
 predict.def		Jan Hubicka		
 gcov			Jan Hubicka		
-gcov			Martin Liska		
 gcov			Nathan Sidwell		
 option handling		Joseph Myers		
 middle-end		Jeff Law		
@@ -268,7 +267,6 @@ check in changes outside of the parts of the compiler they maintain.
 			Reviewers
 
 arc port		Claudiu Zissulescu	
-callgraph		Martin Liska		
 callgraph		Martin Jambor		
 C front end		Marek Polacek		
 CTF, BTF		David Faust		
@@ -519,6 +517,7 @@ Kriang Lerdsuwanakij
 Renlin Li	
 Xinliang David Li
 Chen Liqin	
+Martin Liska	
 Jiangning Liu	
 Sa Liu		
 Ralph Loader	
-- 
2.39.1



Re: Git 'hooks/post_receive.py': UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 2766: invalid start byte

2023-02-16 Thread Martin Liška
On 2/16/23 13:26, Thomas Schwinge wrote:
> Hi!
> 
> The following is not an actual problem for me or GCC/Rust; just for your
> information:

Hello.

Thanks for letting me know.

> 
> I've just pushed to GCC devel/rust/master branch
> Git commits cc23831ec66..74913f718b0, which 'hooks/post_receive.py' threw
> up upon:
> 
> $ git push upstream github/Rust-GCC/gccrs/master:devel/rust/master
> Enumerating objects: 326, done.
> Counting objects: 100% (326/326), done.
> Delta compression using up to 12 threads
> Compressing objects: 100% (143/143), done.
> Writing objects: 100% (224/224), 32.72 KiB | 6.54 MiB/s, done.
> Total 224 (delta 191), reused 106 (delta 79)
> remote: Resolving deltas: 100% (191/191), completed with 86 local objects.
> 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 0xff in 
> position 2766: invalid start byte
> To git+ssh://gcc.gnu.org/git/gcc.git
>cc23831ec66..74913f718b0  github/Rust-GCC/gccrs/master -> 
> devel/rust/master

Well, the https://github.com/AdaCore/git-hooks were ported to Python 3 some 
time ago and I thought we've been
using the updated version. But it seems we're still on python2.7 :((

Joseph, can we update it, please?

> 
> I very much suppose this "byte 0xff" is
> commit 92d6dc8443acbd27cab411bfd68eaca56a89
> "Implemented UTF-8 checking for include_str!()" adding
> 'gcc/testsuite/rust/compile/invalid_utf8':
> 
> $ od -x gcc/testsuite/rust/compile/invalid_utf8
> 000 0aff
> 002
> 
> Due to that (I suppose), Git commit emails to  have
> not been sent.

Dunno if that will be fixed or not, but Python 3 should make our life easier.

Martin

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



[PATCH (pushed)] docs: document new --param=asan-kernel-mem-intrinsic-prefix

2023-02-15 Thread Martin Liška
gcc/ChangeLog:

* doc/invoke.texi: Document --param=asan-kernel-mem-intrinsic-prefix.
---
 gcc/doc/invoke.texi | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 26de582e41e..0a43720f614 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15809,6 +15809,10 @@ is greater or equal to this number, use callbacks 
instead of inline checks.
 E.g. to disable inline code use
 @option{--param asan-instrumentation-with-call-threshold=0}.
 
+@item asan-kernel-mem-intrinsic-prefix
+Prefix calls to memcpy, memset and memmove with __asan_ or __hwasan_
+for -fsanitize=kernel-address or -fsanitize=kernel-hwaddress.
+
 @item hwasan-instrument-stack
 Enable hwasan instrumentation of statically sized stack-allocated variables.
 This kind of instrumentation is enabled by default when using
-- 
2.39.1



Re: realpath() patch to fix symlinks resolution for win32

2023-02-13 Thread Martin Liška

On 2/11/23 22:14, Gerald Pfeifer wrote:

On Sat, 11 Feb 2023, NightStrike wrote:

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

I would have expected the PR to have been automatically updated based on
the commit email. Any idea why that didn't happen? Not to change the state
to closed, but to add the commit information as a reply.


I assume the fact that the PR reference was spelt as
   PR/108350
without a slash, not a blank, after "PR" may be responsible for the
missing Bugzilla comment.

The documented format - per gcc.gnu.org/codingconventions.html - is
   PR component/12345


It's likely what happens.



Martin? (By the way, where does one best have a look at those hooks?
.git/hooks in the main repository isn't it, it appears?)


I know that server hooks (gcc.gnu.org:/home/gccadmin/hooks-bin) do contain:
email-to-bugzilla-filtered:BUGZILLA_CMD = ("/sourceware/infra/bin/email-to-bugzilla", 
"-G", "gcc")

thus I guess it's /sourceware/infra/bin/email-to-bugzilla what makes the 
filtering of commits
to bugzilla.

Martin



Gerald




[PATCH (pushed)] docs: document new param

2023-02-13 Thread Martin Liška

gcc/ChangeLog:

* doc/invoke.texi: Document ira-simple-lra-insn-threshold.
---
 gcc/doc/invoke.texi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 51447a78584..26de582e41e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15511,6 +15511,9 @@ available alternatives for preferred register class 
even if it has
 found some choice with an appropriate register class and respect the
 found qualified matching constraint.
 
+@item ira-simple-lra-insn-threshold

+Approximate function insn number in 1K units triggering simple local RA.
+
 @item lra-inheritance-ebb-probability-cutoff
 LRA tries to reuse values reloaded in registers in subsequent insns.
 This optimization is called inheritance.  EBB is used as a region to
--
2.39.1



Re: [PATCH] docs: add cavear for __builtin_cpu_supports

2023-02-09 Thread Martin Liška
On 2/9/23 11:43, Gerald Pfeifer wrote:
> On Thu, 9 Feb 2023, Martin Liška wrote:
>> Document that the function does not work correctly for old VIA 
>> processors.
> 
> Thanks for doing this, Martin!
> 
>> +Caveat: The built-in function does not work correctly on old VIA
>> +processors (Centaur family).
> 
> Maybe say "This built-in function...", though that's a nuance. The patch 
> is okay either way.

Thanks for review, I've just pushed it with the suggestion.

Martin

> 
> Gerald



[PATCH] docs: add cavear for __builtin_cpu_supports

2023-02-09 Thread Martin Liška
Document that the function does not work correctly for old
VIA processors.

Ready to be installed?
Thanks,
Martin

PR target/100758

gcc/ChangeLog:

* doc/extend.texi: Document that the function
does not work correctly for old VIA processors.
---
 gcc/doc/extend.texi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 5a026c4b48c..2aedf6dfe69 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -22071,6 +22071,9 @@ else
  count = generic_countbits (n); //generic implementation.
   @}
 @end smallexample
+
+Caveat: The built-in function does not work correctly on old VIA
+processors (Centaur family).
 @end deftypefn
 
 The following built-in functions are made available by @option{-mmmx}.
-- 
2.39.1



Re: [PATCH] ipa: silent -Wodr notes with -w

2023-02-08 Thread Martin Liška
On 2/9/23 01:10, Jan Hubicka wrote:
>>> On 2/1/23 15:26, Martin Jambor wrote:
>>>> Hi,
>>>>
>>>> On Fri, Dec 02 2022, Martin Liška wrote:
>>>>> If -w is used, warn_odr properly sets *warned = false and
>>>>> so it should be preserved when calling warn_types_mismatch.
>>>>>
>>>>> Noticed that during a LTO reduction where I used -w.
>>>>>
>>>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>>>
>>>>> Ready to be installed?
>>>>> Thanks,
>>>>> Martin
>>>>>
>>>>> gcc/ChangeLog:
>>>>>
>>>>>   * ipa-devirt.cc (odr_types_equivalent_p): Respect *warned
>>>>>   value if set.
>>>>
>>>
>>> Hi.
>>>
>>>> Sorry for skipping this for so long, usually ODR stuff is... interesting
>>>> to the point I gladly leave it to Honza.
>>>
>>> Makes sense, however, he's not much active when it comes to patch review.
>>
>> Sorry, I was confused by the patch and delayed reply to figure out what
>> you are trying to fix.  Indeed the dererence is missing here, however
>> every caller that sets warn to true should also set warned to non-NULL.
>> So indeed derefernce is missing, but I think the check for
>> warned == NULL should not be necessary.
> 
> This seems to bootstrap with LTO.  I am not sure what testcase you
> looked in, but unless there as a good reason to include the NULL check,
> I would rmeove it as it makes it harder to see what is going on.

Hi.

Thanks for the patch. Apparently, I noticed that during reduction of a test-case
where I used -w in order to silent all warnings.

So go ahead with your patch.

Martin

> 
> honza
> 
> diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
> index 14cf132c767..819860258d1 100644
> --- a/gcc/ipa-devirt.cc
> +++ b/gcc/ipa-devirt.cc
> @@ -1221,6 +1221,9 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
> bool *warned,
>   hash_set *visited,
>   location_t loc1, location_t loc2)
>  {
> +  /* If we are asked to warn, we need warned to keep track if warning was
> + output.  */
> +  gcc_assert (!warn || warned);
>/* Check first for the obvious case of pointer identity.  */
>if (t1 == t2)
>  return true;
> @@ -1300,7 +1303,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
> bool *warned,
> warn_odr (t1, t2, NULL, NULL, warn, warned,
>   G_("it is defined as a pointer to different type "
>  "in another translation unit"));
> -   if (warn && (warned == NULL || *warned))
> +   if (warn && *warned)
>   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2),
>loc1, loc2);
> return false;
> @@ -1315,7 +1318,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
> bool *warned,
> warn_odr (t1, t2, NULL, NULL, warn, warned,
>   G_("a different type is defined "
>  "in another translation unit"));
> -   if (warn && (warned == NULL || *warned))
> +   if (warn && *warned)
>   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
> return false;
>   }
> @@ -1333,7 +1336,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
> bool *warned,
>   warn_odr (t1, t2, NULL, NULL, warn, warned,
> G_("a different type is defined in another "
>"translation unit"));
> - if (warn && (warned == NULL || *warned))
> + if (warn && *warned)
> warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
> }
>   gcc_assert (TYPE_STRING_FLAG (t1) == TYPE_STRING_FLAG (t2));
> @@ -1375,7 +1378,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
> bool *warned,
> warn_odr (t1, t2, NULL, NULL, warn, warned,
>   G_("has different return value "
>  "in another translation unit"));
> -   if (warn && (warned == NULL || *warned))
> +   if (warn && *warned)
>   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
> return false;
>   }
> @@ -1398,7 +1401,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
> bool *warned,
> warn_odr (t1, t2, NULL, NULL, warn, warned,
> 

Re: [PATCH] ipa: silent -Wodr notes with -w

2023-02-01 Thread Martin Liška

On 2/1/23 15:26, Martin Jambor wrote:

Hi,

On Fri, Dec 02 2022, Martin Liška wrote:

If -w is used, warn_odr properly sets *warned = false and
so it should be preserved when calling warn_types_mismatch.

Noticed that during a LTO reduction where I used -w.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

* ipa-devirt.cc (odr_types_equivalent_p): Respect *warned
value if set.




Hi.


Sorry for skipping this for so long, usually ODR stuff is... interesting
to the point I gladly leave it to Honza.


Makes sense, however, he's not much active when it comes to patch review.



Please go ahead and commit the patch.  The way I read the code, your
version must have been the intended behavior and the dereference is
missing.


Yep, the patch seems to me quite straightforward.

Thanks,
Martin



Thanks,

Martin





Re: [PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file

2023-02-01 Thread Martin Liška

PING^2

On 1/24/23 14:34, Martin Liška wrote:

PING^1

On 1/10/23 16:10, Martin Liška wrote:

On 1/6/23 14:21, David Malcolm wrote:

On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:

Patch can bootstrap on x86_64-linux-gnu and survives regression
tests.


Thanks for the patch.

I noticed that you marked PR 108307 as a dup of this, which covers
-fdiagnostics-format=sarif-file (and a .S file as input).

The patch doesn't add any test coverage (for either of the diagnostic
formats).

If we try to emit a diagnostic and base_file_name is NULL, and the user
requested one of -fdiagnostics-format={json,sarif}-file, where do the
diagnostics go?  Where should they go?


Hey.

I've done a new version of the patch where I utilize x_main_input_basename.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin






Re: [PATCH] ipa: silent -Wodr notes with -w

2023-02-01 Thread Martin Liška

PING^5

On 1/24/23 14:34, Martin Liška wrote:

PING^4

On 1/13/23 10:09, Martin Liška wrote:

PING^3

On 12/22/22 13:15, Martin Liška wrote:

PING^2

On 12/9/22 09:27, Martin Liška wrote:

PING^1

On 12/2/22 12:27, Martin Liška wrote:

If -w is used, warn_odr properly sets *warned = false and
so it should be preserved when calling warn_types_mismatch.

Noticed that during a LTO reduction where I used -w.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

 * ipa-devirt.cc (odr_types_equivalent_p): Respect *warned
 value if set.
---
   gcc/ipa-devirt.cc | 12 ++--
   1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
index 265d07bb354..bcdc50c5bd7 100644
--- a/gcc/ipa-devirt.cc
+++ b/gcc/ipa-devirt.cc
@@ -1300,7 +1300,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
     warn_odr (t1, t2, NULL, NULL, warn, warned,
   G_("it is defined as a pointer to different type "
  "in another translation unit"));
-  if (warn && warned)
+  if (warn && (warned == NULL || *warned))
   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2),
    loc1, loc2);
     return false;
@@ -1315,7 +1315,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
     warn_odr (t1, t2, NULL, NULL, warn, warned,
   G_("a different type is defined "
  "in another translation unit"));
-  if (warn && warned)
+  if (warn && (warned == NULL || *warned))
   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
     return false;
   }
@@ -1333,7 +1333,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
   warn_odr (t1, t2, NULL, NULL, warn, warned,
     G_("a different type is defined in another "
    "translation unit"));
-    if (warn && warned)
+    if (warn && (warned == NULL || *warned))
     warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
     }
   gcc_assert (TYPE_STRING_FLAG (t1) == TYPE_STRING_FLAG (t2));
@@ -1375,7 +1375,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
     warn_odr (t1, t2, NULL, NULL, warn, warned,
   G_("has different return value "
  "in another translation unit"));
-  if (warn && warned)
+  if (warn && (warned == NULL || *warned))
   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
     return false;
   }
@@ -1398,7 +1398,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
     warn_odr (t1, t2, NULL, NULL, warn, warned,
   G_("has different parameters in another "
  "translation unit"));
-  if (warn && warned)
+  if (warn && (warned == NULL || *warned))
   warn_types_mismatch (TREE_VALUE (parms1),
    TREE_VALUE (parms2), loc1, loc2);
     return false;
@@ -1484,7 +1484,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
   warn_odr (t1, t2, f1, f2, warn, warned,
     G_("a field of same name but different type "
    "is defined in another translation unit"));
-    if (warn && warned)
+    if (warn && (warned == NULL || *warned))
     warn_types_mismatch (TREE_TYPE (f1), TREE_TYPE (f2), loc1, 
loc2);
   return false;
     }












[PATCH (pushed)] libsanitizer: Regenerate configure

2023-01-31 Thread Martin Liška
libsanitizer/ChangeLog:

* configure: Regenerate.
---
 libsanitizer/configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libsanitizer/configure b/libsanitizer/configure
index d4ee0fac3e7..e7984f96615 100755
--- a/libsanitizer/configure
+++ b/libsanitizer/configure
@@ -17045,6 +17045,7 @@ else
 $as_echo "no" >&6; }
 fi
 
+
 # Always set -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to sync with LLVM,
 # and keep struct *stat* have the same size.
 case "${host}" in
@@ -17054,7 +17055,7 @@ esac
 
 EXTRA_CFLAGS="$EXTRA_CFLAGS $CET_FLAGS $FILE64_FLAGS"
 EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $CET_FLAGS $FILE64_FLAGS"
-EXTRA_ASFLAGS="$CET_FLAGS $FILE64_FLAGS"
+EXTRA_ASFLAGS=$CET_FLAGS
 
 
 
-- 
2.39.1



[PATCH] driver: fix -gz=none error message with missing zstd

2023-01-27 Thread Martin Liška
We wrongly report:

$ echo "int main () {}" | gcc -xc -gz=none -
gcc: error: -gz=zstd is not supported in this configuration

if zstd compression is not supported by binutils. We should emit the
error message only if -gz=zstd.

PR driver/108572

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

* gcc.cc (LINK_COMPRESS_DEBUG_SPEC): Report error only for
-gz=zstd.
---
 gcc/gcc.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index d8130024a8c..becc56051a8 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -842,7 +842,7 @@ proper position among the other output files.  */
 #define LINK_COMPRESS_DEBUG_SPEC \
" %{gz|gz=zlib:"  LD_COMPRESS_DEBUG_OPTION "=zlib}" \
" %{gz=none:" LD_COMPRESS_DEBUG_OPTION "=none}" \
-   " %{gz*:%e-gz=zstd is not supported in this configuration} " \
+   " %{gz=zstd:%e-gz=zstd is not supported in this configuration} " \
" %{gz=zlib-gnu:}" /* Ignore silently zlib-gnu option value.  */
 #elif HAVE_LD_COMPRESS_DEBUG == 2
 /* ELF gABI style and ZSTD.  */
-- 
2.39.1



[PATCH] ipa: check if cache_token != NULL before hash_set::add call

2023-01-24 Thread Martin Liška
We should not insert an empty value to the container.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR ipa/108509

gcc/ChangeLog:

* cgraphunit.cc (walk_polymorphic_call_targets): Insert
ony non-null values.
* ipa.cc (walk_polymorphic_call_targets): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ipa/pr108509.C: New test.
---
 gcc/cgraphunit.cc   |  2 +-
 gcc/ipa.cc  |  2 +-
 gcc/testsuite/g++.dg/ipa/pr108509.C | 22 ++
 3 files changed, 24 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr108509.C

diff --git a/gcc/cgraphunit.cc b/gcc/cgraphunit.cc
index 832818d651f..a972900900b 100644
--- a/gcc/cgraphunit.cc
+++ b/gcc/cgraphunit.cc
@@ -1000,7 +1000,7 @@ walk_polymorphic_call_targets (hash_set 
*reachable_call_targets,
 = possible_polymorphic_call_targets
(edge, , _token);
 
-  if (!reachable_call_targets->add (cache_token))
+  if (cache_token != NULL && !reachable_call_targets->add (cache_token))
 {
   if (symtab->dump_file)
dump_possible_polymorphic_call_targets 
diff --git a/gcc/ipa.cc b/gcc/ipa.cc
index 4de605000b6..5c15b60a603 100644
--- a/gcc/ipa.cc
+++ b/gcc/ipa.cc
@@ -182,7 +182,7 @@ walk_polymorphic_call_targets (hash_set 
*reachable_call_targets,
 = possible_polymorphic_call_targets
(edge, , _token);
 
-  if (!reachable_call_targets->add (cache_token))
+  if (cache_token != NULL && !reachable_call_targets->add (cache_token))
 {
   for (i = 0; i < targets.length (); i++)
{
diff --git a/gcc/testsuite/g++.dg/ipa/pr108509.C 
b/gcc/testsuite/g++.dg/ipa/pr108509.C
new file mode 100644
index 000..2844189bbb4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr108509.C
@@ -0,0 +1,22 @@
+// PR ipa/108509
+// { dg-do compile }
+// { dg-options "-O1 -fdevirtualize -fno-tree-fre" }
+
+struct B {
+  virtual void deref ();
+};
+
+struct RefPtr {
+  B *p;
+
+  RefPtr ()
+  {
+p->deref ();
+  }
+};
+
+void
+f ()
+{
+  RefPtr b;
+}
-- 
2.39.0



Re: [PATCH] ipa: silent -Wodr notes with -w

2023-01-24 Thread Martin Liška
PING^4

On 1/13/23 10:09, Martin Liška wrote:
> PING^3
> 
> On 12/22/22 13:15, Martin Liška wrote:
>> PING^2
>>
>> On 12/9/22 09:27, Martin Liška wrote:
>>> PING^1
>>>
>>> On 12/2/22 12:27, Martin Liška wrote:
>>>> If -w is used, warn_odr properly sets *warned = false and
>>>> so it should be preserved when calling warn_types_mismatch.
>>>>
>>>> Noticed that during a LTO reduction where I used -w.
>>>>
>>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>>
>>>> Ready to be installed?
>>>> Thanks,
>>>> Martin
>>>>
>>>> gcc/ChangeLog:
>>>>
>>>> * ipa-devirt.cc (odr_types_equivalent_p): Respect *warned
>>>> value if set.
>>>> ---
>>>>   gcc/ipa-devirt.cc | 12 ++--
>>>>   1 file changed, 6 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
>>>> index 265d07bb354..bcdc50c5bd7 100644
>>>> --- a/gcc/ipa-devirt.cc
>>>> +++ b/gcc/ipa-devirt.cc
>>>> @@ -1300,7 +1300,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>>>> bool *warned,
>>>>     warn_odr (t1, t2, NULL, NULL, warn, warned,
>>>>   G_("it is defined as a pointer to different type "
>>>>  "in another translation unit"));
>>>> -  if (warn && warned)
>>>> +  if (warn && (warned == NULL || *warned))
>>>>   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2),
>>>>    loc1, loc2);
>>>>     return false;
>>>> @@ -1315,7 +1315,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>>>> bool *warned,
>>>>     warn_odr (t1, t2, NULL, NULL, warn, warned,
>>>>   G_("a different type is defined "
>>>>  "in another translation unit"));
>>>> -  if (warn && warned)
>>>> +  if (warn && (warned == NULL || *warned))
>>>>   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
>>>>     return false;
>>>>   }
>>>> @@ -1333,7 +1333,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>>>> bool *warned,
>>>>   warn_odr (t1, t2, NULL, NULL, warn, warned,
>>>>     G_("a different type is defined in another "
>>>>    "translation unit"));
>>>> -    if (warn && warned)
>>>> +    if (warn && (warned == NULL || *warned))
>>>>     warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, 
>>>> loc2);
>>>>     }
>>>>   gcc_assert (TYPE_STRING_FLAG (t1) == TYPE_STRING_FLAG (t2));
>>>> @@ -1375,7 +1375,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>>>> bool *warned,
>>>>     warn_odr (t1, t2, NULL, NULL, warn, warned,
>>>>   G_("has different return value "
>>>>  "in another translation unit"));
>>>> -  if (warn && warned)
>>>> +  if (warn && (warned == NULL || *warned))
>>>>   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
>>>>     return false;
>>>>   }
>>>> @@ -1398,7 +1398,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>>>> bool *warned,
>>>>     warn_odr (t1, t2, NULL, NULL, warn, warned,
>>>>   G_("has different parameters in another "
>>>>  "translation unit"));
>>>> -  if (warn && warned)
>>>> +  if (warn && (warned == NULL || *warned))
>>>>   warn_types_mismatch (TREE_VALUE (parms1),
>>>>    TREE_VALUE (parms2), loc1, loc2);
>>>>     return false;
>>>> @@ -1484,7 +1484,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>>>> bool *warned,
>>>>   warn_odr (t1, t2, f1, f2, warn, warned,
>>>>     G_("a field of same name but different type "
>>>>    "is defined in another translation unit"));
>>>> -    if (warn && warned)
>>>> +    if (warn && (warned == NULL || *warned))
>>>>     warn_types_mismatch (TREE_TYPE (f1), TREE_TYPE (f2), loc1, 
>>>> loc2);
>>>>   return false;
>>>>     }
>>>
>>
> 



Re: [PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file

2023-01-24 Thread Martin Liška
PING^1

On 1/10/23 16:10, Martin Liška wrote:
> On 1/6/23 14:21, David Malcolm wrote:
>> On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>>> tests.
>>
>> Thanks for the patch.
>>
>> I noticed that you marked PR 108307 as a dup of this, which covers
>> -fdiagnostics-format=sarif-file (and a .S file as input).
>>
>> The patch doesn't add any test coverage (for either of the diagnostic
>> formats).
>>
>> If we try to emit a diagnostic and base_file_name is NULL, and the user
>> requested one of -fdiagnostics-format={json,sarif}-file, where do the
>> diagnostics go?  Where should they go?
> 
> Hey.
> 
> I've done a new version of the patch where I utilize x_main_input_basename.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin



Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

2023-01-23 Thread Martin Liška
On 1/20/23 18:33, Jason Merrill wrote:
> Martin, I wonder about having the hooks reject out-of-order CommitDate
> in future?

Yes, I would do that. Looking at the last 30K commmits I see just a few 
violations
of the order:

UNIXTS hash
1668298622 30d77d49628
1630019619 5889e842ae4
1626967834 3f7a2374d31
1624564915 a0accaa9984
1620660174 0498d2d09a2
1606210175 f72175357d0
1605630503 8895913273b
1604409789 1528f34341b
1601415121 f836f3bc8f7
1593773652 9bc2c2347d5
1588873342 b9250b3cb91
1582563261 9069e9484ce

Martin


[PATCH (pushed)] Ignore test_patches.txt in update-copyright.py.

2023-01-17 Thread Martin Liška
contrib/ChangeLog:

* update-copyright.py: Ignore test_patches.txt.
---
 contrib/update-copyright.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/update-copyright.py b/contrib/update-copyright.py
index ac7a94743cf..f3691dc11cc 100755
--- a/contrib/update-copyright.py
+++ b/contrib/update-copyright.py
@@ -693,6 +693,7 @@ class ContribFilter(GenericFilter):
 'Info.plist',
 # Contains CR (^M).
 'repro_fail',
+'test_patches.txt',
 ])
 
 class GCCCopyright (Copyright):
-- 
2.39.0



[PATCH] contrib: ignore CR in update-copyright.py

2023-01-17 Thread Martin Liška
When opening files, preserve CR characters. By default, open
accepts universal newlines, but I think we should only split with '\n'.

Ready to be installed?
Thanks,
Martin

contrib/ChangeLog:

* update-copyright.py: Split lines only with '\n'.
---
 contrib/update-copyright.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/update-copyright.py b/contrib/update-copyright.py
index ac7a94743cf..bdb5417bcec 100755
--- a/contrib/update-copyright.py
+++ b/contrib/update-copyright.py
@@ -408,7 +408,7 @@ class Copyright:
 line_filter = filter.get_line_filter (dir, filename)
 mode = None
 encoding = self.guess_encoding(pathname)
-with open (pathname, 'r', encoding=encoding) as file:
+with open (pathname, 'r', encoding=encoding, newline='\n') as file:
 prev = None
 mode = os.fstat (file.fileno()).st_mode
 for line in file:
@@ -434,7 +434,7 @@ class Copyright:
 # If something changed, write the new file out.
 if changed and self.errors.ok():
 tmp_pathname = pathname + '.tmp'
-with open (tmp_pathname, 'w', encoding=encoding) as file:
+with open (tmp_pathname, 'w', encoding=encoding, newline='\n') as 
file:
 for line in lines:
 file.write (line)
 os.fchmod (file.fileno(), mode)
-- 
2.39.0



[PATCH (pushed)] contrib: revert removal of CR character

2023-01-17 Thread Martin Liška
contrib/ChangeLog:

* gcc-changelog/test_patches.txt: The CR character was removed
with ./contrib/update-copyright.py which I'm going to change.
---
 contrib/gcc-changelog/test_patches.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/contrib/gcc-changelog/test_patches.txt 
b/contrib/gcc-changelog/test_patches.txt
index 2f1cd923a13..1d120f8e472 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -3631,8 +3631,7 @@ index 000..d75da75
 +pub fn main ()
 +{
 +// { dg-error "Isolated CR" "" { target *-*-* } .+1 }
-+  //! doc cr
- comment
++  //! doc cr
 comment
 +}
 -- 
 2.38.1
-- 
2.39.0



[PATCH (pushed)] Regenerate Makefile.in files.

2023-01-17 Thread Martin Liška
libbacktrace/ChangeLog:

* Makefile.in: Regenerate.

libgomp/ChangeLog:

* Makefile.in: Regenerate.
* configure: Regenerate.

libphobos/ChangeLog:

* Makefile.in: Regenerate.
* libdruntime/Makefile.in: Regenerate.

libstdc++-v3/ChangeLog:

* src/libbacktrace/Makefile.in: Regenerate.
---
 libbacktrace/Makefile.in  | 2 +-
 libgomp/Makefile.in   | 2 +-
 libgomp/configure | 2 +-
 libphobos/Makefile.in | 2 +-
 libphobos/libdruntime/Makefile.in | 2 +-
 libstdc++-v3/src/libbacktrace/Makefile.in | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index c79fd3bfa6b..889144acb1c 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -15,7 +15,7 @@
 @SET_MAKE@
 
 # Makefile.am -- Backtrace Makefile.
-# Copyright (C) 2012-2022 Free Software Foundation, Inc.
+# Copyright (C) 2012-2023 Free Software Foundation, Inc.
 
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions are
diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 8ffd45c9c41..2c81ccacc1d 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -16,7 +16,7 @@
 
 # Plugins for offload execution, Makefile.am fragment.
 #
-# Copyright (C) 2014-2022 Free Software Foundation, Inc.
+# Copyright (C) 2014-2023 Free Software Foundation, Inc.
 #
 # Contributed by Mentor Embedded.
 #
diff --git a/libgomp/configure b/libgomp/configure
index 45a769eb10a..fd0e337b578 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -15053,7 +15053,7 @@ _ACEOF
 
 # Plugins for offload execution, configure.ac fragment.  -*- mode: autoconf -*-
 #
-# Copyright (C) 2014-2022 Free Software Foundation, Inc.
+# Copyright (C) 2014-2023 Free Software Foundation, Inc.
 #
 # Contributed by Mentor Embedded.
 #
diff --git a/libphobos/Makefile.in b/libphobos/Makefile.in
index 2e9360a5238..8d62c31dab0 100644
--- a/libphobos/Makefile.in
+++ b/libphobos/Makefile.in
@@ -15,7 +15,7 @@
 @SET_MAKE@
 
 # Makefile for the toplevel directory of the D Standard library.
-# Copyright (C) 2006-2022 Free Software Foundation, Inc.
+# Copyright (C) 2006-2023 Free Software Foundation, Inc.
 #
 # GCC is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
diff --git a/libphobos/libdruntime/Makefile.in 
b/libphobos/libdruntime/Makefile.in
index e86721fb3fe..3f04496bd7b 100644
--- a/libphobos/libdruntime/Makefile.in
+++ b/libphobos/libdruntime/Makefile.in
@@ -15,7 +15,7 @@
 @SET_MAKE@
 
 # Makefile for the D runtime library.
-# Copyright (C) 2012-2022 Free Software Foundation, Inc.
+# Copyright (C) 2012-2023 Free Software Foundation, Inc.
 #
 # GCC is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
diff --git a/libstdc++-v3/src/libbacktrace/Makefile.in 
b/libstdc++-v3/src/libbacktrace/Makefile.in
index 7c112722938..1c1242d8827 100644
--- a/libstdc++-v3/src/libbacktrace/Makefile.in
+++ b/libstdc++-v3/src/libbacktrace/Makefile.in
@@ -15,7 +15,7 @@
 @SET_MAKE@
 
 # Makefile.am -- Backtrace in libstdc++ Makefile.
-# Copyright (C) 2012-2013 Free Software Foundation, Inc.
+# Copyright (C) 2012-2023 Free Software Foundation, Inc.
 
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions are
-- 
2.39.0



Re: [PATCH] libgcc: Fix uninitialized RA signing on AArch64 [PR107678]

2023-01-16 Thread Martin Liška
On 1/12/23 19:57, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Jan 10, 2023 at 04:33:59PM +, Wilco Dijkstra via Gcc-patches 
> wrote:
>> Hi Szabolcs,
>>
>>> i would keep the assert: how[reg] must be either UNSAVED or UNDEFINED
>>> here, other how[reg] means the toggle cfi instruction is mixed with
>>> incompatible instructions for the pseudo reg.
>>>
>>> and i would add a comment about this e.g. saying that UNSAVED/UNDEFINED
>>> how[reg] is used for tracking the return address signing status and
>>> other how[reg] is not allowed here.
>>
>> I've added the assert back and updated the comment.
> 
> BTW, the patch doesn't apply to trunk cleanly (since the January 2nd
> r13-4955-gcb775ecd6e437 commit).

@Wilco, can you please send the rebased patch for patch review? We would
need in out openSUSE package soon.

Thank you,
Martin

> 
>> v3: Improve comments, add assert.
>>
>> A recent change only initializes the regs.how[] during Dwarf unwinding
>> which resulted in an uninitialized offset used in return address signing
>> and random failures during unwinding.  The fix is to encode the return
>> address signing state in REG_UNSAVED and REG_UNDEFINED.
>>
>> Passes bootstrap & regress, OK for commit?
>>
>> libgcc/
>> PR target/107678
>> * unwind-dw2.c (execute_cfa_program): Use REG_UNSAVED/UNDEFINED
>> to encode return address signing state.
>> * config/aarch64/aarch64-unwind.h (aarch64_demangle_return_addr)
>> Check current return address signing state.
>> (aarch64_frob_update_contex): Remove.
> 
>   Jakub
> 



Re: [PATCH] IPA: do not release body if still needed

2023-01-16 Thread Martin Liška
On 1/14/23 22:36, Jan Hubicka wrote:
>> Hi.
>>
>> Noticed during building of libbackend.a with the LTO partial linking.
>>
>> The function release_body is called even if clone_of is a clone
>> of a another function and thus it shares tree declaration. We should
>> preserve it in that situation.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>>
>>  PR ipa/107944
>>
>> gcc/ChangeLog:
>>
>>  * cgraph.cc (cgraph_node::remove): Do not release body
>>  if a node is clone of another node.
>> ---
>>  gcc/cgraph.cc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
>> index f15cb47c8b8..2e7d77ffd6c 100644
>> --- a/gcc/cgraph.cc
>> +++ b/gcc/cgraph.cc
>> @@ -1893,7 +1893,7 @@ cgraph_node::remove (void)
>>else if (clone_of)
>>  {
>>clone_of->clones = next_sibling_clone;
>> -  if (!clone_of->analyzed && !clone_of->clones && !clones)
>> +  if (!clone_of->analyzed && !clone_of->clones && !clones && 
>> !clone_of->clone_of)
>>  clone_of->release_body ();
> 
> It is interesting that the problem reproduced only after almost 20
> years.  But I suppose it is because we materialize clones in parituclar
> order.

Well, it started with r13-48-g27ee75dbe81bb7 where Martin add a new code
that calls the release_body function. So it's pretty new.

> 
> I think there are two ways to fix it.  Either declare release_body to be
> applicable only to the master clone and avoid calling it here (as you
> do) or make release_body do nothing when called on a clone.
> I guess it makes sense to keep your approach but please add sanity check
> to release_body that clone_of == NULL with a comment.

I do support Martin's enhanced version of the patch.

Cheers,
Martin

> 
> OK with that change.
> Honza
>>  }
>>if (next_sibling_clone)
>> -- 
>> 2.38.1
>>



Re: [PATCH] ipa: silent -Wodr notes with -w

2023-01-13 Thread Martin Liška

PING^3

On 12/22/22 13:15, Martin Liška wrote:

PING^2

On 12/9/22 09:27, Martin Liška wrote:

PING^1

On 12/2/22 12:27, Martin Liška wrote:

If -w is used, warn_odr properly sets *warned = false and
so it should be preserved when calling warn_types_mismatch.

Noticed that during a LTO reduction where I used -w.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

* ipa-devirt.cc (odr_types_equivalent_p): Respect *warned
value if set.
---
  gcc/ipa-devirt.cc | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
index 265d07bb354..bcdc50c5bd7 100644
--- a/gcc/ipa-devirt.cc
+++ b/gcc/ipa-devirt.cc
@@ -1300,7 +1300,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
  warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("it is defined as a pointer to different type "
   "in another translation unit"));
- if (warn && warned)
+ if (warn && (warned == NULL || *warned))
warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2),
 loc1, loc2);
  return false;
@@ -1315,7 +1315,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
  warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("a different type is defined "
   "in another translation unit"));
- if (warn && warned)
+ if (warn && (warned == NULL || *warned))
warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
  return false;
}
@@ -1333,7 +1333,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
warn_odr (t1, t2, NULL, NULL, warn, warned,
  G_("a different type is defined in another "
 "translation unit"));
-   if (warn && warned)
+   if (warn && (warned == NULL || *warned))
  warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
  }
gcc_assert (TYPE_STRING_FLAG (t1) == TYPE_STRING_FLAG (t2));
@@ -1375,7 +1375,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
  warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("has different return value "
   "in another translation unit"));
- if (warn && warned)
+ if (warn && (warned == NULL || *warned))
warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
  return false;
}
@@ -1398,7 +1398,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
  warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("has different parameters in another "
   "translation unit"));
- if (warn && warned)
+ if (warn && (warned == NULL || *warned))
warn_types_mismatch (TREE_VALUE (parms1),
 TREE_VALUE (parms2), loc1, loc2);
  return false;
@@ -1484,7 +1484,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
warn_odr (t1, t2, f1, f2, warn, warned,
  G_("a field of same name but different type "
 "is defined in another translation unit"));
-   if (warn && warned)
+   if (warn && (warned == NULL || *warned))
  warn_types_mismatch (TREE_TYPE (f1), TREE_TYPE (f2), 
loc1, loc2);
return false;
  }








Re: [PATCH] tree-optimization/107767 - not profitable switch conversion

2023-01-11 Thread Martin Liška
On 1/9/23 12:09, Richard Biener wrote:
> |Martin, OK with you?|

Yes, thanks for handling that.

Martin


Re: [PATCH] libgcc: Fix uninitialized RA signing on AArch64 [PR107678]

2023-01-11 Thread Martin Liška
On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
> Anyway, the sooner this makes it into gcc trunk, the better, it breaks quite
> a lot of stuff.

Yep, please, we're also waiting for this patch for pushing to our gcc13 package.

Cheers,
Martin


[gcc-12 backport] strlen: do not use cond_expr for boundaries

2023-01-11 Thread Martin Liška
Tested, I'm going to push it.

Martin

PR tree-optimization/108137

gcc/ChangeLog:

* tree-ssa-strlen.cc (get_range_strlen_phi): Reject anything
different from INTEGER_CST.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr108137.c: New test.

(cherry picked from commit ee6f262b87fef590729e96e999f1c3b207c251c0)
---
 gcc/testsuite/gcc.dg/tree-ssa/pr108137.c |  8 
 gcc/tree-ssa-strlen.cc   | 13 +++--
 2 files changed, 15 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr108137.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr108137.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr108137.c
new file mode 100644
index 000..f0cb71b2267
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr108137.c
@@ -0,0 +1,8 @@
+// PR tree-optimization/108137
+// { dg-do compile }
+// { dg-options "-Wformat-overflow" }
+
+void f(unsigned short x_port, unsigned int x_host)
+{
+__builtin_printf("missing %s", x_port ? "host" : &"host:port"[x_host ? 5 : 
0]);
+}
diff --git a/gcc/tree-ssa-strlen.cc b/gcc/tree-ssa-strlen.cc
index 9ae25d1dde2..2d7db6da5bc 100644
--- a/gcc/tree-ssa-strlen.cc
+++ b/gcc/tree-ssa-strlen.cc
@@ -1136,14 +1136,15 @@ get_range_strlen_phi (tree src, gphi *phi,
 
   /* Adjust the minimum and maximum length determined so far and
 the upper bound on the array size.  */
-  if (!pdata->minlen
- || tree_int_cst_lt (argdata.minlen, pdata->minlen))
+  if (TREE_CODE (argdata.minlen) == INTEGER_CST
+ && (!pdata->minlen
+ || tree_int_cst_lt (argdata.minlen, pdata->minlen)))
pdata->minlen = argdata.minlen;
 
-  if (!pdata->maxlen
- || (argdata.maxlen
- && TREE_CODE (argdata.maxlen) == INTEGER_CST
- && tree_int_cst_lt (pdata->maxlen, argdata.maxlen)))
+  if (TREE_CODE (argdata.maxlen) == INTEGER_CST
+ && (!pdata->maxlen
+ || (argdata.maxlen
+ && tree_int_cst_lt (pdata->maxlen, argdata.maxlen
pdata->maxlen = argdata.maxlen;
 
   if (!pdata->maxbound
-- 
2.39.0



[PATCH] switch expansion: limit JT growth param values

2023-01-11 Thread Martin Liška
Currently, one can request a huge jump table creation which
leads to a non-sensual huge output. Moreover, use auto_vec rather
than a stack-allocated array.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR middle-end/107976

gcc/ChangeLog:

* params.opt: Limit JT params.
* stmt.cc (emit_case_dispatch_table): Use auto_vec.
---
 gcc/params.opt | 4 ++--
 gcc/stmt.cc| 9 -
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/gcc/params.opt b/gcc/params.opt
index e178dec1600..3454700eb91 100644
--- a/gcc/params.opt
+++ b/gcc/params.opt
@@ -327,11 +327,11 @@ Common Joined UInteger Var(param_iv_max_considered_uses) 
Init(250) Param Optimiz
 Bound on number of iv uses in loop optimized in iv optimizations.
 
 -param=jump-table-max-growth-ratio-for-size=
-Common Joined UInteger Var(param_jump_table_max_growth_ratio_for_size) 
Init(300) Param Optimization
+Common Joined UInteger Var(param_jump_table_max_growth_ratio_for_size) 
Init(300) IntegerRange(0, 1) Param Optimization
 The maximum code size growth ratio when expanding into a jump table (in 
percent).  The parameter is used when optimizing for size.
 
 -param=jump-table-max-growth-ratio-for-speed=
-Common Joined UInteger Var(param_jump_table_max_growth_ratio_for_speed) 
Init(800) Param Optimization
+Common Joined UInteger Var(param_jump_table_max_growth_ratio_for_speed) 
Init(800) IntegerRange(0, 1) Param Optimization
 The maximum code size growth ratio when expanding into a jump table (in 
percent).  The parameter is used when optimizing for speed.
 
 -param=l1-cache-line-size=
diff --git a/gcc/stmt.cc b/gcc/stmt.cc
index 82a3e1035ec..b239c02018a 100644
--- a/gcc/stmt.cc
+++ b/gcc/stmt.cc
@@ -746,7 +746,7 @@ emit_case_dispatch_table (tree index_expr, tree index_type,
  tree range, basic_block stmt_bb)
 {
   int i, ncases;
-  rtx *labelvec;
+  auto_vec labelvec;
   rtx_insn *fallback_label = label_rtx (case_list[0].m_code_label);
   rtx_code_label *table_label = gen_label_rtx ();
   bool has_gaps = false;
@@ -779,8 +779,7 @@ emit_case_dispatch_table (tree index_expr, tree index_type,
   /* Get table of labels to jump to, in order of case index.  */
 
   ncases = tree_to_shwi (range) + 1;
-  labelvec = XALLOCAVEC (rtx, ncases);
-  memset (labelvec, 0, ncases * sizeof (rtx));
+  labelvec.safe_grow_cleared (ncases);
 
   for (unsigned j = 0; j < case_list.length (); j++)
 {
@@ -860,11 +859,11 @@ emit_case_dispatch_table (tree index_expr, tree 
index_type,
 emit_jump_table_data (gen_rtx_ADDR_DIFF_VEC (CASE_VECTOR_MODE,
 gen_rtx_LABEL_REF (Pmode,

table_label),
-gen_rtvec_v (ncases, labelvec),
+gen_rtvec_v (ncases, 
labelvec.address ()),
 const0_rtx, const0_rtx));
   else
 emit_jump_table_data (gen_rtx_ADDR_VEC (CASE_VECTOR_MODE,
-   gen_rtvec_v (ncases, labelvec)));
+   gen_rtvec_v (ncases, 
labelvec.address (;
 
   /* Record no drop-through after the table.  */
   emit_barrier ();
-- 
2.39.0



Re: [PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file

2023-01-10 Thread Martin Liška
On 1/6/23 14:21, David Malcolm wrote:
> On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:
>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>> tests.
> 
> Thanks for the patch.
> 
> I noticed that you marked PR 108307 as a dup of this, which covers
> -fdiagnostics-format=sarif-file (and a .S file as input).
> 
> The patch doesn't add any test coverage (for either of the diagnostic
> formats).
> 
> If we try to emit a diagnostic and base_file_name is NULL, and the user
> requested one of -fdiagnostics-format={json,sarif}-file, where do the
> diagnostics go?  Where should they go?

Hey.

I've done a new version of the patch where I utilize x_main_input_basename.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
MartinFrom 078233b4f84ae6d81a7327589723b2be518d29ca Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 10 Jan 2023 15:14:05 +0100
Subject: [PATCH] middle-end: always find a basename for -fdiagnostics-format=*

In some situations, x_dump_base_name is NULL and thus we can
and should use x_main_input_basename which should never be NULL.

	PR middle-end/106133

gcc/ChangeLog:

	* gcc.cc (driver_handle_option): Use x_main_input_basename
	if x_dump_base_name is null.
	* opts.cc (common_handle_option): Likewise.

gcc/testsuite/ChangeLog:

	* c-c++-common/pr106133.c: New test.
---
 gcc/gcc.cc| 10 +++---
 gcc/opts.cc   | 10 +++---
 gcc/testsuite/c-c++-common/pr106133.c |  3 +++
 3 files changed, 17 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/pr106133.c

diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index d629ca5e424..382ca817a09 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -4290,9 +4290,13 @@ driver_handle_option (struct gcc_options *opts,
   break;
 
 case OPT_fdiagnostics_format_:
-  diagnostic_output_format_init (dc, opts->x_dump_base_name,
- (enum diagnostics_output_format)value);
-  break;
+	{
+	  const char *basename = (opts->x_dump_base_name ? opts->x_dump_base_name
+  : opts->x_main_input_basename);
+	  diagnostic_output_format_init (dc, basename,
+	 (enum diagnostics_output_format)value);
+	  break;
+	}
 
 case OPT_Wa_:
   {
diff --git a/gcc/opts.cc b/gcc/opts.cc
index 9ba47d7deaa..4809c18a529 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -2863,9 +2863,13 @@ common_handle_option (struct gcc_options *opts,
   break;
 
 case OPT_fdiagnostics_format_:
-  diagnostic_output_format_init (dc, opts->x_dump_base_name,
- (enum diagnostics_output_format)value);
-  break;
+	{
+	  const char *basename = (opts->x_dump_base_name ? opts->x_dump_base_name
+  : opts->x_main_input_basename);
+	  diagnostic_output_format_init (dc, basename,
+	 (enum diagnostics_output_format)value);
+	  break;
+	}
 
 case OPT_fdiagnostics_parseable_fixits:
   dc->extra_output_kind = (value
diff --git a/gcc/testsuite/c-c++-common/pr106133.c b/gcc/testsuite/c-c++-common/pr106133.c
new file mode 100644
index 000..7d2c5afe417
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/pr106133.c
@@ -0,0 +1,3 @@
+/* PR middle-end/106133 */
+/* { dg-do compile } */
+/* { dg-options "-fdiagnostics-format=json-file -E" } */
-- 
2.39.0



Re: [PATCH] Remove legacy pre-C++ 11 definitions

2023-01-10 Thread Martin Liška
On 1/9/23 16:19, Jonathan Wakely wrote:
> On Mon, 9 Jan 2023 at 15:17, Martin Liška  wrote:
>>
>> On 1/6/23 19:23, Jonathan Wakely wrote:
>>> Seems to me that GCC code should just use nullptr directly not redefine 
>>> NULL.
>>
>> Sure, but that would lead to a huge patch which would rename NULL to 
>> nullptr, right?
> 
> 
> Yeah, which can probably be done separately (or not done at all).

That would be a massive patch affecting all targets and FEs.

> I was just commenting on the comment that Andrew showed. That comment
> explain that nullptr is better than 0 as a null pointer constant,
> which is a good reason to prefer nullptr. But not a good reason to
> redefine NULL; in code with a minimum requirement of C++11 you can
> just use nullptr directly.

Ok, so does it mean my patch addresses what can be easily adjusted?

Thanks,
Martin



Re: [PATCH][pushed] contrib: add 'contrib' to default dirs in update-copyright.py

2023-01-09 Thread Martin Liška
> However, I noticed when I run ./contrib/update-copyright.py --this-year
> I get much more modifications out of contrib folder:

@Jakub?

Martin



Re: [PATCH] ipa: Sort ipa_param_body_adjustments::m_replacements (PR 108110)

2023-01-09 Thread Martin Liška

On 1/6/23 17:50, Martin Jambor wrote:

Hi,

On Fri, Jan 06 2023, Martin Liška wrote:

Hi Martin


+  key.unit_offset = unit_offset;
+  ipa_param_body_replacement *res
+= std::lower_bound (m_replacements.begin (), m_replacements.end (), key,
+   [] (const ipa_param_body_replacement ,
+   const ipa_param_body_replacement )
+   {
+ if (DECL_UID (elt.base) < DECL_UID (val.base))
+   return true;
+ if (DECL_UID (elt.base) > DECL_UID (val.base))
+   return false;
+ if (elt.unit_offset < val.unit_offset)
+   return true;
+ return false;
+   });


I'm curious if we can re-use compare_param_body_replacement as the introduced
lambda does a very similar thing, right?



Not directly, the qsort callback returns an integer that can be either
negative, positive or zero but the lower_bound returns only true or
false (the semantics is that it returns the first element for which it
returns false).  Plus one takes parameters which are pointer and other
needs references.


Hi.

I see, so leaving that up to you if you want to adjust it or not.

OK for both versions of the patch.

Cheers,
Martin



So I was lazy and just came up with a similar comparator lambda.  But
sure, I can call the qsort comparator from it, which I guess makes sense
at least for consistency.  I'll adjust the patch.

Thanks,

Martin




Re: [PATCH] Remove legacy pre-C++ 11 definitions

2023-01-09 Thread Martin Liška

On 1/6/23 19:23, Jonathan Wakely wrote:

Seems to me that GCC code should just use nullptr directly not redefine NULL.


Sure, but that would lead to a huge patch which would rename NULL to nullptr, 
right?

Martin


[PATCH] hash: do not insert deleted value to a hash_set

2023-01-09 Thread Martin Liška

Hi.

After the new hash_set checking code, we face an issue where deleted value
is added to a hash_set. Fix it.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR lto/108330

gcc/ChangeLog:

* lto-cgraph.cc (compute_ltrans_boundary): Do not insert
NULL (deleleted value) to a hash_set.

gcc/testsuite/ChangeLog:

* g++.dg/ipa/pr108830.C: New test.
---
 gcc/lto-cgraph.cc   |  3 ++-
 gcc/testsuite/g++.dg/ipa/pr108830.C | 20 
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr108830.C

diff --git a/gcc/lto-cgraph.cc b/gcc/lto-cgraph.cc
index eef5ea1d061..805c7855eb3 100644
--- a/gcc/lto-cgraph.cc
+++ b/gcc/lto-cgraph.cc
@@ -918,7 +918,8 @@ compute_ltrans_boundary (lto_symtab_encoder_t in_encoder)
  vec targets
= possible_polymorphic_call_targets
(edge, , _token);
- if (!reachable_call_targets.add (cache_token))
+ if (cache_token != NULL
+ && !reachable_call_targets.add (cache_token))
{
  for (i = 0; i < targets.length (); i++)
{
diff --git a/gcc/testsuite/g++.dg/ipa/pr108830.C 
b/gcc/testsuite/g++.dg/ipa/pr108830.C
new file mode 100644
index 000..96656f67e4f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr108830.C
@@ -0,0 +1,20 @@
+// PR lto/108330
+// { dg-do compile }
+
+class A {
+  virtual unsigned long m_fn1() const;
+virtual int _fn2(unsigned long) const;
+};
+class C : A {
+public:
+  int _fn2(unsigned long) const;
+unsigned long m_fn1() const;
+};
+class B {
+  void m_fn3(const A &, const int &, const C &, int &) const;
+};
+void B::m_fn3(const A &, const int &, const C &, int &) const {
+  C (a);
+for (long b = 0; a.m_fn1(); b++)
+ a.m_fn2(0);
+}
--
2.39.0



[PATCH] Remove legacy pre-C++ 11 definitions

2023-01-06 Thread Martin Liška
As mentioned in the PRs, both are defined in C++ 11
which is a version we depend on.

Ready to be installed now?

Thanks,
Martin

PR middle-end/108311
PR middle-end/108312

gcc/ChangeLog:

* system.h (va_copy): Remove as it is defined in C++ 11.
(NULL): Likewise.
---
 gcc/system.h | 13 -
 1 file changed, 13 deletions(-)

diff --git a/gcc/system.h b/gcc/system.h
index 5eaeb9d2d03..0d06b9749e5 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -31,25 +31,12 @@ along with GCC; see the file COPYING3.  If not see
 /* We must include stdarg.h before stdio.h.  */
 #include 
 
-#ifndef va_copy
-# ifdef __va_copy
-#   define va_copy(d,s)  __va_copy (d, s)
-# else
-#   define va_copy(d,s)  ((d) = (s))
-# endif
-#endif
-
 #ifdef HAVE_STDDEF_H
 # include 
 #endif
 
 #include 
 
-/* Define a generic NULL if one hasn't already been defined.  */
-#ifndef NULL
-#define NULL 0
-#endif
-
 /* Use the unlocked open routines from libiberty.  */
 
 /* Some of these are #define on some systems, e.g. on AIX to redirect
-- 
2.39.0



Re: [PATCH] ipa: Sort ipa_param_body_adjustments::m_replacements (PR 108110)

2023-01-06 Thread Martin Liška
Hi Martin

> +  key.unit_offset = unit_offset;
> +  ipa_param_body_replacement *res
> += std::lower_bound (m_replacements.begin (), m_replacements.end (), key,
> + [] (const ipa_param_body_replacement ,
> + const ipa_param_body_replacement )
> + {
> +   if (DECL_UID (elt.base) < DECL_UID (val.base))
> + return true;
> +   if (DECL_UID (elt.base) > DECL_UID (val.base))
> + return false;
> +   if (elt.unit_offset < val.unit_offset)
> + return true;
> +   return false;
> + });

I'm curious if we can re-use compare_param_body_replacement as the introduced
lambda does a very similar thing, right?

Thanks,
Martin


[PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file

2023-01-06 Thread Martin Liška
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR middle-end/106133

gcc/ChangeLog:

* diagnostic.cc (diagnostic_output_format_init): If
-fdiagnostics-format=json-file and -E is used, then
base_file_name is null and we should not emit anything.
---
 gcc/diagnostic.cc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index c90c14e993e..fe7d121e340 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -2277,6 +2277,9 @@ diagnostic_output_format_init (diagnostic_context 
*context,
   const char *base_file_name,
   enum diagnostics_output_format format)
 {
+  if (base_file_name == NULL)
+return;
+
   switch (format)
 {
 default:
-- 
2.39.0



[PATCH][pushed] contrib: add 'contrib' to default dirs in update-copyright.py

2023-01-05 Thread Martin Liška
Hi.

I forgot to include contrib folder in default dir, thus the copyright in the 
folder
haven't been updated by Jakub.

However, I noticed when I run ./contrib/update-copyright.py --this-year
I get much more modifications out of contrib folder:

$ git diff --stat
...
 951 files changed, 976 insertions(+), 979 deletions(-)

where the are not updated files is:
gcc/analyzer/*
gcc/common/config/*
gcc/m2/*
gcc/objc/*

Jakub, can you please re-run the script?

Cheers,
Martin

contrib/ChangeLog:

* update-copyright.py: Add contrib as a default dir.
---
 contrib/update-copyright.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/update-copyright.py b/contrib/update-copyright.py
index fcae846fb1e..06e6fb61757 100755
--- a/contrib/update-copyright.py
+++ b/contrib/update-copyright.py
@@ -785,6 +785,7 @@ class GCCCmdLine (CmdLine):
 
 self.default_dirs = [
 'c++tools',
+'contrib',
 'gcc',
 'include',
 'libada',
-- 
2.39.0



Re: [PATCH] contrib: add contrib to update-copyright.py script

2022-12-28 Thread Martin Liška
On 12/14/22 14:13, Jakub Jelinek wrote:
> s/Filder/Filter/g ?

Yep. Pushed with the fix as there hasn't been any comments on this.

Martin


Re: [PATCH] IPA: do not release body if still needed

2022-12-28 Thread Martin Liška
PING^2

On 12/9/22 09:28, Martin Liška wrote:
> PING^1
> 
> On 12/1/22 10:59, Martin Liška wrote:
>> Hi.
>>
>> Noticed during building of libbackend.a with the LTO partial linking.
>>
>> The function release_body is called even if clone_of is a clone
>> of a another function and thus it shares tree declaration. We should
>> preserve it in that situation.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>>
>>  PR ipa/107944
>>
>> gcc/ChangeLog:
>>
>>  * cgraph.cc (cgraph_node::remove): Do not release body
>>  if a node is clone of another node.
>> ---
>>  gcc/cgraph.cc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
>> index f15cb47c8b8..2e7d77ffd6c 100644
>> --- a/gcc/cgraph.cc
>> +++ b/gcc/cgraph.cc
>> @@ -1893,7 +1893,7 @@ cgraph_node::remove (void)
>>else if (clone_of)
>>  {
>>clone_of->clones = next_sibling_clone;
>> -  if (!clone_of->analyzed && !clone_of->clones && !clones)
>> +  if (!clone_of->analyzed && !clone_of->clones && !clones && 
>> !clone_of->clone_of)
>>  clone_of->release_body ();
>>  }
>>if (next_sibling_clone)
> 



[PATCH] docs: fix Var documentation for .opt files

2022-12-28 Thread Martin Liška
The Var documentation was somehow wrongly split into 2 pieces.

PR middle-end/107966

gcc/ChangeLog:

* doc/options.texi: Fix Var documentation in internal manual.
---
 gcc/doc/options.texi | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/gcc/doc/options.texi b/gcc/doc/options.texi
index 17ba923890e..39a2d1a0d43 100644
--- a/gcc/doc/options.texi
+++ b/gcc/doc/options.texi
@@ -340,19 +340,6 @@ The state of this option should be stored in variable 
@var{var}
 (actually a macro for @code{global_options.x_@var{var}}).
 The way that the state is stored depends on the type of option:
 
-@item WarnRemoved
-The option is removed and every usage of such option will
-result in a warning.  We use it option backward compatibility.
-
-@item Var(@var{var}, @var{set})
-The option controls an integer variable @var{var} and is active when
-@var{var} equals @var{set}.  The option parser will set @var{var} to
-@var{set} when the positive form of the option is used and @code{!@var{set}}
-when the ``no-'' form is used.
-
-@var{var} is declared in the same way as for the single-argument form
-described above.
-
 @itemize @bullet
 @item
 If the option uses the @code{Mask} or @code{InverseMask} properties,
@@ -390,11 +377,24 @@ and wasn't given.
 The option-processing script will usually zero-initialize @var{var}.
 You can modify this behavior using @code{Init}.
 
+@item Var(@var{var}, @var{set})
+The option controls an integer variable @var{var} and is active when
+@var{var} equals @var{set}.  The option parser will set @var{var} to
+@var{set} when the positive form of the option is used and @code{!@var{set}}
+when the ``no-'' form is used.
+
+@var{var} is declared in the same way as for the single-argument form
+described above.
+
 @item Init(@var{value})
 The variable specified by the @code{Var} property should be statically
 initialized to @var{value}.  If more than one option using the same
 variable specifies @code{Init}, all must specify the same initializer.
 
+@item WarnRemoved
+The option is removed and every usage of such option will
+result in a warning.  We use it option backward compatibility.
+
 @item Mask(@var{name})
 The option is associated with a bit in the @code{target_flags}
 variable (@pxref{Run-time Target}) and is active when that bit is set.
-- 
2.39.0



Re: Document how to build PGO-optimized GCC version

2022-12-28 Thread Martin Liška
On 12/28/22 06:48, Andrew Pinski via Gcc wrote:
> But distros do provide more recent prebuilt binaries, you could ask
> them to build using PGO (some do already I think).

Yes, I can confirm that the openSUSE gccX pacakges utlize both PGO and LTO 
during
the compiler bootstrap. So, you can use:
https://software.opensuse.org/package/gcc12

What compiler version and the architecture are you interested in?

Cheers,
Martin


Re: [00/13] check hash table counts

2022-12-28 Thread Martin Liška
On 12/27/22 05:07, Alexandre Oliva via Gcc-patches wrote:
> 
> While looking into another issue that corrupted hash tables, I added
> code to check consistency of element counts, and hit numerous issues
> that were concerning, of three kinds: insertion of entries that seem
> empty, dangling insertions, and lookups during insertions.
> 
> These problems may all have the effect of replacing a deleted entry
> with one that seems empty, which may disconnect double-hashing chains
> involving that entry, and thus cause entries to go missing.
> 
> This patch, opening the patch series, only adds code to detect these
> problems to the hash table verifier method.  I'm not sure it makes
> sense to put it in, but I post it for the record.  Fixes and cheaper
> detectors for some of these errors are going to be posted separately.
> 
> The number of bugs it revealed tells me that leaving callers in charge
> of completing insertions is too error prone.  I found this
> verification code a bit too expensive to enable in general.

Hello.

I really like the verification code you added. It's quite similar to what
I added to hash-table.h:

void
hash_table
::verify (const compare_type , hashval_t hash)

where the check is also expensive, but I guard it with a param value:

hash-table-verification-limit
The number of elements for which hash table verification is done for each 
searched element.

You can utilize the parameter or come up with your own.

Cheers,
Martin

>  We could
> add check entry count cheaply at expand time and catch some of these
> at very low cost, which would likely catch at least some of the
> errors, but perhaps a safer interface could avoid them entirely.
> WDYT?
> 
> 
> I'm going to post a collection of 13 patches a as a followup to this
> one, fixing various problems it has detected, or adding code to catch
> some of these problems sooner.
> 
> 
> for  gcc/ChangeLog
> 
>   * hash-table.h (verify): Check elements and deleted counts.
> ---
>  gcc/hash-table.h |   17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/gcc/hash-table.h b/gcc/hash-table.h
> index 53507daae26c3..7dbeea05373a2 100644
> --- a/gcc/hash-table.h
> +++ b/gcc/hash-table.h
> @@ -1035,6 +1035,23 @@ hash_table
> && Descriptor::equal (*entry, comparable))
>   hashtab_chk_error ();
>  }
> +
> +  if (m_size < 2048)
> +{
> +  size_t elmts = m_n_elements, dels = m_n_deleted;
> +  for (size_t i = 0; i < m_size; i++)
> + {
> +   value_type *entry = _entries[i];
> +   if (!is_empty (*entry))
> + {
> +   elmts--;
> +   if (is_deleted (*entry))
> + dels--;
> + }
> + }
> +  if (elmts || dels)
> + hashtab_chk_error ();
> +}
>  }
>  
>  /* This function deletes an element with the given COMPARABLE value
> 
> 



[PATCH] c: check if target_clone attrs are all string

2022-12-28 Thread Martin Liška
Hi.

The patch checks all attribute arguments if they are string. If not,
an error message is emitted.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR c/107993

gcc/c-family/ChangeLog:

* c-attribs.cc (handle_target_clones_attribute): Check for
string constant for all target_clone attribute values.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr107993.c: New test.
---
 gcc/c-family/c-attribs.cc| 14 ++
 gcc/testsuite/gcc.target/i386/pr107993.c |  9 +
 2 files changed, 19 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr107993.c

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index b36dd97802b..33d84cb6e07 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -5574,12 +5574,18 @@ handle_target_clones_attribute (tree *node, tree name, 
tree ARG_UNUSED (args),
   /* Ensure we have a function type.  */
   if (TREE_CODE (*node) == FUNCTION_DECL)
 {
-  if (TREE_CODE (TREE_VALUE (args)) != STRING_CST)
+  for (tree t = args; t != NULL_TREE; t = TREE_CHAIN (t))
{
- error ("%qE attribute argument not a string constant", name);
- *no_add_attrs = true;
+ tree value = TREE_VALUE (t);
+ if (TREE_CODE (value) != STRING_CST)
+   {
+ error ("%qE attribute argument not a string constant", name);
+ *no_add_attrs = true;
+ return NULL_TREE;
+   }
}
-  else if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (*node)))
+
+  if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (*node)))
{
  warning (OPT_Wattributes, "%qE attribute ignored due to conflict "
   "with %qs attribute", name, "always_inline");
diff --git a/gcc/testsuite/gcc.target/i386/pr107993.c 
b/gcc/testsuite/gcc.target/i386/pr107993.c
new file mode 100644
index 000..b0b84a677d8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr107993.c
@@ -0,0 +1,9 @@
+/* PR c/107993 */
+/* { dg-do compile } */
+
+typedef union { int x; } u;
+__attribute__((target_clones("arch=alderlake",!"default")))
+int f (u *x)
+{ /* { dg-error ".target_clones. attribute argument not a string constant" } */
+  return 0;
+}
-- 
2.39.0



[PATCH] strlen: do not use cond_expr for boundaries

2022-12-23 Thread Martin Liška
Hi.

We reach cond_expr and then we get an ICE in tree_int_cst_lt.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR tree-optimization/108137

gcc/ChangeLog:

* tree-ssa-strlen.cc (get_range_strlen_phi): Reject anything
different from INTEGER_CST.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr108137.c: New test.
---
 gcc/testsuite/gcc.dg/tree-ssa/pr108137.c |  8 
 gcc/tree-ssa-strlen.cc   | 13 +++--
 2 files changed, 15 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr108137.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr108137.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr108137.c
new file mode 100644
index 000..f0cb71b2267
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr108137.c
@@ -0,0 +1,8 @@
+// PR tree-optimization/108137
+// { dg-do compile }
+// { dg-options "-Wformat-overflow" }
+
+void f(unsigned short x_port, unsigned int x_host)
+{
+__builtin_printf("missing %s", x_port ? "host" : &"host:port"[x_host ? 5 : 
0]);
+}
diff --git a/gcc/tree-ssa-strlen.cc b/gcc/tree-ssa-strlen.cc
index abec225566d..a2edac4c77f 100644
--- a/gcc/tree-ssa-strlen.cc
+++ b/gcc/tree-ssa-strlen.cc
@@ -1136,14 +1136,15 @@ get_range_strlen_phi (tree src, gphi *phi,
 
   /* Adjust the minimum and maximum length determined so far and
 the upper bound on the array size.  */
-  if (!pdata->minlen
- || tree_int_cst_lt (argdata.minlen, pdata->minlen))
+  if (TREE_CODE (argdata.minlen) == INTEGER_CST
+ && (!pdata->minlen
+ || tree_int_cst_lt (argdata.minlen, pdata->minlen)))
pdata->minlen = argdata.minlen;
 
-  if (!pdata->maxlen
- || (argdata.maxlen
- && TREE_CODE (argdata.maxlen) == INTEGER_CST
- && tree_int_cst_lt (pdata->maxlen, argdata.maxlen)))
+  if (TREE_CODE (argdata.maxlen) == INTEGER_CST
+ && (!pdata->maxlen
+ || (argdata.maxlen
+ && tree_int_cst_lt (pdata->maxlen, argdata.maxlen
pdata->maxlen = argdata.maxlen;
 
   if (!pdata->maxbound
-- 
2.39.0



Re: [PATCH] ipa: silent -Wodr notes with -w

2022-12-22 Thread Martin Liška
PING^2

On 12/9/22 09:27, Martin Liška wrote:
> PING^1
> 
> On 12/2/22 12:27, Martin Liška wrote:
>> If -w is used, warn_odr properly sets *warned = false and
>> so it should be preserved when calling warn_types_mismatch.
>>
>> Noticed that during a LTO reduction where I used -w.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>>  * ipa-devirt.cc (odr_types_equivalent_p): Respect *warned
>>  value if set.
>> ---
>>  gcc/ipa-devirt.cc | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
>> index 265d07bb354..bcdc50c5bd7 100644
>> --- a/gcc/ipa-devirt.cc
>> +++ b/gcc/ipa-devirt.cc
>> @@ -1300,7 +1300,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>> bool *warned,
>>warn_odr (t1, t2, NULL, NULL, warn, warned,
>>  G_("it is defined as a pointer to different type "
>> "in another translation unit"));
>> -  if (warn && warned)
>> +  if (warn && (warned == NULL || *warned))
>>  warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2),
>>   loc1, loc2);
>>return false;
>> @@ -1315,7 +1315,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>> bool *warned,
>>warn_odr (t1, t2, NULL, NULL, warn, warned,
>>  G_("a different type is defined "
>> "in another translation unit"));
>> -  if (warn && warned)
>> +  if (warn && (warned == NULL || *warned))
>>  warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
>>return false;
>>  }
>> @@ -1333,7 +1333,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>> bool *warned,
>>  warn_odr (t1, t2, NULL, NULL, warn, warned,
>>G_("a different type is defined in another "
>>   "translation unit"));
>> -if (warn && warned)
>> +if (warn && (warned == NULL || *warned))
>>warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
>>}
>>  gcc_assert (TYPE_STRING_FLAG (t1) == TYPE_STRING_FLAG (t2));
>> @@ -1375,7 +1375,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>> bool *warned,
>>warn_odr (t1, t2, NULL, NULL, warn, warned,
>>  G_("has different return value "
>> "in another translation unit"));
>> -  if (warn && warned)
>> +  if (warn && (warned == NULL || *warned))
>>  warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
>>return false;
>>  }
>> @@ -1398,7 +1398,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>> bool *warned,
>>warn_odr (t1, t2, NULL, NULL, warn, warned,
>>  G_("has different parameters in another "
>> "translation unit"));
>> -  if (warn && warned)
>> +  if (warn && (warned == NULL || *warned))
>>  warn_types_mismatch (TREE_VALUE (parms1),
>>   TREE_VALUE (parms2), loc1, loc2);
>>return false;
>> @@ -1484,7 +1484,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
>> bool *warned,
>>  warn_odr (t1, t2, f1, f2, warn, warned,
>>G_("a field of same name but different type "
>>   "is defined in another translation unit"));
>> -if (warn && warned)
>> +if (warn && (warned == NULL || *warned))
>>warn_types_mismatch (TREE_TYPE (f1), TREE_TYPE (f2), 
>> loc1, loc2);
>>  return false;
>>}
> 



Re: [PATCH] Backport gcc-12: jobserver FIFO support

2022-12-22 Thread Martin Liška
On 12/12/22 13:05, Martin Liška wrote:
> On 12/12/22 12:42, Jakub Jelinek wrote:
>> On Mon, Dec 12, 2022 at 12:39:36PM +0100, Martin Liška wrote:
>>>> I'm fine with backporting the whole
>>>> series to GCC 12 but I wonder if earlier still maintained versions are also
>>>> affected (noting that the series also addresses WPA streaming which is
>>>> not part of the "troubles" here).
>>>
>>> Yes, they are also affected.
>>>
>>> So ready for all active branches?
>>
>> Can't you backport instead a minimal fix that will not change other stuff?
> 
> Yes, then it would be exactly the following 2 patches:
> 
> 1270ccda70ca09f7d4fe76b5156dca8992bd77a6
> 53e3b2bf16a486c15c20991c6095f7be09012b55

I'm going to push that to all release branches.

Cheers,
Martin

> 
> Martin
> 
>>
>>  Jakub
>>
> 



[PATCH] go: fix clang warnings

2022-12-21 Thread Martin Liška
The patch fixes the following Clang warnings:

gcc/go/gofrontend/escape.cc:1290:17: warning: private field 'fn_' is not used 
[-Wunused-private-field]
gcc/go/gofrontend/escape.cc:3478:19: warning: private field 'context_' is not 
used [-Wunused-private-field]
gcc/go/gofrontend/lex.h:564:15: warning: private field 'input_file_name_' is 
not used [-Wunused-private-field]
gcc/go/gofrontend/types.cc:5788:20: warning: private field 'call_' is not used 
[-Wunused-private-field]
gcc/go/gofrontend/wb.cc:206:9: warning: private field 'gogo_' is not used 
[-Wunused-private-field]

Ready for master?
Thanks,
Martin

gcc/go/ChangeLog:

* gofrontend/escape.cc (Gogo::analyze_escape): Remove context
arg.
(Gogo::assign_connectivity): Likewise.
(class Escape_analysis_tag): Remove context ctor argument.
(Gogo::tag_function): Likewise.
* gofrontend/expressions.cc (Call_expression::do_type):
Remove extra arg.
* gofrontend/gogo.h (class Gogo): Remove context arg.
* gofrontend/lex.h (class Lex): Make input_file_name_
with ATTRIBUTE_UNUSED.
* gofrontend/types.cc (class Call_multiple_result_type):
Remove call_ argument.
(Type::make_call_multiple_result_type): Likewise.
* gofrontend/types.h (class Type): Remove argument.
* gofrontend/wb.cc (class Check_escape): Remove gogo_
field.
(Gogo::add_write_barriers): Remove extra arg.
---
 gcc/go/gofrontend/escape.cc  | 20 +++-
 gcc/go/gofrontend/expressions.cc |  2 +-
 gcc/go/gofrontend/gogo.h |  2 +-
 gcc/go/gofrontend/lex.h  |  2 +-
 gcc/go/gofrontend/types.cc   | 13 -
 gcc/go/gofrontend/types.h|  2 +-
 gcc/go/gofrontend/wb.cc  | 10 +++---
 7 files changed, 18 insertions(+), 33 deletions(-)

diff --git a/gcc/go/gofrontend/escape.cc b/gcc/go/gofrontend/escape.cc
index 6da29edc419..ccbc7910743 100644
--- a/gcc/go/gofrontend/escape.cc
+++ b/gcc/go/gofrontend/escape.cc
@@ -990,7 +990,7 @@ Gogo::analyze_escape()
   for (std::vector::iterator fn = stack.begin();
fn != stack.end();
++fn)
-this->tag_function(context, *fn);
+   this->tag_function(*fn);
 
   if (this->debug_escape_level() != 0)
{
@@ -1246,10 +1246,10 @@ Escape_analysis_loop::statement(Block*, size_t*, 
Statement* s)
 class Escape_analysis_assign : public Traverse
 {
 public:
-  Escape_analysis_assign(Escape_context* context, Named_object* fn)
+  Escape_analysis_assign(Escape_context* context)
 : Traverse(traverse_statements
   | traverse_expressions),
-  context_(context), fn_(fn)
+  context_(context)
   { }
 
   // Model statements within a function as assignments and flows between nodes.
@@ -1286,8 +1286,6 @@ public:
 private:
   // The escape context for this set of functions.
   Escape_context* context_;
-  // The current function being analyzed.
-  Named_object* fn_;
 };
 
 // Helper function to detect self assignment like the following.
@@ -2899,7 +2897,7 @@ Gogo::assign_connectivity(Escape_context* context, 
Named_object* fn)
   int save_depth = context->loop_depth();
   context->set_loop_depth(1);
 
-  Escape_analysis_assign ea(context, fn);
+  Escape_analysis_assign ea(context);
   Function::Results* res = fn->func_value()->result_variables();
   if (res != NULL)
 {
@@ -3465,17 +3463,13 @@ Gogo::propagate_escape(Escape_context* context, Node* 
dst)
 class Escape_analysis_tag
 {
  public:
-  Escape_analysis_tag(Escape_context* context)
-: context_(context)
+  Escape_analysis_tag()
   { }
 
   // Add notes to the function's type about the escape information of its
   // input parameters.
   void
   tag(Named_object* fn);
-
- private:
-  Escape_context* context_;
 };
 
 void
@@ -3580,9 +3574,9 @@ Escape_analysis_tag::tag(Named_object* fn)
 // retain analysis results across imports.
 
 void
-Gogo::tag_function(Escape_context* context, Named_object* fn)
+Gogo::tag_function(Named_object* fn)
 {
-  Escape_analysis_tag eat(context);
+  Escape_analysis_tag eat;
   eat.tag(fn);
 }
 
diff --git a/gcc/go/gofrontend/expressions.cc b/gcc/go/gofrontend/expressions.cc
index 71838b14629..53901306ef7 100644
--- a/gcc/go/gofrontend/expressions.cc
+++ b/gcc/go/gofrontend/expressions.cc
@@ -12500,7 +12500,7 @@ Call_expression::do_type()
   else if (results->size() == 1)
 ret = results->begin()->type();
   else
-ret = Type::make_call_multiple_result_type(this);
+ret = Type::make_call_multiple_result_type();
 
   this->type_ = ret;
 
diff --git a/gcc/go/gofrontend/gogo.h b/gcc/go/gofrontend/gogo.h
index 433fdaebb66..c08a16b74c2 100644
--- a/gcc/go/gofrontend/gogo.h
+++ b/gcc/go/gofrontend/gogo.h
@@ -879,7 +879,7 @@ class Gogo
   // Add notes about the escape level of a function's input and output
   // parameters for exporting and importing top level functions.
   void
-  tag_function(Escape_context*, Named_object*);
+  

[PATCH (pushed)] libgccjit: silent 2 Clang warnings

2022-12-21 Thread Martin Liška
The make silent the following 2 warnings:

jit/jit-playback.h:785:16: warning: private field 'm_source_file' is not used 
[-Wunused-private-field]
jit/jit-playback.h:804:16: warning: private field 'm_line' is not used 
[-Wunused-private-field]

gcc/jit/ChangeLog:

* jit-playback.h: Use unused attribute.
---
 gcc/jit/jit-playback.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index 214f399f45c..43e92d67d74 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -782,7 +782,7 @@ public:
   vec m_locations;
 
 private:
-  source_file *m_source_file;
+  source_file *m_source_file ATTRIBUTE_UNUSED;
   int m_line_num;
 };
 
@@ -801,7 +801,7 @@ public:
 
 private:
   recording::location *m_recording_loc;
-  source_line *m_line;
+  source_line *m_line ATTRIBUTE_UNUSED;
   int m_column_num;
 };
 
-- 
2.39.0



Re: new ubsan handler

2022-12-19 Thread Martin Liška

On 12/19/22 10:25, Martin Uecker wrote:

Am Montag, dem 19.12.2022 um 09:44 +0100 schrieb Martin Liška:

On 12/17/22 20:35, Martin Uecker wrote:



Hi all,

what is the process for adding a new UBsan handler?


Hello.

Yes, we sync the run-time library from LLVM project. So a new
sanitizer
should go there first.



We have the source in the GCC tree, but I guess this
should go via LLVM?


And the compiler support (instrumentation) is independent.


Thanks Martin!

Does it make sense to send the full patch (with changes
to the compiler and library) to gcc-patches first for
review?


Yep, please CC me.



I am working on a patch that calls a handler when bounds
for VM-types do not match on assignment.


Nice. So basically something like -fsanitize=bounds/bounds-strict/object-size ?

Martin




Martin





[PATCH (pushed)] gcc-changelog: support digits in PR's component in subject

2022-12-19 Thread Martin Liška

Yes, fixed in the following patch.

Martin

contrib/ChangeLog:

* gcc-changelog/git_commit.py: Support digits in PR's
component in subject.
---
 contrib/gcc-changelog/git_commit.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 7fde02cba85..b73e587eb98 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -163,7 +163,7 @@ author_line_regex = \
 re.compile(r'^(?P\d{4}-\d{2}-\d{2})\ {2}(?P.*  <.*>)')
 additional_author_regex = re.compile(r'^\t(?P\ *)?(?P.*  <.*>)')
 changelog_regex = re.compile(r'^(?:[fF]or +)?([a-z0-9+-/]*)ChangeLog:?')
-subject_pr_regex = 
re.compile(r'(^|\W)PR\s+(?P[a-zA-Z+-]+)/(?P\d{4,7})')
+subject_pr_regex = 
re.compile(r'(^|\W)PR\s+(?P[a-zA-Z0-9+-]+)/(?P\d{4,7})')
 subject_pr2_regex = re.compile(r'[(\[]PR\s*(?P\d{4,7})[)\]]')
 pr_regex = re.compile(r'\tPR (?P[a-z0-9+-]+\/)?(?P[0-9]+)$')
 dr_regex = re.compile(r'\tDR ([0-9]+)$')
--
2.39.0



[PATCH (pushed)] gcc-changelog: allow digit in component name

2022-12-19 Thread Martin Liška

contrib/ChangeLog:

* gcc-changelog/git_commit.py: Allow digit in component name.

contrib/ChangeLog:

* gcc-changelog/test_email.py: Add new test.
* gcc-changelog/test_patches.txt: Add new patch.
---
 contrib/gcc-changelog/git_commit.py|  2 +-
 contrib/gcc-changelog/test_email.py|  4 
 contrib/gcc-changelog/test_patches.txt | 25 +
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index e82fbcacd3e..7fde02cba85 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -165,7 +165,7 @@ additional_author_regex = re.compile(r'^\t(?P\ 
*)?(?P.*  <.*>)')
 changelog_regex = re.compile(r'^(?:[fF]or +)?([a-z0-9+-/]*)ChangeLog:?')
 subject_pr_regex = 
re.compile(r'(^|\W)PR\s+(?P[a-zA-Z+-]+)/(?P\d{4,7})')
 subject_pr2_regex = re.compile(r'[(\[]PR\s*(?P\d{4,7})[)\]]')
-pr_regex = re.compile(r'\tPR (?P[a-z+-]+\/)?(?P[0-9]+)$')
+pr_regex = re.compile(r'\tPR (?P[a-z0-9+-]+\/)?(?P[0-9]+)$')
 dr_regex = re.compile(r'\tDR ([0-9]+)$')
 star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')
 end_of_location_regex = re.compile(r'[\[<(:]')
diff --git a/contrib/gcc-changelog/test_email.py 
b/contrib/gcc-changelog/test_email.py
index 79f8e0b8604..3e311d8d0f1 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -475,3 +475,7 @@ class TestGccChangelog(unittest.TestCase):
 assert (len(email.warnings) == 2)
 assert (email.warnings[0] == "Auto-added new file 'gcc/doc/gm2.texi'")
 assert (email.warnings[1] == "Auto-added 2 new files in 'gcc/m2'")
+
+def test_digit_in_PR_component(self):
+email = self.from_patch_glob('modula-PR-component.patch')
+assert not email.errors
diff --git a/contrib/gcc-changelog/test_patches.txt 
b/contrib/gcc-changelog/test_patches.txt
index 6004608a8f9..8bbd341c399 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -3732,3 +3732,28 @@ index 000..649af5e573a
 +GCC RUNTIME LIBRARY EXCEPTION
 --
 2.25.1
+
+=== modula-PR-component.patch ===
+From 1052d89a0b9769453561e18da32b1558d059b320 Mon Sep 17 00:00:00 2001
+From: Martin Liska 
+Date: Mon, 19 Dec 2022 14:34:18 +0100
+Subject: [PATCH] gcc-changelog: allow digit in component name
+
+   PR modula2/123456
+
+contrib/ChangeLog:
+
+   * gcc-changelog/git_commit.py: Allow digit in component name.
+---
+ contrib/gcc-changelog/git_commit.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
+index e82fbcacd3e..7fde02cba85 100755
+--- a/contrib/gcc-changelog/git_commit.py
 b/contrib/gcc-changelog/git_commit.py
+@@ -0,0 +1,1 @@
++  GNU Free Documentation License
+--
+2.39.0
+
--
2.39.0



[PATCH (pushed)] gcc-changelog: stop using --flake8

2022-12-19 Thread Martin Liška

The flake8 pytest plug-in is broken and we should not use it.

contrib/ChangeLog:

* gcc-changelog/setup.cfg: Do not use flake8 pytest plug-in.
---
 contrib/gcc-changelog/setup.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/gcc-changelog/setup.cfg b/contrib/gcc-changelog/setup.cfg
index efc313f6d52..a606029e25f 100644
--- a/contrib/gcc-changelog/setup.cfg
+++ b/contrib/gcc-changelog/setup.cfg
@@ -2,4 +2,4 @@
 max-line-length = 120
 
 [tool:pytest]

-addopts = -vv --flake8
+addopts = -vv
--
2.39.0



Re: new ubsan handler

2022-12-19 Thread Martin Liška

On 12/17/22 20:35, Martin Uecker wrote:



Hi all,

what is the process for adding a new UBsan handler?


Hello.

Yes, we sync the run-time library from LLVM project. So a new sanitizer
should go there first.



We have the source in the GCC tree, but I guess this
should go via LLVM?


And the compiler support (instrumentation) is independent.

Cheers,
Martin




Martin





Re: [Patch] gcc-changelog: Add warning for auto-added files

2022-12-16 Thread Martin Liška
On 12/16/22 13:33, Tobias Burnus wrote:
> Thus, the auto-add feature does not seem to be an often used feature - 
> neither on
> purpose nor accidentally. And glancing at the results, I think it was as 
> often used
> on purpose as it was used accidentally.

Hello.

Understood, I do support the newly added warning with a small patch tweak.

> 
> I was wondering whether the commit hook should print this warning/note or not.

I would print it.

> It can be helpful in case something too much got committed, but for the usual
> case that the file was missed, it simply comes too late. (Frankly, I don't
> know whether the hook currently runs with '-v' or not.)

Cheers,
Martindiff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index b9a60312099..e82fbcacd3e 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -22,6 +22,7 @@ import difflib
 import os
 import re
 import sys
+from collections import defaultdict
 
 default_changelog_locations = {
 'c++tools',
@@ -707,7 +708,7 @@ class GitCommit:
 msg += f' (did you mean "{candidates[0]}"?)'
 details = '\n'.join(difflib.Differ().compare([file], [candidates[0]])).rstrip()
 self.errors.append(Error(msg, file, details))
-auto_add_warnings = {}
+auto_add_warnings = defaultdict(list)
 for file in sorted(changed_files - mentioned_files):
 if not self.in_ignored_location(file):
 if file in self.new_files:
@@ -740,10 +741,7 @@ class GitCommit:
 file = file[len(entry.folder):].lstrip('/')
 entry.lines.append('\t* %s: New file.' % file)
 entry.files.append(file)
-if entry.folder not in auto_add_warnings:
-auto_add_warnings[entry.folder] = [file]
-else:
-auto_add_warnings[entry.folder].append(file)
+auto_add_warnings[entry.folder].append(file)
 else:
 msg = 'new file in the top-level folder not mentioned in a ChangeLog'
 self.errors.append(Error(msg, file))
@@ -763,11 +761,9 @@ class GitCommit:
 self.errors.append(Error(error, pattern))
 for entry, val in auto_add_warnings.items():
 if len(val) == 1:
-self.warnings.append('Auto-added new file \'%s/%s\''
- % (entry, val[0]))
+self.warnings.append(f"Auto-added new file '{entry}/{val[0]}'")
 else:
-self.warnings.append('Auto-added %d new files in \'%s\''
- % (len(val), entry))
+self.warnings.append(f"Auto-added {len(val)} new files in '{entry}'")
 
 def check_for_correct_changelog(self):
 for entry in self.changelog_entries:



  1   2   3   4   5   6   7   8   9   10   >