[r13-1268 Regression] FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++98 (test for excess errors) on Linux/x86_64
On Linux/x86_64,
8c99e307b20c502e55c425897fb3884ba8f05882 is the first bad commit
commit 8c99e307b20c502e55c425897fb3884ba8f05882
Author: Aldy Hernandez
Date: Sat Jun 25 18:58:02 2022 -0400
Convert DOM to use Ranger rather than EVRP
caused
FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++98 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r13-1268/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/warn/Wstringop-overflow-4.C
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/warn/Wstringop-overflow-4.C
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/warn/Wstringop-overflow-4.C
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/warn/Wstringop-overflow-4.C
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[PATCH] libgompd: Fixed Access bug
Hello, I referenced kind, nthread, and implicit as pointers in my last patch. This patch fixes this bug. We review patches and even the committed ones. Another thing, I didn't add gompd_thread_handle_access entries in the ChangeLog. libgomp/ChangeLog 2022-06-26 MohamedAtef * ompd-helper.c (gompd_is_final): Change is_ptr from 1 to 0 in ACCESS_VALUE. (gompd_is_implicit, and gompd_get_team_size): Likewise. Signed-off-by: Mohamed Atef diff --git a/libgomp/ompd-helper.c b/libgomp/ompd-helper.c index 9762b48dff8..ca05ed50c18 100644 --- a/libgomp/ompd-helper.c +++ b/libgomp/ompd-helper.c @@ -540,7 +540,7 @@ gompd_is_final (ompd_task_handle_t *task_handle, ompd_word_t *final_task) ompd_rc_t ret; /* gomp_task->final_task. */ ACCESS_VALUE (context, NULL, "gompd_access_gomp_task_final_task", temp_offset, - 1, ret, symbol_addr, temp_sym_addr, temp_addr); + 0, ret, symbol_addr, temp_sym_addr, temp_addr); DEREFERENCE (context, NULL, symbol_addr, target_sizes.sizeof_char, 1, res, ret, 0); *final_task = res; @@ -565,7 +565,7 @@ gompd_is_implicit (ompd_task_handle_t *task_handle, ompd_word_t *task_kind) ompd_address_space_context_t *context = task_handle->ah->context; ompd_rc_t ret; /* gomp_task->kind. */ - ACCESS_VALUE (context, NULL, "gompd_access_gomp_task_kind", temp_offset, 1, + ACCESS_VALUE (context, NULL, "gompd_access_gomp_task_kind", temp_offset, 0, ret, symbol_addr, temp_sym_addr, temp_addr); DEREFERENCE (context, NULL, symbol_addr, target_sizes.sizeof_int, 1, res, ret, 0); @@ -597,7 +597,7 @@ gompd_get_team_size (ompd_parallel_handle_t *parallel_handle, ompd_rc_t ret; /* gomp_team->nthreads. */ ACCESS_VALUE (context, NULL, "gompd_access_gomp_team_nthreads", temp_offset, - 1, ret, symbol_addr, temp_sym_addr, temp_addr); + 0, ret, symbol_addr, temp_sym_addr, temp_addr); DEREFERENCE (context, NULL, symbol_addr, target_sizes.sizeof_int, 1, res, ret, 0); *nthreads = res;
Pushed patch to convert DOM from EVRP to Ranger
This is 99.99% Aldy's work. My only real contribution was twiddling one MIPS specific test in response to a regression after adding this patch to my tester. In simplest terms, this patch converts DOM to use the Ranger infrastructure rather than the EVRP infrastructure. I'd basically approved it before Aldy went on PTO and it's been sitting in my tester ever since. So I figured it was time to go ahead and push it. Jeffcommit 8c99e307b20c502e55c425897fb3884ba8f05882 Author: Aldy Hernandez Date: Sat Jun 25 18:58:02 2022 -0400 Convert DOM to use Ranger rather than EVRP [Jeff, this is the same patch I sent you last week with minor tweaks to the commit message.] [Despite the verbosity of the message, this is actually a pretty straightforward patch. It should've gone in last cycle, but there was a nagging regression I couldn't get to until after stage1 had closed.] There are 3 uses of EVRP in DOM that must be converted. Unfortunately, they need to be converted in one go, so further splitting of this patch would be problematic. There's nothing here earth shattering. It's all pretty obvious in retrospect, but I've added a short description of each use to aid in reviewing: * Convert evrp use in cprop to ranger. This is easy, as cprop in DOM was converted to the ranger API last cycle, so this is just a matter of using a ranger instead of an evrp_range_analyzer. * Convert evrp use in threader to ranger. The idea here is to use the hybrid approach we used for the initial VRP threader conversion last cycle. The DOM threader will continue using the forward threader infrastructure while continuing to query DOM data structures, and only if the conditional does not relsolve, using the ranger. This gives us the best of both worlds, and is a proven approach. Furthermore, as frange and prange come live in the next cycle, we can move away from the forward threader altogether, and just add another backward threader. This will not only remove the last use of the forward threader, but will allow us to remove at least 1 or 2 threader instances. * Convert conditional folding to use the method used by the ranger and evrp. Previously DOM was calling into the guts of simplify_using_ranges::vrp_visit_cond_stmt. The blessed way now is using fold_cond() which rewrites the conditional and edges automatically. When legacy is removed, simplify_using_ranges will be further cleaned up, and there will only be one entry point into simplifying a statement. * DOM was setting global ranges determined from unreachable edges as a side-effect of using the evrp engine. We must handle these cases before nuking evrp, and DOM seems like a good fit. I've just moved the snippet to DOM, but it could live anywhere else we do a DOM walk. For the record, this is the case *vrp handled: : ... if (c_5(D) != 5) goto ; else goto ; : __builtin_unreachable (); : If M dominates all uses of c_5, we can set the global range of c_5 to [5,5]. I have tested on x86-64, pcc64le, and aarch64 Linux. I also ran threading benchmarks as well as performance benchmarks. DOM threads 1.56% more paths which ultimately yields a miniscule total increase of 0.03%. The conversion to ranger brings a 7.87% performance drop in DOM, which is a wash in overall compilation. This is in line with other replacements of legacy evrp with ranger. We handle a lot more cases. It's not free . There is a a regression on Wstringop-overflow-4.C which I'm planning on XFAILing. It's another variant of the usual middle-end false positives: having no ranges produces no warnings, but slightly refined ranges, or worse-- isolating specific problematic cases in the threader causes flare-ups. As an aside, as Richi has suggested, I think we should discuss restricting the threader's ability to thread highly unlikely paths. These cause no end of pain for middle-end warnings. However, I don't know if this would conflict with path isolation for things like null dereferencing. ISTR you were interested in this. BTW, I think the Wstringop-overflow-4.C test is problematic and I've attached my analysis. Basically the regression is caused by a bad interaction with the rounding/alignment that placement new has inlined into the IL. This happens for int16_r[] which the test is testing. Ranger can glean some range info, which causes DOM threading to isolate a path which causes a warning. OK for trunk? gcc/ChangeLog: *
[committed] Remove tile and tilegx ports
Per Martin's request. These were deprecated years ago, but not removed in a timely manner. I didn't remove any bits in runtimes where the canonical repository is elsewhere. Similarly I didn't remove any of the bits from config.guess and config.sub which we get from gnu-config. I did a sanity build on x86_64 just to verify I didn't muck anything up too badly (and yes, it did find a typo/thinko the first time). Installed on the trunk, Jeffcommit fc259b522c0f8b7bbca8e7adcd3da63330094a34 Author: Jeff Law Date: Sat Jun 25 12:36:55 2022 -0400 Remove long deprecated tilegx and tilepro ports / * MAINTAINERS: Remove tilegx and tilepro entries. * configure.ac: Remove tilegx and tilepro stanzas. * configure: Rebuilt. contrib/ * config-list.mk: Remove tilegx and tilepro entries. * gcc_update: Remove tilegx and tilepro entries. gcc/ * common/config/tilegx/tilegx-common.cc: Removed. * common/config/tilepro/tilepro-common.cc: Removed. * config.gcc: Remove tilegx and tilepro entries. * config/tilegx/constraints.md: Removed. * config/tilegx/feedback.h: Removed. * config/tilegx/linux.h: Removed. * config/tilegx/mul-tables.cc: Removed. * config/tilegx/predicates.md: Removed. * config/tilegx/sync.md: Removed. * config/tilegx/t-tilegx: Removed. * config/tilegx/tilegx-builtins.h: Removed. * config/tilegx/tilegx-c.cc: Removed. * config/tilegx/tilegx-generic.md: Removed. * config/tilegx/tilegx-modes.def: Removed. * config/tilegx/tilegx-multiply.h: Removed. * config/tilegx/tilegx-opts.h: Removed. * config/tilegx/tilegx-protos.h: Removed. * config/tilegx/tilegx.cc: Removed. * config/tilegx/tilegx.h: Removed. * config/tilegx/tilegx.md: Removed. * config/tilegx/tilegx.opt: Removed. * config/tilepro/constraints.md: Removed. * config/tilepro/feedback.h: Removed. * config/tilepro/gen-mul-tables.cc: Removed. * config/tilepro/linux.h: Removed. * config/tilepro/mul-tables.cc: Removed. * config/tilepro/predicates.md: Removed. * config/tilepro/t-tilepro: Removed. * config/tilepro/tilepro-builtins.h: Removed. * config/tilepro/tilepro-c.cc: Removed. * config/tilepro/tilepro-generic.md: Removed. * config/tilepro/tilepro-modes.def: Removed. * config/tilepro/tilepro-multiply.h: Removed. * config/tilepro/tilepro-protos.h: Removed. * config/tilepro/tilepro.cc: Removed. * config/tilepro/tilepro.h: Removed. * config/tilepro/tilepro.md: Removed. * config/tilepro/tilepro.opt: Removed. * configure.ac: Remove tilegx and tilepro entries. * configure: Rebuilt. * doc/extend.texi: Remove tilegx and tilepro entries. * doc/install.texi: Remove tilegx and tilepro entries. * doc/invoke.texi: Remove tilegx and tilepro entries. * doc/md.texi: Remove tilegx and tilepro entries. gcc/testsuite/ * gcc.dg/lower-subreg-1.c: Remove tilegx and tilepro entries. * gcc.misc-tests/linkage.exp: Remove tilegx and tilepro entries. libgcc/ * config.host: Removed tilegx and tilepro entries. * config/tilegx/sfp-machine.h: Removed. * config/tilegx/sfp-machine32.h: Removed. * config/tilegx/sfp-machine64.h: Removed. * config/tilegx/t-crtstuff: Removed. * config/tilegx/t-softfp: Removed. * config/tilegx/t-tilegx: Removed. * config/tilepro/atomic.c: Removed. * config/tilepro/atomic.h: Removed. * config/tilepro/linux-unwind.h: Removed. * config/tilepro/sfp-machine.h: Removed. * config/tilepro/softdivide.c: Removed. * config/tilepro/softmpy.S: Removed. * config/tilepro/t-crtstuff: Removed. * config/tilepro/t-tilepro: Removed.
Re: [PATCH] libgccjit: Fix bug where unary_op will return an integer type instead of the correct type
David: PING On Wed, 2022-06-01 at 22:45 -0400, Antoni Boucher wrote: > Also, the test gcc/testsuite/jit.dg/test-asm.cc fails and would need > this line: > > #include > > Is this okay if I add it in this patch? > > On Wed, 2022-06-01 at 22:13 -0400, Antoni Boucher wrote: > > Hi. > > The attached patch fix bug 105812: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812 > > > > I'm having an issue where contrib/check_GNU_style.sh doesn't seem > > to > > work, i.e. it doesn't seem to do any checking. > > Is there a new way to do that or am I missing something? > > > > Thanks for the review. >
[PATCH] testsuite, Darwin: Fix darwin-comm-1.c error messages for Darwin <= 10.
When amending the allowed alignment size to accommodate the larger values
permitted by newer tools, we retained the object file limit of 2^15 for
Darwin versions <= 10, since that is what the native tools expect there.
This triggers a different diagnostic path with a distinct error message,
which is checked in the revised test here.
Signed-off-by: Iain Sandoe
gcc/testsuite/ChangeLog:
* gcc.dg/darwin-comm-1.c: Check for the correct error message for
Darwin <= 10.
---
gcc/testsuite/gcc.dg/darwin-comm-1.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/darwin-comm-1.c
b/gcc/testsuite/gcc.dg/darwin-comm-1.c
index 46519984fd8..2ea11d63d81 100644
--- a/gcc/testsuite/gcc.dg/darwin-comm-1.c
+++ b/gcc/testsuite/gcc.dg/darwin-comm-1.c
@@ -1,5 +1,6 @@
-/* { dg-do compile { target *-*-darwin[912]* } } */
+/* { dg-do compile { target *-*-darwin* } } */
/* { dg-options "-fcommon" } */
/* In all cases, common has a max alignment of 2^15. */
-int badcommon __attribute__ ((aligned (65536))); /* { dg-error "common
variables must have an alignment" } */
+int badcommon __attribute__ ((aligned (65536))); /* { dg-error "common
variables must have an alignment" "" { target { *-*-darwin1[1-9]* *-*-darwin2*
} } } */
+/* { dg-error "requested alignment .65536. exceeds object file maximum 32768"
"" { target { *-*-darwin[4-9]* *-*-darwin10* } } .-1 } */
\ No newline at end of file
--
2.24.3 (Apple Git-128)
[PATCH][gdb/build] Fix gdbserver build with -fsanitize=thread
Hi,
When building gdbserver with -fsanitize=thread (added to CFLAGS/CXXFLAGS) we
run into:
...
ld: ../libiberty/libiberty.a(safe-ctype.o): warning: relocation against \
`__tsan_init' in read-only section `.text'
ld: ../libiberty/libiberty.a(safe-ctype.o): relocation R_X86_64_PC32 \
against symbol `__tsan_init' can not be used when making a shared object; \
recompile with -fPIC
ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[1]: *** [libinproctrace.so] Error 1
...
which looks similar to what is described in commit 78e49486944 ("[gdb/build]
Fix gdbserver build with -fsanitize=address").
The gdbserver component builds a shared library libinproctrace.so, which uses
libiberty and therefore requires the pic variant. The gdbserver Makefile is
setup to use this variant, if available, but it's not there.
Fix this by listing gdbserver in the toplevel configure alongside libcc1, as a
component that needs the libiberty pic variant, setting:
...
extra_host_libiberty_configure_flags=--enable-shared
...
Tested on x86_64-linux.
OK for trunk gcc?
Thanks,
- Tom
[gdb/build] Fix gdbserver build with -fsanitize=thread
---
configure| 2 +-
configure.ac | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 1badcb314f8..aac80b88d70 100755
--- a/configure
+++ b/configure
@@ -6964,7 +6964,7 @@ fi
extra_host_libiberty_configure_flags=
extra_host_zlib_configure_flags=
case " $configdirs " in
- *" lto-plugin "* | *" libcc1 "*)
+ *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
# When these are to be built as shared libraries, the same applies to
# libiberty.
extra_host_libiberty_configure_flags=--enable-shared
diff --git a/configure.ac b/configure.ac
index 5b6e2048514..29f74d10b5a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2344,7 +2344,7 @@ fi
extra_host_libiberty_configure_flags=
extra_host_zlib_configure_flags=
case " $configdirs " in
- *" lto-plugin "* | *" libcc1 "*)
+ *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
# When these are to be built as shared libraries, the same applies to
# libiberty.
extra_host_libiberty_configure_flags=--enable-shared
