[Bug target/102976] MMA test case emits wrong code when building a vector pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102976 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:7729d2c96d5eac9537c78d368bbc037bea13f988 commit r10-10399-g7729d2c96d5eac9537c78d368bbc037bea13f988 Author: Peter Bergner Date: Tue Nov 16 12:14:22 2021 -0600 rs6000: MMA test case emits wrong code when building a vector pair [PR102976] PR102976 shows a test case where we generate wrong code when building a vector pair from 2 vector registers. The bug here is that with unlucky register assignments, we can clobber one of the input operands before we write both registers of the output operand. The solution is to use early-clobbers in the assemble pair and accumulator patterns. 2021-11-16 Peter Bergner gcc/ PR target/102976 * config/rs6000/mma.md (*vsx_assemble_pair): Add early-clobber for output operand. (*mma_assemble_acc): Likewise. gcc/testsuite/ PR target/102976 * gcc.target/powerpc/pr102976.c: New test. (cherry picked from commit 4cdf7db9a39d18bd536d816a5751d4d3cf23808b)
[Bug c++/104040] New: linker: when exported template class from module is used in several .cpp with same tpl arg ~ undefined reference to not default non-inline destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104040
Bug ID: 104040
Summary: linker: when exported template class from module is
used in several .cpp with same tpl arg ~ undefined
reference to not default non-inline destructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sm0ke999 at yandex dot ru
Target Milestone: ---
Created attachment 52201
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52201=edit
-save-temps
There is minimal example of two files, using modules:
//lib.cpp
export module test;
export template
struct test {
T v_;
test(T v) : v_(v) {}
//inline
~test() {}
};
export struct omg {
using tt = test;
static tt go(tt t) {
return t;
}
};
//end
//main.cpp
import test;
int main() {
test t = false;
return 0;
}
//end
1. If we remove class omg then all compiles fine.
2. Or if we change "export struct omg { using tt = test;" to "export
struct omg { using tt = test;" then again all fine.
3. Or if we change "~test() {}" to "inline ~test() {}" then fine.
I think this problem related not only to just destructor, but to any not-inline
method in exported template class.
Here compile messages:
Perform "_build" task:
x86_64-w64-mingw32-g++.exe -v -save-temps -Wall -O3 -std=c++20 -m64 -c
D:\prog\Dropbox\cpp\vs-code/src/lib.cpp -o
D:\prog\Dropbox\cpp\vs-code/obj/src/lib.o -fmodules-ts
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++.exe
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-w64-mingw32
Configured with: ../configure
--prefix=/R/winlibs64_stage/inst_gcc-11.2.0/share/gcc
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64
x86_64-ucrt-posix-seh, built by Brecht Sanders' --with-tune=generic
--enable-checking=release --enable-threads=posix --disable-sjlj-exceptions
--disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap
--enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath
--enable-libstdcxx-pch --enable-libstdcxx-time=yes --disable-libstdcxx-debug
--disable-version-specific-runtime-libs --with-stabs --disable-symvers
--enable-languages=c,c++,fortran,lto,objc,obj-c++,d,jit --disable-gold
--disable-nls --disable-stage1-checking --disable-win32-registry
--disable-multilib --enable-ld --enable-libquadmath --enable-libada
--enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string
--enable-libgomp --enable-graphite --enable-mingw-wildcard
--with-mpc=/d/Prog/winlibs64_stage/custombuilt
--with-mpfr=/d/Prog/winlibs64_stage/custombuilt
--with-gmp=/d/Prog/winlibs64_stage/custombuilt
--with-isl=/d/Prog/winlibs64_stage/custombuilt --enable-install-libiberty
--enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto
--enable-clocale=generic --with-libiconv --with-system-zlib
--with-build-sysroot=/R/winlibs64_stage/gcc-11.2.0/build_mingw/mingw-w64
CFLAGS=-I/d/Prog/winlibs64_stage/custombuilt/include/libdl-win32
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-O3' '-std=c++20' '-m64' '-c'
'-o' 'D:\prog\Dropbox\cpp\vs-code/obj/src/lib.o' '-fmodules-ts'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir'
'D:\prog\Dropbox\cpp\vs-code/obj/src/'
d:/prog/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/cc1plus.exe -E
-quiet -v -iprefix d:\prog\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/
-D_REENTRANT D:\prog\Dropbox\cpp\vs-code/src/lib.cpp -m64 -mtune=generic
-march=x86-64 -std=c++20 -Wall -fmodules-ts -O3 -fpch-preprocess -o
D:\prog\Dropbox\cpp\vs-code/obj/src/lib.ii
ignoring duplicate directory
"d:/prog/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0"
ignoring duplicate directory
"d:/prog/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/x86_64-w64-mingw32"
ignoring duplicate directory
"d:/prog/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/backward"
ignoring duplicate directory
"d:/prog/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/include"
ignoring nonexistent directory
"R:/winlibs64_stage/inst_gcc-11.2.0/share/gcc/include"
ignoring nonexistent directory
"/R/winlibs64_stage/inst_gcc-11.2.0/share/gcc/include"
ignoring duplicate directory
"d:/prog/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/include-fixed"
ignoring duplicate directory
"d:/prog/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include
Re: [PATCH v2 RFA] diagnostic: avoid repeating include path
On 1/13/22 17:30, David Malcolm wrote:
On Thu, 2022-01-13 at 17:08 -0500, Jason Merrill wrote:
When a sequence of diagnostic messages bounces back and forth
repeatedly
between two includes, as with
#include
std::map m ("123", "456");
The output is quite a bit longer than necessary because we dump the
include
path each time it changes. I'd think we could print the include path
once
for each header file, and then expect that the user can look earlier
in the
output if they're wondering.
Tested x86_64-pc-linux-gnu, OK for trunk?
gcc/ChangeLog:
* diagnostic.c (includes_seen): New.
(diagnostic_report_current_module): Use it.
---
gcc/diagnostic.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 58139427d01..e56441a2dbf 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -700,6 +700,16 @@ set_last_module (diagnostic_context *context,
const line_map_ordinary *map)
context->last_module = map;
}
+/* Only dump the "In file included from..." stack once for each
file. */
+
+static bool
+includes_seen (const line_map_ordinary *map)
+{
+ using hset = hash_set;
+ static hset *set = new hset;
+ return set->add (map);
+}
Overall, I like the idea, but...
- the patch works at the level of line_map_ordinary instances, rather
than header files. There are various ways in which a single header
file can have multiple line maps e.g. due to very long lines, or
including another file, etc. I think it makes sense to do it at the
per-file level, assuming we aren't in a horrible situation where a
header is being included repeatedly, with different effects. So maybe
this ought to look at what include directive led to this map, i.e.
looking at the ord_map->included_from field, and having a
hash_set ?
Done. This version doesn't affect printing of the module import path
yet, pending more consideration of whether we always want to identify
the module it comes from or just the file/line is enough.
- there's no test coverage, but it's probably not feasible to write
DejaGnu tests for this, given the way prune.exp's prune_gcc_output
strips these strings. Maybe a dg directive to selectively disable the
pertinent pruning operations in prune_gcc_output??? Gah...
- global state is a pet peeve of mine; can the above state be put
inside the diagnostic_context instead? (perhaps via a pointer to a
wrapper class to avoid requiring all users of diagnostic.h to include
hash-set.h?).
It seems that using hash_set directly doesn't break any users.
From a6137bc1154bdf237449382f98cd3945a701103f Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Fri, 17 Dec 2021 05:45:02 -0500
Subject: [PATCH] diagnostic: avoid repeating include path
To: gcc-patches@gcc.gnu.org
When a sequence of diagnostic messages bounces back and forth repeatedly
between two includes, as with
#include
std::map m ("123", "456");
The output is quite a bit longer than necessary because we dump the include
path each time it changes. I'd think we could print the include path once
for each header file, and then expect that the user can look earlier in the
output if they're wondering.
gcc/ChangeLog:
* diagnostic.h (struct diagnostic_context): Add includes_seen.
* diagnostic.c (diagnostic_initialize): Initialize it.
(diagnostic_finish): Clean it up.
(includes_seen): New function.
(diagnostic_report_current_module): Use it.
gcc/testsuite/ChangeLog:
* c-c++-common/cpp/line-2.c: Only expect includes once.
* c-c++-common/cpp/line-3.c: Likewise.
---
gcc/diagnostic.h| 4 +++
gcc/diagnostic.c| 36 +++--
gcc/testsuite/c-c++-common/cpp/line-2.c | 2 +-
gcc/testsuite/c-c++-common/cpp/line-3.c | 2 +-
4 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/gcc/diagnostic.h b/gcc/diagnostic.h
index 6739028a931..ccaa33b5817 100644
--- a/gcc/diagnostic.h
+++ b/gcc/diagnostic.h
@@ -387,6 +387,10 @@ struct diagnostic_context
the BLOCK_SUPERCONTEXT() chain hanging off the LOCATION_BLOCK()
of a diagnostic's location. */
void (*set_locations_cb)(diagnostic_context *, diagnostic_info *);
+
+ /* Include files that diagnostic_report_current_module has already listed the
+ include path for. */
+ hash_set *includes_seen;
};
static inline void
diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 58139427d01..5c02ff05882 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -237,6 +237,7 @@ diagnostic_initialize (diagnostic_context *context, int n_opts)
context->begin_group_cb = NULL;
context->end_group_cb = NULL;
context->final_cb = default_diagnostic_final_cb;
+ context->includes_seen = NULL;
}
/* Maybe initialize the color support. We require clients to do this
@@ -329,6 +330,12 @@ diagnostic_finish (diagnostic_context *context)
delete context->edit_context_ptr;
context->edit_context_ptr = NULL;
}
+
+ if
Re: [PATCH v3 RFC] c++: add color to function decl printing
On 1/14/22 16:49, David Malcolm wrote:
On Mon, 2021-12-13 at 09:58 -0500, Jason Merrill via Gcc-patches wrote:
On 12/13/21 06:02, Jonathan Wakely wrote:
On Sun, 12 Dec 2021 at 05:39, Jason Merrill mailto:ja...@redhat.com>> wrote:
>
> In reading C++ diagnostics, it's often hard to find the name of
the
function
> in the middle of the template header, return type, parameters, and
template
> arguments. So let's colorize it, and maybe the template argument
bindings
> while we're at it.
Thanks for the patch; sorry for not responding before.
Overall I like that patch, with some reservations...
>
> I've somewhat arbitrarily chosen bold green for the function name,
and
> non-bold magenta for the template arguments. I'm not at all
attached to
> these choices.
I tried the patch with gnome terminals "light" and "dark" themes, and
the colors seemed readable with both color schemes.
>
> A side-effect is that when this happens in a quote (i.e. %qD), the
> rest of the quote after the function name is no longer bold. I
think
that's
> acceptable; returning to the bold would require maintaining a
colorize stack
> instead of the on/off controls we have now.
I was going to grumble about this, but having tried it on some
examples, I think it's actually an improvement in readability to drop
the emboldening, in that it reduces the "wall of bold text" seen.
Having tried it on some examples, I think the patch as a whole is a
definite readability win, in that it breaks up long stretches of bold
text into useful colorized parts; the result seems much easier to
decipher at a glance. I wonder to what extent this is a poor-man's
syntax highlighting?
I think it definitely is. Going farther in that direction would make
sense it future.
Did you try any other variants of the highlighting? This approach
seems to work well, FWIW, I wonder if others might work better, or if
this is a local maxima in terms of readability.
Do you have any particular variants in mind? This was motivated by my
having trouble finding the name of the function in diagnostic output, so
that's the main thing I wanted to highlight.
I'm taking the liberty of attaching a screenshot (137K) showing
before/after the patch for the sake of discussion.
>
> Any thoughts?
I was also concerned about how this would interact with the template
type diff printing from f012c8ef4b35dcee9b5a3807868d050812d5b3b9, but I
did a few tests and it seems to work OK.
I only tested in lightly for a few minutes, so it could do with some
more testing.
I thought I was going to love this ... and it's a nice little
improvement, but I didn't love it as much as I expected.
Is it intentional that only the last function in the instantiation
stack
gets colourized? In this example the function on line 390 isn't
highlighted:
/home/jwakely/gcc/12/include/c++/12.0.0/bits/ranges_base.h:390:12:
required
by substitution of 'template requires
(is_bounded_array_v::type>) ||
(__member_size*<_Tp>) || (__adl_size<_Tp>) ||
(__sentinel_size<_Tp>)
constexpr auto std::ranges::__cust_access::_Size::operator()(_Tp&&)
const [with _Tp = adl::Footie (&)[]]*'
Oops, I needed to change subst_to_string as well. Updated patch
below.
Jonathan, did you try the v2 patch?
Aside: it's a little odd that the first caret diagnostic there only
highlights the word "operator" and not the name of the function,
"operator()".
Yes, I imagine we need to adjust DECL_SOURCE_LOCATION to use a range
instead of assuming the location of the first token is sufficient.
Jason
[...]
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 9b4371b9213..cdfddd75343 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4803,6 +4803,14 @@ SGR substring for location information,
@samp{file:line} or
@vindex quote GCC_COLORS @r{capability}
SGR substring for information printed within quotes.
+@item fnname=
+@vindex fnname GCC_COLORS @r{capability}
+SGR substring for names of C++ functions.
+
+@item targs=
+@vindex targs GCC_COLORS @r{capability}
+SGR substring for C++ function template parameter bindings.
+
@item fixit-insert=
@vindex fixit-insert GCC_COLORS @r{capability}
SGR substring for fix-it hints suggesting text to
There's a section of the docs for -fdiagnostics-color a little above
this, starting
"The default @env{GCC_COLORS} is"
which needs to be updated whenever we add new color capabilities.
Fixed.
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 323643d1e6f..0008ee2ee8d 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -1,4 +1,4 @@
-/* Call-backs for C++ error reporting.
+/* Call-backs for -*- C++ -*- error reporting.
This change isn't called out in the ChangeLog. Is it deliberate?
Yes, an incidental change to tell emacs that it's a C++ source file
despite the .c suffix. Probably not important, since it seems we're
about to rename the .c files.
[...]
@@ -1158,6 +1163,22 @@ dump_simple_decl
[Bug target/104039] AArch64 Redundant instruction moving general to vector register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104039
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed||2022-01-15
Ever confirmed|0 |1
Target||aarch64
Keywords||ra
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed.
The problem is the register allocator.
It goes from:
(insn 18 10 19 2 (set (reg:DI 99)
(reg:DI 0 x0 [ a ])) "/app/example.cpp":4:49 53 {*movdi_aarch64}
(expr_list:REG_DEAD (reg:DI 0 x0 [ a ])
(nil)))
(insn 19 18 8 2 (set (reg:DI 100)
(reg:DI 1 x1 [ b ])) "/app/example.cpp":4:49 53 {*movdi_aarch64}
(expr_list:REG_DEAD (reg:DI 1 x1 [ b ])
(nil)))
(insn 8 19 15 2 (set (reg:V2DI 95 [ a ])
(subreg:V2DI (reg:DI 99) 0)) "/app/example.cpp":5:16 1206
{*aarch64_simd_movv2di}
(expr_list:REG_DEAD (reg:DI 99)
(nil)))
To:
(insn 8 10 15 2 (set (reg:V2DI 32 v0 [orig:95 a ] [95])
(reg:V2DI 0 x0 [99])) "/app/example.cpp":5:16 1206
{*aarch64_simd_movv2di}
(nil))
And then that gets split into:
(insn 22 10 23 2 (set (reg:V2DI 32 v0 [orig:95 a ] [95])
(vec_concat:V2DI (reg:DI 0 x0 [99])
(const_int 0 [0]))) "/app/example.cpp":5:16 1919
{move_lo_quad_internal_v2di}
(nil))
(insn 23 22 15 2 (set (reg:V2DI 32 v0 [orig:95 a ] [95])
(vec_concat:V2DI (vec_select:DI (reg:V2DI 32 v0 [orig:95 a ] [95])
(parallel:V2DI [
(const_int 0 [0])
]))
(reg:DI 1 x1 [+8 ]))) "/app/example.cpp":5:16 1932
{aarch64_simd_move_hi_quad_v2di}
(nil))
Maybe we should have done the expansion to use an fmov in the first place via a
special pattern which then gets expanded correctly might be better, I don't
know.
[Bug target/104039] New: AArch64 Redundant instruction moving general to vector register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104039
Bug ID: 104039
Summary: AArch64 Redundant instruction moving general to vector
register
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
Compiling the following code on AArch64 with -O2 or -O3:
typedef unsigned long u64x2 __attribute__((vector_size(16)));
u64x2 combine(unsigned long a, unsigned long b) {
u64x2 v = {a,b};
return v;
}
yields the following assembly:
combine:
fmovd0, x0
ins v0.d[1], x1
ins v0.d[1], x1
ret
where the second ins is entirely redundant with the first and serves no
apparent purpose. (Unless it is something extremely clever...)
This seems to be a regression from 8.x to 9.x; Godbolt's 8.5 looks correct with
just one ins, but 9.3 has the two.
Originally noticed by Peter Cordes on StackOverflow:
https://stackoverflow.com/questions/70717360/how-to-load-vector-registers-from-integer-registers-in-arm64-m1/70718572#comment125016906_70717360
[PATCH] libstdc++: Add missing free functions for atomic_flag [PR103934]
From c2b74fd7cf2668d288f46da42565e5eb954e5e1f Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Fri, 14 Jan 2022 18:30:27 -0800
Subject: [PATCH] libstdc++: Add missing free functions for atomic_flag
[PR103934]
libstdc++-v3/ChangeLog:
PR103934
* include/std/atomic: Add missing free functions.
* testsuite/29_atomics/atomic_flag/wait_notify/1.cc:
Add test case to cover missing atomic_flag free functions.
---
libstdc++-v3/include/std/atomic | 39 +++
.../29_atomics/atomic_flag/wait_notify/1.cc | 27 +++--
2 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 9df17704f7e..92c96a9b047 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -1216,6 +1216,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
memory_order __m) noexcept
{ return __a->test_and_set(__m); }
+#if __cpp_lib_atomic_flag_test
+ inline bool
+ atomic_flag_test(const atomic_flag* __a) noexcept
+ { return __a->test(); }
+
+ inline bool
+ atomic_flag_test(const volatile atomic_flag* __a) noexcept
+ { return __a->test(); }
+
+ inline bool
+ atomic_flag_test_explicit(const atomic_flag* __a,
+ memory_order __m) noexcept
+ { return __a->test(__m); }
+
+ inline bool
+ atomic_flag_test_explicit(const volatile atomic_flag* __a,
+ memory_order __m) noexcept
+ { return __a->test(__m); }
+#endif
+
inline void
atomic_flag_clear_explicit(atomic_flag* __a, memory_order __m) noexcept
{ __a->clear(__m); }
@@ -1241,6 +1261,25 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
atomic_flag_clear(volatile atomic_flag* __a) noexcept
{ atomic_flag_clear_explicit(__a, memory_order_seq_cst); }
+#if __cpp_lib_atomic_wait
+ inline void
+ atomic_flag_wait(const atomic_flag* __a, bool __old) noexcept
+ { __a->wait(__old); }
+
+ inline void
+ atomic_flag_wait_explicit(const atomic_flag* __a, bool __old,
+ std::memory_order __m) noexcept
+ { __a->wait(__old, __m); }
+
+ inline void
+ atomic_flag_notify_one(const atomic_flag* __a) noexcept
+ { __a->notify_one(); }
+
+ inline void
+ atomic_flag_notify_all(const atomic_flag* __a) noexcept
+ { __a->notify_all(); }
+#endif // __cpp_lib_atomic_wait
+
template
using __atomic_val_t = typename atomic<_Tp>::value_type;
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_flag/wait_notify/1.cc b/libstdc++-v3/testsuite/29_atomics/atomic_flag/wait_notify/1.cc
index 87a104059ff..1050b72a1c6 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/wait_notify/1.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/wait_notify/1.cc
@@ -26,8 +26,8 @@
#include
-int
-main()
+void
+test01()
{
std::atomic_flag a;
VERIFY( !a.test() );
@@ -39,5 +39,26 @@ main()
});
a.wait(false);
t.join();
- return 0;
+}
+
+void
+test02()
+{
+ std::atomic_flag a;
+ VERIFY( !std::atomic_flag_test() );
+ std::atomic_flag_wait(, true);
+ std::thread t([&]
+{
+ std::atomic_flag_test_and_set();
+ std::atomic_flag_notify_one();
+});
+ std::atomic_flag_wait(, false);
+ t.join();
+}
+
+int
+main()
+{
+ test01();
+ test02();
}
--
2.31.1
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 --- Comment #26 from Andrew Pinski --- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |5.0
[Bug target/104028] M68k: Error: value -16034 out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104028 --- Comment #10 from Giulio Benetti --- Ah, forgot to mention that it builds fine with -O0.
[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101715 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #17 from Marek Polacek --- Patch posted https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588520.html
[PATCH] c++: ICE with noexcept and canonical types [PR101715]
This is a "canonical types differ for identical types" ICE, which started
with r11-4682. It's a bit tricky to explain. Consider:
template struct S {
S bar() noexcept(T::value); // #1
S foo() noexcept(T::value); // #2
};
template S S::foo() noexcept(T::value) {} // #3
We ICE because #3 and #2 have the same type, but their canonical types
differ: TYPE_CANONICAL (#3) == #2 but TYPE_CANONICAL (#2) == #1.
The member functions #1 and #2 have the same type. However, since their
noexcept-specifier is deferred, when parsing them, we create a variant for
both of them, because DEFERRED_PARSE cannot be compared. In other words,
build_cp_fntype_variant's
tree v = TYPE_MAIN_VARIANT (type);
for (; v; v = TYPE_NEXT_VARIANT (v))
if (cp_check_qualified_type (v, type, type_quals, rqual, raises, late))
return v;
will *not* find an existing variant when creating a method_type for #2, so we
have to create a new one.
But then we perform delayed parsing and call fixup_deferred_exception_variants
for #1 and #2. f_d_e_v will replace TYPE_RAISES_EXCEPTIONS with the newly
parsed noexcept-specifier. It also sets TYPE_CANONICAL (#2) to #1. Both
noexcepts turned out to be the same, so now we have two equivalent variants in
the list! I.e.,
+-+ +-+ +-+
| main | | #2 | | #1 |
| S S::(S*) |->| S S::(S*) |->| S S::(S*) |->NULL
|-| | noex(T::value) | | noex(T::value) |
+-+ +-+ +-+
Then we get to #3. As for #1 and #2, grokdeclarator calls build_memfn_type,
which ends up calling build_cp_fntype_variant, which will use the loop
above to look for an existing variant. The first one that matches
cp_check_qualified_type will be used, so we use #2 rather than #1, and the
TYPE_CANONICAL mismatch follows. Hopefully that makes sense.
As for the fix, I didn't think I could rewrite the method_type #2 with #1
because the type may have escaped via decltype. So my approach is to
elide #2 from the list, so when looking for a matching variant, we always
find #1 (#2 remains live though, which admittedly sounds sort of dodgy).
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11?
PR c++/101715
gcc/cp/ChangeLog:
* tree.c (fixup_deferred_exception_variants): Remove duplicate
variants after parsing the exception specifications.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept72.C: New test.
* g++.dg/cpp0x/noexcept73.C: New test.
---
gcc/cp/tree.c | 16 +++-
gcc/testsuite/g++.dg/cpp0x/noexcept72.C | 21 +
gcc/testsuite/g++.dg/cpp0x/noexcept73.C | 13 +
3 files changed, 49 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept72.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept73.C
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 7f7de86b4e8..2efad49e7c1 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -2804,8 +2804,9 @@ fixup_deferred_exception_variants (tree type, tree raises)
/* Though sucky, this walk will process the canonical variants
first. */
+ tree prev = NULL_TREE;
for (tree variant = TYPE_MAIN_VARIANT (type);
- variant; variant = TYPE_NEXT_VARIANT (variant))
+ variant; prev = variant, variant = TYPE_NEXT_VARIANT (variant))
if (TYPE_RAISES_EXCEPTIONS (variant) == original)
{
gcc_checking_assert (variant != TYPE_MAIN_VARIANT (type));
@@ -2827,6 +2828,19 @@ fixup_deferred_exception_variants (tree type, tree
raises)
v = build_cp_fntype_variant (TYPE_CANONICAL (variant),
rqual, cr, false);
TYPE_CANONICAL (variant) = v;
+
+ /* If VARIANT became a duplicate (cp_check_qualified_type-wise)
+ of an existing variant in the variant list of TYPE after we
+ have parsed its exception specification, elide it. Otherwise,
+ build_cp_fntype_variant would use it, leading to "canonical
+ types differ for identical types." */
+ for (v = TYPE_MAIN_VARIANT (type); v; v = TYPE_NEXT_VARIANT (v))
+ if (v != variant
+ /* The main variant will not have TYPE_RAISES_EXCEPTIONS
+so PREV should never be null. */
+ && cp_check_qualified_type (v, variant, var_quals,
+ rqual, cr, false))
+ TYPE_NEXT_VARIANT (prev) = TYPE_NEXT_VARIANT (variant);
}
else
TYPE_RAISES_EXCEPTIONS (variant) = raises;
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept72.C
b/gcc/testsuite/g++.dg/cpp0x/noexcept72.C
new file mode 100644
index 000..f1455b3b46b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept72.C
@@ -0,0 +1,21 @@
+// PR c++/101715
+// {
[Bug fortran/103782] [9/10/11/12 Regression] internal error occurs when overloading intrinsic since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782 --- Comment #6 from urbanjost at comcast dot net --- Thanks for the quick response! Fantastic! That gets me below a dozen bug reports. I'll have to go break something new :> g95/gfortran saved fortran IMHO. Thanks to all the gfortran heroes out there, past and present. > On 01/14/2022 1:22 PM cvs-commit at gcc dot gnu.org > wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782 > > --- Comment #5 from CVS Commits --- > The master branch has been updated by Harald Anlauf : > > https://gcc.gnu.org/g:a4a8ae123cd70188e4b4bf5e288a84e0a76fb0fd > > commit r12-6593-ga4a8ae123cd70188e4b4bf5e288a84e0a76fb0fd > Author: Harald Anlauf > Date: Thu Jan 13 21:50:45 2022 +0100 > > Fortran: fix ICE overloading elemental intrinsics > > gcc/fortran/ChangeLog: > > PR fortran/103782 > * expr.c (gfc_simplify_expr): Adjust logic for when to scalarize a > call of an intrinsic which may have been overloaded. > > gcc/testsuite/ChangeLog: > > PR fortran/103782 > * gfortran.dg/overload_4.f90: New test. > > -- > You are receiving this mail because: > You reported the bug.
[Bug tree-optimization/104038] ranger infinite loop on a PHI statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103464 --- Comment #6 from Andrew Pinski --- And PR 103464.
[Bug tree-optimization/104038] ranger infinite loop on a PHI statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103603 --- Comment #5 from Andrew Pinski --- Similar to PR 103603.
[Bug target/104028] M68k: Error: value -16034 out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104028 --- Comment #9 from Andreas Schwab --- It's a duplicated case vector load, where the second one is placed far off from its table.
[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031
--- Comment #6 from Sergei Trofimovich ---
> void __static_initialization_and_destruction_0 (int __initialize_p, int
> __priority)
> {
> struct InfoD.2399 D.2453 = {.arityD.2402=0};
Having poked at -fdump-tree-all-raw I now think `= {.arityD.2402=0};` is not a
variable initialization itself, but a reference to `DECL_INITIAL` that would do
an initialization.
Perhaps something was supposed to expand this `DECL_INITIAL` to an actual
initializing statement, but did not for this case.
[Bug analyzer/103892] -Wanalyzer-double-free false positive when compiling libpipeline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-01-14 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this; it does indeed look like a false positive. I can reproduce it with trunk; will investigate further.
[committed] ada: Fix up handling of ghost units [PR104027]
Hi! As reported, libgnat-12.so gets PT_GNU_STACK RWE, which means it doesn't work in some SELinux configurations. This is caused by the a-nbnbig.o file, which is a ghost unit and since r12-5670 the FE emits an object file for it, but exits before compile_file has a chance to finalize it e.g. with targetm.asm_out.file_end () that emits the .note.GNU-stack section on various linux targets. Fixed by not existing but instead returning early to the caller. Bootstrapped/regtested on x86_64-linux, preapproved in the PR, committed to trunk. 2022-01-14 Andrew Pinski PR ada/104027 * gnat1drv.adb (Gnat1drv): After Back_End.Gen_Or_Update_Object_File goto End_Of_Program. --- gcc/ada/gnat1drv.adb +++ gcc/ada/gnat1drv.adb @@ -1429,6 +1429,11 @@ begin Ecode := E_Success; Back_End.Gen_Or_Update_Object_File; +-- Use a goto instead of calling Exit_Program so that finalization +-- occurs normally. + +goto End_Of_Program; + -- Otherwise the unit is missing a crucial piece that prevents code -- generation. Jakub
[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104027 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:952b7dbb418198f86d7829aaf9d7f9fc7714a8b3 commit r12-6599-g952b7dbb418198f86d7829aaf9d7f9fc7714a8b3 Author: Andrew Pinski Date: Fri Jan 14 23:58:38 2022 +0100 ada: Fix up handling of ghost units [PR104027] As reported, libgnat-12.so gets PT_GNU_STACK RWE, which means it doesn't work in some SELinux configurations. This is caused by the a-nbnbig.o file, which is a ghost unit and since r12-5670 the FE emits an object file for it, but exits before compile_file has a chance to finalize it e.g. with targetm.asm_out.file_end () that emits the .note.GNU-stack section on various linux targets. Fixed by not existing but instead returning early to the caller. 2022-01-14 Andrew Pinski PR ada/104027 * gnat1drv.adb (Gnat1drv): After Back_End.Gen_Or_Update_Object_File goto End_Of_Program.
[Bug analyzer/104029] [12 Regression] ICE with -fanalyzer-checker=taint since r12-5230-gb9365b93212041f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104029 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from David Malcolm --- Should be fixed by the above commit.
Re: [committed] analyzer: fix ICE in taint checker on unary ops [PR104029]
On Fri, 2022-01-14 at 17:53 -0500, David Malcolm wrote: > gcc/analyzer/ChangeLog: > PR analyzer/104029 > * sm-taint.cc (taint_state_machine::alt_get_inherited_state): > Remove gcc_unreachable from default case for unary ops. > > gcc/testsuite/ChangeLog: > PR analyzer/104029 > * gcc.dg/analyzer/pr104029.c: New test. > * gcc.dg/analyzer/taint-ops.c: New test. Forgot to add: Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r12-6597-g8931adfa0530590d21e74e5c7a1f8d26df575775. [...snip...]
[PATCH] widening_mul, i386: Improve spaceship expansion on x86 [PR103973]
Hi!
C++20:
#include
auto cmp4way(double a, double b)
{
return a <=> b;
}
expands to:
ucomisd %xmm1, %xmm0
jp .L8
movl$0, %eax
jne .L8
.L2:
ret
.p2align 4,,10
.p2align 3
.L8:
comisd %xmm0, %xmm1
movl$-1, %eax
ja .L2
ucomisd %xmm1, %xmm0
setbe %al
addl$1, %eax
ret
That is 3 comparisons of the same operands.
The following patch improves it to just one comparison:
comisd %xmm1, %xmm0
jp .L4
seta%al
movl$0, %edx
leal-1(%rax,%rax), %eax
cmove %edx, %eax
ret
.L4:
movl$2, %eax
ret
While a <=> b expands to a == b ? 0 : a < b ? -1 : a > b ? 1 : 2
where the first comparison is equality and this shouldn't raise
exceptions on qNaN operands, if the operands aren't equal (which
includes unordered cases), then it immediately performs < or >
comparison and that raises exceptions even on qNaNs, so we can just
perform a single comparison that raises exceptions on qNaN.
As the 4 different cases are encoded as
ZF CF PF
1 1 1 a unordered b
0 0 0 a > b
0 1 0 a < b
1 0 0 a == b
we can emit optimal sequence of comparions, first jp
for the unordered case, then je for the == case and finally jb
for the < case.
The patch pattern recognizes spaceship-like comparisons during
widening_mul if the spaceship optab is implemented, and replaces
thoose comparisons with comparisons of .SPACESHIP ifn which returns
-1/0/1/2 based on the comparison. This seems to work well both for the
case of just returning the -1/0/1/2 (when we have just a common
successor with a PHI) or when the different cases are handled with
various other basic blocks. The testcases cover both of those cases,
the latter with different function calls in those.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2022-01-14 Jakub Jelinek
PR target/103973
* tree-cfg.h (cond_only_block_p): Declare.
* tree-ssa-phiopt.c (cond_only_block_p): Move function to ...
* tree-cfg.c (cond_only_block_p): ... here. No longer static.
* optabs.def (spaceship_optab): New optab.
* internal-fn.def (SPACESHIP): New internal function.
* internal-fn.h (expand_SPACESHIP): Declare.
* internal-fn.c (expand_PHI): Formatting fix.
(expand_SPACESHIP): New function.
* tree-ssa-math-opts.c (optimize_spaceship): New function.
(math_opts_dom_walker::after_dom_children): Use it.
* config/i386/i386.md (spaceship3): New define_expand.
* config/i386/i386-protos.h (ix86_expand_fp_spaceship): Declare.
* config/i386/i386-expand.c (ix86_expand_fp_spaceship): New function.
* doc/md.texi (spaceship@var{m}3): Document.
* gcc.target/i386/pr103973-1.c: New test.
* gcc.target/i386/pr103973-2.c: New test.
* gcc.target/i386/pr103973-3.c: New test.
* gcc.target/i386/pr103973-4.c: New test.
* g++.target/i386/pr103973-1.C: New test.
* g++.target/i386/pr103973-2.C: New test.
* g++.target/i386/pr103973-3.C: New test.
* g++.target/i386/pr103973-4.C: New test.
--- gcc/tree-cfg.h.jj 2022-01-13 22:29:07.414943450 +0100
+++ gcc/tree-cfg.h 2022-01-14 12:59:42.147866622 +0100
@@ -111,6 +111,7 @@ extern basic_block gimple_switch_label_b
extern basic_block gimple_switch_default_bb (function *, gswitch *);
extern edge gimple_switch_edge (function *, gswitch *, unsigned);
extern edge gimple_switch_default_edge (function *, gswitch *);
+extern bool cond_only_block_p (basic_block);
/* Return true if the LHS of a call should be removed. */
--- gcc/tree-ssa-phiopt.c.jj2022-01-13 22:29:07.514942041 +0100
+++ gcc/tree-ssa-phiopt.c 2022-01-14 12:59:42.146866637 +0100
@@ -1958,31 +1958,6 @@ minmax_replacement (basic_block cond_bb,
return true;
}
-/* Return true if the only executable statement in BB is a GIMPLE_COND. */
-
-static bool
-cond_only_block_p (basic_block bb)
-{
- /* BB must have no executable statements. */
- gimple_stmt_iterator gsi = gsi_after_labels (bb);
- if (phi_nodes (bb))
-return false;
- while (!gsi_end_p (gsi))
-{
- gimple *stmt = gsi_stmt (gsi);
- if (is_gimple_debug (stmt))
- ;
- else if (gimple_code (stmt) == GIMPLE_NOP
- || gimple_code (stmt) == GIMPLE_PREDICT
- || gimple_code (stmt) == GIMPLE_COND)
- ;
- else
- return false;
- gsi_next ();
-}
- return true;
-}
-
/* Attempt to optimize (x <=> y) cmp 0 and similar comparisons.
For strong ordering <=> try to match something like:
: // cond3_bb (== cond2_bb)
--- gcc/tree-cfg.c.jj 2022-01-13 22:29:07.399943661 +0100
+++ gcc/tree-cfg.c 2022-01-14 12:59:42.148866608 +0100
@@ -9410,6 +9410,31 @@ gimple_switch_default_edge (function *if
return gimple_switch_edge (ifun, gs, 0);
}
[committed] analyzer: fix ICE when combining taint states has_ub and has_lb
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as cc3b67e40140ec79f86e79a96d7fdd169b84faaf.
gcc/analyzer/ChangeLog:
* sm-taint.cc (taint_state_machine::combine_states): Handle combination
of has_ub and has_lb.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/taint-merger.c: New test.
---
gcc/analyzer/sm-taint.cc | 14 +++--
gcc/testsuite/gcc.dg/analyzer/taint-merger.c | 57
2 files changed, 66 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/taint-merger.c
diff --git a/gcc/analyzer/sm-taint.cc b/gcc/analyzer/sm-taint.cc
index 3a46256b020..357456593ff 100644
--- a/gcc/analyzer/sm-taint.cc
+++ b/gcc/analyzer/sm-taint.cc
@@ -860,15 +860,19 @@ taint_state_machine::combine_states (state_t s0, state_t
s1) const
return s0;
if (s0 == m_tainted || s1 == m_tainted)
return m_tainted;
- if (s0 == m_stop)
-return s1;
- if (s1 == m_stop)
-return s0;
if (s0 == m_start)
return s1;
if (s1 == m_start)
return s0;
- gcc_unreachable ();
+ if (s0 == m_stop)
+return s1;
+ if (s1 == m_stop)
+return s0;
+ /* The only remaining combinations are one of has_ub and has_lb
+ (in either order). */
+ gcc_assert ((s0 == m_has_lb && s1 == m_has_ub)
+ || (s0 == m_has_ub && s1 == m_has_lb));
+ return m_tainted;
}
/* Check for calls to external functions marked with
diff --git a/gcc/testsuite/gcc.dg/analyzer/taint-merger.c
b/gcc/testsuite/gcc.dg/analyzer/taint-merger.c
new file mode 100644
index 000..e4e48f3db03
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/taint-merger.c
@@ -0,0 +1,57 @@
+/* { dg-additional-options "-fanalyzer-checker=taint" } */
+// TODO: remove need for this option
+
+#include "analyzer-decls.h"
+
+int v_start;
+
+__attribute__((tainted_args))
+void test (int v_tainted, int v_has_lb, int v_has_ub, int v_stop)
+{
+ /* Get each var into the 5 different taintedness states. */
+ if (v_has_lb < 10)
+return;
+ if (v_has_ub > 100)
+return;
+ if (v_stop < 0 || v_stop > 100)
+return;
+
+ /* Verify that we have the taintedness states we expect. */
+
+ __analyzer_dump_state ("taint", v_start); /* { dg-warning "state: 'start'" }
*/
+ __analyzer_dump_state ("taint", v_tainted); /* { dg-warning "state:
'tainted'" } */
+ __analyzer_dump_state ("taint", v_has_lb); /* { dg-warning "state: 'has_lb'"
} */
+ __analyzer_dump_state ("taint", v_has_ub); /* { dg-warning "state: 'has_ub'"
} */
+ __analyzer_dump_state ("taint", v_stop); /* { dg-warning "state: 'stop'" } */
+
+ /* Check all combinations of taintedness state. */
+ __analyzer_dump_state ("taint", v_start + v_start); /* { dg-warning "state:
'start'" } */
+ __analyzer_dump_state ("taint", v_start + v_tainted); /* { dg-warning
"state: 'tainted'" } */
+ __analyzer_dump_state ("taint", v_start + v_has_lb); /* { dg-warning "state:
'has_lb'" } */
+ __analyzer_dump_state ("taint", v_start + v_has_ub); /* { dg-warning "state:
'has_ub'" } */
+ __analyzer_dump_state ("taint", v_start + v_stop); /* { dg-warning "state:
'stop'" } */
+
+ __analyzer_dump_state ("taint", v_tainted + v_start); /* { dg-warning
"state: 'tainted'" } */
+ __analyzer_dump_state ("taint", v_tainted + v_tainted); /* { dg-warning
"state: 'tainted'" } */
+ __analyzer_dump_state ("taint", v_tainted + v_has_lb); /* { dg-warning
"state: 'tainted'" } */
+ __analyzer_dump_state ("taint", v_tainted + v_has_ub); /* { dg-warning
"state: 'tainted'" } */
+ __analyzer_dump_state ("taint", v_tainted + v_stop); /* { dg-warning "state:
'tainted'" } */
+
+ __analyzer_dump_state ("taint", v_has_lb + v_start); /* { dg-warning "state:
'has_lb'" } */
+ __analyzer_dump_state ("taint", v_has_lb + v_tainted); /* { dg-warning
"state: 'tainted'" } */
+ __analyzer_dump_state ("taint", v_has_lb + v_has_lb); /* { dg-warning
"state: 'has_lb'" } */
+ __analyzer_dump_state ("taint", v_has_lb + v_has_ub); /* { dg-warning
"state: 'tainted'" } */
+ __analyzer_dump_state ("taint", v_has_lb + v_stop); /* { dg-warning "state:
'has_lb'" } */
+
+ __analyzer_dump_state ("taint", v_has_ub + v_start); /* { dg-warning "state:
'has_ub'" } */
+ __analyzer_dump_state ("taint", v_has_ub + v_tainted); /* { dg-warning
"state: 'tainted'" } */
+ __analyzer_dump_state ("taint", v_has_ub + v_has_lb); /* { dg-warning
"state: 'tainted'" } */
+ __analyzer_dump_state ("taint", v_has_ub + v_has_ub); /* { dg-warning
"state: 'has_ub'" } */
+ __analyzer_dump_state ("taint", v_has_ub + v_stop); /* { dg-warning "state:
'has_ub'" } */
+
+ __analyzer_dump_state ("taint", v_stop + v_start); /* { dg-warning "state:
'stop'" } */
+ __analyzer_dump_state ("taint", v_stop + v_tainted); /* { dg-warning "state:
'tainted'" } */
+ __analyzer_dump_state ("taint", v_stop + v_has_lb); /* { dg-warning "state:
'has_lb'" } */
+ __analyzer_dump_state ("taint", v_stop + v_has_ub); /* { dg-warning "state:
'has_ub'" } */
[committed] analyzer: fix ICE in taint checker on unary ops [PR104029]
gcc/analyzer/ChangeLog:
PR analyzer/104029
* sm-taint.cc (taint_state_machine::alt_get_inherited_state):
Remove gcc_unreachable from default case for unary ops.
gcc/testsuite/ChangeLog:
PR analyzer/104029
* gcc.dg/analyzer/pr104029.c: New test.
* gcc.dg/analyzer/taint-ops.c: New test.
---
gcc/analyzer/sm-taint.cc | 1 -
gcc/testsuite/gcc.dg/analyzer/pr104029.c | 115 ++
gcc/testsuite/gcc.dg/analyzer/taint-ops.c | 106
3 files changed, 221 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr104029.c
create mode 100644 gcc/testsuite/gcc.dg/analyzer/taint-ops.c
diff --git a/gcc/analyzer/sm-taint.cc b/gcc/analyzer/sm-taint.cc
index 54c7e6015ab..3a46256b020 100644
--- a/gcc/analyzer/sm-taint.cc
+++ b/gcc/analyzer/sm-taint.cc
@@ -649,7 +649,6 @@ taint_state_machine::alt_get_inherited_state (const
sm_state_map ,
return arg_state;
}
default:
- gcc_unreachable ();
break;
}
}
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr104029.c
b/gcc/testsuite/gcc.dg/analyzer/pr104029.c
new file mode 100644
index 000..adf15ed356f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/pr104029.c
@@ -0,0 +1,115 @@
+// TODO: remove need for this option
+/* { dg-additional-options "-fanalyzer-checker=taint" } */
+
+typedef __SIZE_TYPE__ size_t;
+typedef const void *t_comptype;
+typedef int (*t_compfunc)(t_comptype, t_comptype);
+
+extern int *__errno_location(void)
+ __attribute__((__nothrow__, __leaf__,__const__));
+extern void free(void *__ptr)
+ __attribute__((__nothrow__, __leaf__));
+extern void *my_malloc1(const char *file, int line, size_t size);
+
+int heapsort(void *vbase, size_t nmemb, size_t size, t_compfunc compar) {
+ char tmp, *tmp1, *tmp2, *abase, *k, *p, *t;
+ size_t cnt, i, j, l;
+
+ if (nmemb <= 1)
+return (0);
+
+ if (!size) {
+(*__errno_location()) = 22;
+return (-1);
+ }
+
+ k = my_malloc1(__FILE__, __LINE__, size);
+
+ abase = (char *)vbase - size;
+
+ for (l = nmemb / 2 + 1; --l;) {
+for (i = l; (j = i * 2) <= nmemb; i = j) {
+ p = abase + j * size;
+ if (j < nmemb && compar(p, p + size) < 0) {
+p += size;
+++j;
+ }
+ t = abase + i * size;
+ if (compar(p, t) <= 0)
+break;
+ {
+cnt = size;
+do {
+ tmp = *t;
+ *t++ = *p;
+ *p++ = tmp;
+} while (--cnt);
+ };
+}
+ };
+
+ while (nmemb > 1) {
+{
+ cnt = size;
+ tmp1 = k;
+ tmp2 = abase + nmemb * size;
+ do {
+*tmp1++ = *tmp2++;
+ } while (--cnt);
+};
+{
+ cnt = size;
+ tmp1 = abase + nmemb * size;
+ tmp2 = abase + size;
+ do {
+*tmp1++ = *tmp2++;
+ } while (--cnt);
+};
+--nmemb;
+{
+ for (i = 1; (j = i * 2) <= nmemb; i = j) {
+p = abase + j * size;
+if (j < nmemb && compar(p, p + size) < 0) {
+ p += size;
+ ++j;
+}
+t = abase + i * size;
+{
+ cnt = size;
+ tmp1 = t;
+ tmp2 = p;
+ do {
+*tmp1++ = *tmp2++;
+ } while (--cnt);
+};
+ }
+ for (;;) {
+j = i;
+i = j / 2;
+p = abase + j * size;
+t = abase + i * size;
+if (j == 1 || compar(k, t) < 0) {
+ {
+cnt = size;
+tmp1 = p;
+tmp2 = k;
+do {
+ *tmp1++ = *tmp2++;
+} while (--cnt);
+ };
+ break;
+}
+{
+ cnt = size;
+ tmp1 = p;
+ tmp2 = t;
+ do {
+*tmp1++ = *tmp2++;
+ } while (--cnt);
+};
+ }
+};
+ }
+ free(k);
+ return (0);
+}
diff --git a/gcc/testsuite/gcc.dg/analyzer/taint-ops.c
b/gcc/testsuite/gcc.dg/analyzer/taint-ops.c
new file mode 100644
index 000..729dbe53a0c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/taint-ops.c
@@ -0,0 +1,106 @@
+/* { dg-additional-options "-fanalyzer-checker=taint" } */
+// TODO: remove need for this option
+/* This test can probably be removed when -fanalyzer enables
+ the taint checker by default. */
+
+#include "analyzer-decls.h"
+
+void
+test_1 (char a)
+{
+ char b = -a;
+}
+
+/* Copies of code from data-model-1.c. */
+
+void test_20 (int i, int j)
+{
+ __analyzer_eval (i + 1); /* { dg-warning "UNKNOWN" } */
+ __analyzer_eval (i + j); /* { dg-warning "UNKNOWN" } */
+
+ __analyzer_eval (i - 1); /* { dg-warning "UNKNOWN" } */
+ __analyzer_eval (i - j); /* { dg-warning "UNKNOWN" } */
+
+ __analyzer_eval (i * 2); /* { dg-warning "UNKNOWN" } */
+ __analyzer_eval (i * j); /* { dg-warning "UNKNOWN" } */
+
+ __analyzer_eval (i / 2); /* { dg-warning "UNKNOWN" } */
+ __analyzer_eval (i / j); /* { dg-warning "UNKNOWN" } */
+
+ __analyzer_eval (i % 2); /* {
[Bug analyzer/104029] [12 Regression] ICE with -fanalyzer-checker=taint since r12-5230-gb9365b93212041f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104029 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:8931adfa0530590d21e74e5c7a1f8d26df575775 commit r12-6597-g8931adfa0530590d21e74e5c7a1f8d26df575775 Author: David Malcolm Date: Fri Jan 14 09:49:59 2022 -0500 analyzer: fix ICE in taint checker on unary ops [PR104029] gcc/analyzer/ChangeLog: PR analyzer/104029 * sm-taint.cc (taint_state_machine::alt_get_inherited_state): Remove gcc_unreachable from default case for unary ops. gcc/testsuite/ChangeLog: PR analyzer/104029 * gcc.dg/analyzer/pr104029.c: New test. * gcc.dg/analyzer/taint-ops.c: New test. Signed-off-by: David Malcolm
[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031
--- Comment #5 from Sergei Trofimovich ---
gcc-11 for comparison did not seem to have `struct InfoD.2399 D.2453 =
{.arityD.2402=0};` style nodes and encoded stores explicitly:
main.cc.244t.optimized:
voidD.48 _GLOBAL__sub_I_main ()
{
struct InfoD.2377 D.2496;
...
D.2496.arityD.2380 = 0;
and produced expected RTL: main.cc.245r.expand:
;; Function _GLOBAL__sub_I_main (_GLOBAL__sub_I_main, funcdef_no=14,
decl_uid=2463, cgraph_uid=15, symbol_order=15) (executed once)
...
;;
;; Full RTL generated for this function:
;;
1: NOTE_INSN_DELETED
3: NOTE_INSN_BASIC_BLOCK 2
2: NOTE_INSN_FUNCTION_BEG
5: [r77:DI-0x4]=0 // <<<--- our lost store
6: {r82:DI=r77:DI-0x8;clobber flags:CC;}
7: si:DI=r82:DI
8: di:DI=`_ZL4s_op'
9: call [`_ZN14RegisterPrimOpC1E4Info'] argc:0
REG_CALL_DECL `_ZN14RegisterPrimOpC1E4Info'
REG_EH_REGION 0
Re: [PATCH] libstdc++: Implement C++20 atomic and atomic
On Sat, 18 Sept 2021 at 05:12, Thomas Rodgers
wrote:
> From: Thomas Rodgers
>
> Let's try this one instead.
>
> Signed-off-by: Thomas Rodgers
>
If you're doing DCO "Signed-off-by" commits you don't need FSF copyright
notices in the new tests.
I no longer put any copyright notices in the tests, because it's largely
pointless. They're usually not interesting and don't do anything that
anybody is going to want to steal to incorporate into non-GPL code. Your
new 20_util/shared_ptr/atomic/atomic_shared_ptr.cc is non-trivial, and
maybe interesting, but the two that just check feature test macros are not
worth putting licence headers and copyright notices on.
> libstdc++-v3/ChangeLog:
> * acinclude.m4: Update ABI version.
> * config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Do not match new
> _Sp_locker
> constructor.
> (GLIBCXX_3.4.30): Export _Sp_locker::_M_wait/_M_notify and new
> constructor.
> * include/bits/shared_ptr_atomic.h: define
> __cpp_lib_atomic_shared_ptr
> feature test macro.
> (_Sp_locker::_Sp_locker(const void*, bool): New constructor.
> (_Sp_locker::_M_wait()), _Sp_locker::_M_notify()): New methods.
> (_Sp_impl): New type.
> (atomic>): New partial template specialization.
> (atomic>): New partial template specialization.
> * include/std/version: define __cpp_lib_atomic_shared_ptr feature
> test macro.
> * doc/xml/manual/abi.xml: New ABI version.
> * src/c++11/Makefile.am: Compile src/c++11/shared_ptr.cc
> -std=gnu++20.
> * src/c++11/Makefile.in: Regenerate.
> * src/c++11/shared_ptr.cc (_Sp_locker::_Sp_locker(const void*,
> bool),
> _Sp_locker::_M_wait(), _Sp_locker::_M_notify(): Implement.
> * testsuite/20_util/shared_ptr/atomic/4.cc: New test.
> * testsuite/20_util/shared_ptr/atomic/5.cc: Likewise.
> * testsuite/20_util/shared_ptr/atomic/atomic_shared_ptr.cc:
> Likewise.
> * testuite/util/testsuite_abi.cc: New ABI version.
> ---
> libstdc++-v3/acinclude.m4 | 2 +-
> libstdc++-v3/config/abi/pre/gnu.ver | 12 +-
> libstdc++-v3/configure| 2 +-
> libstdc++-v3/doc/xml/manual/abi.xml | 1 +
> libstdc++-v3/include/bits/shared_ptr_atomic.h | 309 ++
> libstdc++-v3/include/std/version | 1 +
> libstdc++-v3/src/c++11/Makefile.am| 6 +
> libstdc++-v3/src/c++11/Makefile.in| 6 +
> libstdc++-v3/src/c++11/shared_ptr.cc | 86 -
> .../testsuite/20_util/shared_ptr/atomic/4.cc | 28 ++
> .../testsuite/20_util/shared_ptr/atomic/5.cc | 28 ++
> .../shared_ptr/atomic/atomic_shared_ptr.cc| 159 +
> libstdc++-v3/testsuite/util/testsuite_abi.cc | 3 +-
> 13 files changed, 637 insertions(+), 6 deletions(-)
> create mode 100644 libstdc++-v3/testsuite/20_util/shared_ptr/atomic/4.cc
> create mode 100644 libstdc++-v3/testsuite/20_util/shared_ptr/atomic/5.cc
> create mode 100644
> libstdc++-v3/testsuite/20_util/shared_ptr/atomic/atomic_shared_ptr.cc
>
>
[...]
> + void
> + store(value_type __r, memory_order __o = memory_order_seq_cst)
> noexcept
> + { _M_impl._M_store(move(__r), __o); }
>
Every move(x) needs to be qualified as std::move(x) to avoid ADL.
>
> +
> +// { dg-options "-std=gnu++2a" }
> +// { dg-do run { target c++2a } }
>
gnu++20 and c++20 has been OK for a while, there's no need to use the 2a
forms.
Other than that, the patch looks OK, but I have a modified version based on
your patch just using atomic ops, no mutexes, which I'll post shortly.
[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- This seems to have been recently fixed on mainline for gcc-12. Likely fix: r12-6387 for pr101762.
gcc-10-20220114 is now available
Snapshot gcc-10-20220114 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20220114/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision d7e32de60032630c8b39cceb289d558263849acb You'll find: gcc-10-20220114.tar.xz Complete GCC SHA256=dd2fe7538679fa31a68327786679f540aac3c9b0a1623ac120620e64f40c0f9c SHA1=8713cf5bc83bc5ec223430cdb0c9d8d747329fd8 Diffs from 10-20220107 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [PATCH v2 RFC] c++: add color to function decl printing
On Fri, 14 Jan 2022 at 21:49, David Malcolm wrote: > > Jonathan, did you try the v2 patch? > No, sorry.
[Bug target/104028] M68k: Error: value -16034 out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104028 --- Comment #8 from Giulio Benetti --- Note that bug is still present in gcc 11.2.0 so it's probable it's still in master branch. Thank you for taking care. Best regards
[Bug target/104028] M68k: Error: value -16034 out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104028 --- Comment #7 from Giulio Benetti --- Created attachment 52200 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52200=edit Pre-processed sg_vpd.c(sg_vpd.s)
[Bug target/104028] M68k: Error: value -16034 out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104028 --- Comment #6 from Giulio Benetti --- Created attachment 52199 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52199=edit Pre-processed sg_vpd.c(sg_vpd.i)
[Bug target/104028] M68k: Error: value -16034 out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104028 --- Comment #5 from Giulio Benetti --- This is the output log with -v. Now it's built not in parallel and the file where gcc fails is not sg_dd.c so I'm going to update .i and .s files. ``` Target: m68k-buildroot-uclinux-uclibc Configured with: ./configure --prefix=/builds/bootlin/toolchains-builder/build/m68k-coldfire--uclibc--stable-2021.11-1 --sysconfdir=/builds/bootlin/toolchains-builder/build/m68k-coldfire--uclibc--stable-2021.11-1/etc --enable-static --target=m68k-buildroot-uclinux-uclibc --with-sysroot=/builds/bootlin/toolchains-builder/build/m68k-coldfire--uclibc--stable-2021.11-1/m68k-buildroot-uclinux-uclibc/sysroot --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --with-gmp=/builds/bootlin/toolchains-builder/build/m68k-coldfire--uclibc--stable-2021.11-1 --with-mpc=/builds/bootlin/toolchains-builder/build/m68k-coldfire--uclibc--stable-2021.11-1 --with-mpfr=/builds/bootlin/toolchains-builder/build/m68k-coldfire--uclibc--stable-2021.11-1 --with-pkgversion='Buildroot toolchains.bootlin.com-2021.11-1' --with-bugurl=http://bugs.buildroot.net/ --without-zstd --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --disable-tls --enable-threads --without-isl --without-cloog --with-cpu=5208 --enable-languages=c,c++,fortran --with-build-time-tools=/builds/bootlin/toolchains-builder/build/m68k-coldfire--uclibc--stable-2021.11-1/m68k-buildroot-uclinux-uclibc/bin --disable-shared --disable-libgomp Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.3.0 (Buildroot toolchains.bootlin.com-2021.11-1) COLLECT_GCC_OPTIONS='-msoft-float' '-mcpu=5208' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '..' '-iquote' '../include' '-D' '_LARGEFILE64_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-D' '_LARGEFILE_SOURCE' '-D' '_LARGEFILE64_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-Wall' '-Wextra' '-D' '_LARGEFILE_SOURCE' '-D' '_LARGEFILE64_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-Os' '-g2' '-fno-dwarf2-cfi-asm' '-static' '-v' '-save-temps' '-c' '-o' 'sg_vpd.o' /home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/opt/ext-toolchain/bin/../libexec/gcc/m68k-buildroot-uclinux-uclibc/10.3.0/cc1 -E -quiet -v -I . -I .. -iprefix /home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/opt/ext-toolchain/bin/../lib/gcc/m68k-buildroot-uclinux-uclibc/10.3.0/ -isysroot /home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/m68k-buildroot-uclinux-uclibc/sysroot -D HAVE_CONFIG_H -D _LARGEFILE64_SOURCE -D _FILE_OFFSET_BITS=64 -D _LARGEFILE_SOURCE -D _LARGEFILE64_SOURCE -D _FILE_OFFSET_BITS=64 -D _LARGEFILE_SOURCE -D _LARGEFILE64_SOURCE -D _FILE_OFFSET_BITS=64 -iquote ../include sg_vpd.c -msoft-float -mcpu=5208 -Wall -Wextra -fno-dwarf2-cfi-asm -g2 -fworking-directory -Os -fpch-preprocess -o sg_vpd.i ignoring duplicate directory "/home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/opt/ext-toolchain/bin/../lib/gcc/../../lib/gcc/m68k-buildroot-uclinux-uclibc/10.3.0/include" ignoring nonexistent directory "/home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/m68k-buildroot-uclinux-uclibc/sysroot/usr/local/include" ignoring duplicate directory "/home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/opt/ext-toolchain/bin/../lib/gcc/../../lib/gcc/m68k-buildroot-uclinux-uclibc/10.3.0/include-fixed" ignoring duplicate directory "/home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/opt/ext-toolchain/bin/../lib/gcc/../../lib/gcc/m68k-buildroot-uclinux-uclibc/10.3.0/../../../../m68k-buildroot-uclinux-uclibc/include" #include "..." search starts here: ../include #include <...> search starts here: . .. /home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/opt/ext-toolchain/bin/../lib/gcc/m68k-buildroot-uclinux-uclibc/10.3.0/include /home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/opt/ext-toolchain/bin/../lib/gcc/m68k-buildroot-uclinux-uclibc/10.3.0/include-fixed /home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/opt/ext-toolchain/bin/../lib/gcc/m68k-buildroot-uclinux-uclibc/10.3.0/../../../../m68k-buildroot-uclinux-uclibc/include /home/giuliobenetti/br_reproduce/c49300d12a209b18f41d389f092324592b881277/output/host/m68k-buildroot-uclinux-uclibc/sysroot/usr/include End of search list. COLLECT_GCC_OPTIONS='-msoft-float' '-mcpu=5208' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '..' '-iquote' '../include' '-D' '_LARGEFILE64_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-D' '_LARGEFILE_SOURCE' '-D' '_LARGEFILE64_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-Wall' '-Wextra' '-D' '_LARGEFILE_SOURCE' '-D' '_LARGEFILE64_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-Os' '-g2' '-fno-dwarf2-cfi-asm' '-static' '-v' '-save-temps' '-c' '-o' 'sg_vpd.o'
[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031
--- Comment #4 from Sergei Trofimovich ---
Great test, Andrew!
Something is completely dropped initialization of Info{} input argument to
s_op. As if it's lifetime ends before RegisterPrimOp{} enters:
--- main.s.good 2022-01-14 21:53:42.334571321 +
+++ main.s.bad 2022-01-14 21:53:51.275722971 +
@@ -43,26 +43,25 @@
.p2align 4
.type _GLOBAL__sub_I_main, @function
_GLOBAL__sub_I_main:
.LFB14:
.cfi_startproc
subq$24, %rsp #,
.cfi_def_cfa_offset 32
# ../main.cc:21: });
movl$_ZL4s_op, %edi #,
leaq8(%rsp), %rsi #, tmp84
- movl$0, 12(%rsp)#, D.2496.arityD.2380
call_ZN14RegisterPrimOpC1E4Info #
# ../main.cc:22: int main() {}
addq$24, %rsp #,
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE14:
.size _GLOBAL__sub_I_main, .-_GLOBAL__sub_I_main
.section.init_array,"aw"
.align 8
.quad _GLOBAL__sub_I_main
.local _ZL4s_op
.comm _ZL4s_op,1,1
- .ident "GCC: (GNU) 11.2.0"
+ .ident "GCC: (GNU) 12.0.0 20220109 (experimental)"
.section.note.GNU-stack,"",@progbits
Initial gimple looks valid to me: main.cc.006t.gimple:
void __static_initialization_and_destruction_0 (int __initialize_p, int
__priority)
{
struct InfoD.2399 D.2453 = {.arityD.2402=0};
...
_ZN6vectorC1EvD.2377 ();
...
try { try { try {
# USE = anything
# CLB = anything
_ZN14RegisterPrimOpC1E4InfoD.2413 (_opD.2424, );
} finally {
# USE = anything
# CLB = anything
_ZN4InfoD1EvD.2457 ();
} } finally {
D.2453 = {CLOBBER};
}
Final tree also looks ok: main.cc.250t.optimized:
voidD.48 _GLOBAL__sub_I_mainD.2486 ()
{
struct InfoD.2399 D.2522 = {.arityD.2402=0};
# USE = nonlocal escaped { D.2424 D.2522 } (nonlocal, escaped)
# CLB = nonlocal escaped { D.2424 D.2522 } (nonlocal, escaped)
_ZN14RegisterPrimOpC1E4InfoD.2413 (&_ZL4s_opD.2424, );
D.2522 ={v} {CLOBBER};
First RTL seems to lack the assignment: main.cc.252r.expand:
;; Function _GLOBAL__sub_I_main (_GLOBAL__sub_I_main, funcdef_no=14,
decl_uid=2486, cgraph_uid=15, symbol_order=15) (executed once)
...
;;
;; Full RTL generated for this function:
;;
1: NOTE_INSN_DELETED
3: NOTE_INSN_BASIC_BLOCK 2
2: NOTE_INSN_FUNCTION_BEG
5: {r82:DI=r77:DI-0x8;clobber flags:CC;}
6: si:DI=r82:DI
7: di:DI=`_ZL4s_op'
8: call [`_ZN14RegisterPrimOpC1E4Info'] argc:0
REG_CALL_DECL `_ZN14RegisterPrimOpC1E4Info'
REG_EH_REGION 0
[Bug fortran/79685] [9/10/11/12 Regression] ICE on valid code in gfc_match_structur_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79685 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #11 from anlauf at gcc dot gnu.org --- The following tentative change fixes testcase z1 in comment#5: diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c index 3f01f67cd49..d3729b20446 100644 --- a/gcc/fortran/primary.c +++ b/gcc/fortran/primary.c @@ -3373,8 +3373,8 @@ gfc_match_structure_constructor (gfc_symbol *sym, gfc_expr **result) e->expr_type = EXPR_FUNCTION; e->where = gfc_current_locus; - gcc_assert (gfc_fl_struct (sym->attr.flavor) - && symtree->n.sym->attr.flavor == FL_PROCEDURE); + gcc_assert (gfc_fl_struct (sym->attr.flavor)); +// && symtree->n.sym->attr.flavor == FL_PROCEDURE); e->value.function.esym = sym; e->symtree->n.sym->attr.generic = 1; However, it does not fix the example in comment#0. Playing a little, it seems that commenting the "implicit none" in module foo then lets the code compile. Alternative reproducer: module m implicit none private public :: t type t integer :: i end type end module m2 use m, t2 => t implicit none ! <--- Error: Symbol 't' at (1) has no IMPLICIT type private type(t2), public, protected :: x(2) data x(1) /t2(3)/ end program p use m2 implicit none print *, x(1)%i end program p So there is more to it...
[Bug tree-optimization/104038] ranger infinite loop on a PHI statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038 --- Comment #4 from Martin Sebor --- The problem is reproducible with -O1 and above. To confirm it's not infinite recursion I let the process run for about an hour before killing it. Memory consumption seems to slowly but steadily increase as GCC spins.
[Bug tree-optimization/104038] ranger infinite loop on a PHI statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038 --- Comment #3 from Martin Sebor --- The basic block being analyzed is bb 2 in clang::clangd::stdlib::initialize(). What's unusual about it is that it's a sequence of 2464 assignments like so: : SymCount_21 = 0; SymCount_22 = SymCount_21 + 1; SymCount_23 = SymCount_22 + 1; SymCount_24 = SymCount_23 + 1; ... SymCount_2481 = SymCount_2480 + 1; SymCount_2482 = SymCount_2481 + 1; SymCount_2483 = SymCount_2482 + 1; _2484 = (sizetype) SymCount_2483; if (_2484 <= 288230376151711743) goto ; [INV] else goto ; [INV]
[Bug testsuite/104037] [12 regression] excess errors in g++.old-deja/g++.robertl/eb43.C after r12-6581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104037 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-01-14 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug tree-optimization/104038] ranger infinite loop on a PHI statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038 --- Comment #2 from Martin Sebor --- Created attachment 52198 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52198=edit Unreduced test case. The attached translation unit reproduces the infinite loop.
[Bug tree-optimization/104038] ranger infinite loop on a PHI statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038 --- Comment #1 from Martin Sebor --- Created attachment 52197 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52197=edit Patch needed to trigger the infinite loop. When the attached patch is applied the infinite loop can be triggered by compiling the test case (to be attached) with -O2.
[Bug tree-optimization/104038] New: ranger infinite loop on a PHI statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038 Bug ID: 104038 Summary: ranger infinite loop on a PHI statement Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- I'm debugging what looks like an infinite loop deep in Ranger. Interrupting with SIGABRT the cc1plus process while under GDB produces the backtrace below. Returning eventually re-enters the infinite loop in gimple_ranger::prefill_stmt_dependencies(). The statement being processed at the highest level is: _11 = PHI <_2493(5), _27180(6)> Program received signal SIGABRT, Aborted. 0x00ac2f81 in tree_check (__t=0x7fffc6437990, __f=0x31ca5b8 "/src/gcc/master/gcc/value-relation.cc", __l=1117, __g=0x31ca7f4 "find_relation_block", __c=SSA_NAME) at /src/gcc/master/gcc/tree.h:3440 3440 if (TREE_CODE (__t) != __c) (gdb) bt #0 0x00ac2f81 in tree_check (__t=0x7fffc6437990, __f=0x31ca5b8 "/src/gcc/master/gcc/value-relation.cc", __l=1117, __g=0x31ca7f4 "find_relation_block", __c=SSA_NAME) at /src/gcc/master/gcc/tree.h:3440 #1 0x01bb3831 in dom_oracle::find_relation_block (this=0x55615c0, bb=2, v1=324, v2=47, obj=0x0) at /src/gcc/master/gcc/value-relation.cc:1117 #2 0x01bb3976 in dom_oracle::find_relation_dom (this=0x55615c0, bb=0x7fffe7e08af8, v1=324, v2=47) at /src/gcc/master/gcc/value-relation.cc:1149 #3 0x01bb2f52 in dom_oracle::set_one_relation (this=0x55615c0, bb=0x7fffe7e08af8, k=GT_EXPR, op1=0x7fffc643c798, op2=0x7fffc6436870) at /src/gcc/master/gcc/value-relation.cc:946 #4 0x01bb3511 in dom_oracle::register_transitives (this=0x55615c0, root_bb=0x7fffe7e08af8, relation=...) at /src/gcc/master/gcc/value-relation.cc:1043 #5 0x01bb2c76 in dom_oracle::register_relation (this=0x55615c0, bb=0x7fffe7e08af8, k=GT_EXPR, op1=0x7fffc643c798, op2=0x7fffc643c750) at /src/gcc/master/gcc/value-relation.cc:892 #6 0x01bb2a79 in relation_oracle::register_stmt (this=0x55615c0, stmt=0x7fffe7e12948, k=GT_EXPR, op1=0x7fffc643c798, op2=0x7fffc643c750) at /src/gcc/master/gcc/value-relation.cc:846 #7 0x02c01084 in fur_depend::register_relation (this=0x7fff89e0, s=0x7fffe7e12948, k=GT_EXPR, op1=0x7fffc643c798, op2=0x7fffc643c750) at /src/gcc/master/gcc/gimple-range-fold.cc:198 #8 0x02c028d9 in fold_using_range::range_of_range_op ( this=0x7fff8a0f, r=..., s=0x7fffe7e12948, src=...) at /src/gcc/master/gcc/gimple-range-fold.cc:642 #9 0x02c021f5 in fold_using_range::fold_stmt (this=0x7fff8a0f, r=..., s=0x7fffe7e12948, src=..., name=0x7fffc643c798) at /src/gcc/master/gcc/gimple-range-fold.cc:552 #10 0x02bf70be in gimple_ranger::fold_range_internal (this=0x5509e30, r=..., s=0x7fffe7e12948, name=0x7fffc643c798) at /src/gcc/master/gcc/gimple-range.cc:250 #11 0x02bf7636 in gimple_ranger::prefill_stmt_dependencies ( this=0x5509e30, ssa=0x7fffc64631b0) at /src/gcc/master/gcc/gimple-range.cc:385 #12 0x02bf7373 in gimple_ranger::range_of_stmt (this=0x5509e30, r=..., s=0x7fffe7e41898, name=0x7fffc64631b0) at /src/gcc/master/gcc/gimple-range.cc:307 #13 0x02bf68d4 in gimple_ranger::range_of_expr (this=0x5509e30, r=..., expr=0x7fffc64631b0, stmt=0x7fffd76f4900) at /src/gcc/master/gcc/gimple-range.cc:120 #14 0x0160c78a in get_size_range (query=0x5509e30, exp=0x7fffc64631b0, stmt=0x7fffd76f4900, range=0x7fffc190, flags=3) at /src/gcc/master/gcc/pointer-query.cc:320 #15 0x0160d8de in gimple_call_alloc_size (stmt=0x7fffd76f4900, rng1=0x7fffc470, qry=0x5509e30) at /src/gcc/master/gcc/pointer-query.cc:506 #16 0x01614a30 in handle_ssa_name (ptr=0x7fffc6463240, addr=false, ostype=0, pref=0x7fffd650, snlim=..., qry=0x7fffd730) at /src/gcc/master/gcc/pointer-query.cc:2053 #17 0x016160a8 in compute_objsize_r (ptr=0x7fffc6463240, stmt=0x7fffe7f45f50, addr=false, ostype=0, pref=0x7fffd650, snlim=..., qry=0x7fffd730) at /src/gcc/master/gcc/pointer-query.cc:2346 #18 0x016156d6 in handle_ssa_name (ptr=0x7fffc6463288, addr=false, ostype=0, pref=0x7fffd650, snlim=..., qry=0x7fffd730) at /src/gcc/master/gcc/pointer-query.cc:2196 #19 0x016160a8 in compute_objsize_r (ptr=0x7fffc6463288, stmt=0x7fffe7e0a3c0, addr=false, ostype=0, pref=0x7fffd650, snlim=..., --Type for more, q to quit, c to continue without paging-- qry=0x7fffd730) at /src/gcc/master/gcc/pointer-query.cc:2346 #20 0x016156d6 in handle_ssa_name (ptr=0x7fffc6463318, addr=false, ostype=0, pref=0x7fffd650, snlim=..., qry=0x7fffd730) at
[Bug fortran/77667] ICE in expand_call, at calls.c:2588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77667 --- Comment #5 from anlauf at gcc dot gnu.org --- Seems fixed on mainline for gcc-12. Most likely fix: r12-6557 for pr67804.
Re: [PATCH 11/11] libstdc++: Fix ODR issues with different -m flags
On Mon, 15 Nov 2021 at 08:57, Matthias Kretz wrote: > ping. OK to push? > Sorry for the delay - this is OK for trunk. > On Tuesday, 8 June 2021 14:12:23 CET Matthias Kretz wrote: > > From: Matthias Kretz > > > > Explicitly support use of the stdx::simd implementation in situations > > where the user links TUs that were compiled with different -m flags. In > > general, this is always a (quasi) ODR violation for inline functions > > because at least codegen may differ in important ways. However, in the > > resulting executable only one (unspecified which one) of them might be > > used. For simd we want to support users to compile code multiple times, > > with different -m flags and have a runtime dispatch to the TU matching > > the target CPU. But if internal functions are not inlined this may lead > > to unexpected performance loss or execution of illegal instructions. > > Therefore, inline functions that are not marked as always_inline must > > use an additional template parameter somewhere in their name, to > > disambiguate between the different -m translations. > > > > Signed-off-by: Matthias Kretz > > > > libstdc++-v3/ChangeLog: > > > > * include/experimental/bits/simd.h: Move feature detection bools > > and add __have_avx512bitalg, __have_avx512vbmi2, > > __have_avx512vbmi, __have_avx512ifma, __have_avx512cd, > > __have_avx512vnni, __have_avx512vpopcntdq. > > (__detail::__machine_flags): New function which returns a unique > > uint64 depending on relevant -m and -f flags. > > (__detail::__odr_helper): New type alias for either an anonymous > > type or a type specialized with the __machine_flags number. > > (_SimdIntOperators): Change template parameters from _Impl to > > _Tp, _Abi because _Impl now has an __odr_helper parameter which > > may be _OdrEnforcer from the anonymous namespace, which makes > > for a bad base class. > > (many): Either add __odr_helper template parameter or mark as > > always_inline. > > * include/experimental/bits/simd_detail.h: Add defines for > > AVX512BITALG, AVX512VBMI2, AVX512VBMI, AVX512IFMA, AVX512CD, > > AVX512VNNI, AVX512VPOPCNTDQ, and AVX512VP2INTERSECT. > > * include/experimental/bits/simd_builtin.h: Add __odr_helper > > template parameter or mark as always_inline. > > * include/experimental/bits/simd_fixed_size.h: Ditto. > > * include/experimental/bits/simd_math.h: Ditto. > > * include/experimental/bits/simd_scalar.h: Ditto. > > * include/experimental/bits/simd_neon.h: Add __odr_helper > > template parameter. > > * include/experimental/bits/simd_ppc.h: Ditto. > > * include/experimental/bits/simd_x86.h: Ditto. > > --- > > libstdc++-v3/include/experimental/bits/simd.h | 380 -- > > .../include/experimental/bits/simd_builtin.h | 41 +- > > .../include/experimental/bits/simd_detail.h | 40 ++ > > .../experimental/bits/simd_fixed_size.h | 39 +- > > .../include/experimental/bits/simd_math.h | 45 ++- > > .../include/experimental/bits/simd_neon.h | 4 +- > > .../include/experimental/bits/simd_ppc.h | 4 +- > > .../include/experimental/bits/simd_scalar.h | 71 +++- > > .../include/experimental/bits/simd_x86.h | 4 +- > > 9 files changed, 440 insertions(+), 188 deletions(-) > > -- > ── > Dr. Matthias Kretz https://mattkretz.github.io > GSI Helmholtz Centre for Heavy Ion Research https://gsi.de > stdₓ::simd > ── > > > >
[Bug testsuite/104037] New: [12 regression] excess errors in g++.old-deja/g++.robertl/eb43.C after r12-6581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104037 Bug ID: 104037 Summary: [12 regression] excess errors in g++.old-deja/g++.robertl/eb43.C after r12-6581 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:de196e5dd8ea4d0ed01a8c265afdd3676e27545b, r12-6581 make -k check-gcc RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.robertl/eb43.C" FAIL: g++.old-deja/g++.robertl/eb43.C -std=c++14 (test for excess errors) FAIL: g++.old-deja/g++.robertl/eb43.C -std=c++17 (test for excess errors) FAIL: g++.old-deja/g++.robertl/eb43.C -std=c++2a (test for excess errors) # of expected passes5 # of unexpected failures3 commit de196e5dd8ea4d0ed01a8c265afdd3676e27545b (HEAD, refs/bisect/bad) Author: Jonathan Wakely Date: Tue Jan 11 18:42:38 2022 + libstdc++: Add attribute to features deprecated in C++17 [PR91260] Excess errors: /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C:32:8: warning: 'template class std::pointer_to_binary_function' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C:35:57: warning: 'std::pointer_to_binary_function<_Arg1, _Arg2, _Result> std::ptr_fun(_Result (*)(_Arg1, _Arg2)) [with _Arg1 = const Expr; _Arg2 = const Expr; _Result = bool]' is deprecated: use 'std::mem_fn' instead [-Wdeprecated-declarations] /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C:37:16: warning: 'std::pointer_to_binary_function<_Arg1, _Arg2, _Result> std::ptr_fun(_Result (*)(_Arg1, _Arg2)) [with _Arg1 = Expr; _Arg2 = Expr; _Result = bool]' is deprecated: use 'std::mem_fn' instead [-Wdeprecated-declarations] /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C:39:9: warning: 'template class std::pointer_to_binary_function' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C:41:9: warning: 'template class std::pointer_to_binary_function' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C:43:9: warning: 'template class std::pointer_to_binary_function' is deprecated [-Wdeprecated-declarations]
[Bug fortran/104036] New: Derived type assigment to allocatable with dynamic type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104036 Bug ID: 104036 Summary: Derived type assigment to allocatable with dynamic type Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: baradi09 at gmail dot com Target Milestone: --- Created attachment 52196 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52196=edit Demonstration code Dear developers, the behaviour of the GNU compiler is probably not standard conforming, when assigning a derived type without user defined assignment, which contains a derived type component with user defined assignment, to an allocatable variable with dynamic type. Some discussion about the topic can be found here: https://fortran-lang.discourse.group/t/intrinsic-assigment-of-derived-types-containing-components-with-user-defined-assignment/2595 I have also attached the demonstration program, where I would expect the user defined assignment be triggered when line 41 is executed, which does not happen. (On line 39 it does, as expected.) Best regards, Bálint
[Bug fortran/99256] ICE in variable_check, at fortran/check.c:1012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99256 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #7 from anlauf at gcc dot gnu.org --- Committed as obvious, see also https://gcc.gnu.org/pipermail/fortran/2022-January/057398.html Closing. Thanks for the report!
[PATCH, committed] PR fortran/99256 - ICE in variable_check, at fortran/check.c:1012
Dear all,
this is a rather satisfying mini-patch which removes code to fix a bug.
The intrinsics MOVE_ALLOC, C_F_POINTER, and C_F_PROCPOINTER require
deferred checks of part of their actual argument types which may be of
"any" type. This however excludes alternate return specifiers which
therefore must be unconditionally rejected for all standard intrinsics.
OK'ed by Steve (see PR), and committed to mainline as obvious after
regtesting on x86_64-pc-linux-gnu.
Thanks,
Harald
From 70e24c9682ddbcade0301665bccd8e7f928d0082 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 14 Jan 2022 21:48:15 +0100
Subject: [PATCH] Fortran: always reject alternate return specifier as argument
of intrinsics
The intrinsics MOVE_ALLOC, C_F_POINTER, and C_F_PROCPOINTER require
deferred checks of part of their actual argument types which may be of
"any" type. This however excludes alternate return specifiers which
therefore must be unconditionally rejected for all standard intrinsics.
gcc/fortran/ChangeLog:
PR fortran/99256
* intrinsic.c: Do not check formal argument type when checking
arguments of intrinsics for alternate return specifiers.
gcc/testsuite/ChangeLog:
PR fortran/99256
* gfortran.dg/altreturn_11.f90: New test.
---
gcc/fortran/intrinsic.c| 2 +-
gcc/testsuite/gfortran.dg/altreturn_11.f90 | 15 +++
2 files changed, 16 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/altreturn_11.f90
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index a7ecdb401ef..9746cd5ddb6 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -4420,7 +4420,7 @@ do_sort:
FOR_EACH_VEC_ELT (dummy_args, idx, f)
{
a = ordered_actual_args[idx];
- if (a && a->label != NULL && f->ts.type)
+ if (a && a->label != NULL)
{
gfc_error ("ALTERNATE RETURN not permitted at %L", where);
return false;
diff --git a/gcc/testsuite/gfortran.dg/altreturn_11.f90 b/gcc/testsuite/gfortran.dg/altreturn_11.f90
new file mode 100644
index 000..be42971d781
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/altreturn_11.f90
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! { dg-prune-output "Obsolescent feature: Alternate-return argument" }
+! PR fortran/99256 - ICE in variable_check
+! Contributed by G.Steimetz
+
+program test
+ use iso_c_binding
+ type(c_ptr):: i
+ type(c_funptr) :: p
+ call move_alloc (*1, *2) ! { dg-error "ALTERNATE RETURN" }
+ call c_f_pointer (i, *1) ! { dg-error "ALTERNATE RETURN" }
+ call c_f_procpointer (p, *2) ! { dg-error "ALTERNATE RETURN" }
+1 continue
+2 stop
+end
--
2.31.1
[Bug fortran/99256] ICE in variable_check, at fortran/check.c:1012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99256 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:70e24c9682ddbcade0301665bccd8e7f928d0082 commit r12-6596-g70e24c9682ddbcade0301665bccd8e7f928d0082 Author: Harald Anlauf Date: Fri Jan 14 21:48:15 2022 +0100 Fortran: always reject alternate return specifier as argument of intrinsics The intrinsics MOVE_ALLOC, C_F_POINTER, and C_F_PROCPOINTER require deferred checks of part of their actual argument types which may be of "any" type. This however excludes alternate return specifiers which therefore must be unconditionally rejected for all standard intrinsics. gcc/fortran/ChangeLog: PR fortran/99256 * intrinsic.c: Do not check formal argument type when checking arguments of intrinsics for alternate return specifiers. gcc/testsuite/ChangeLog: PR fortran/99256 * gfortran.dg/altreturn_11.f90: New test.
[Bug testsuite/104035] New: [12 regression] g++.dg/torture/pr57993-2.C fails with excess errors after r12-6586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104035 Bug ID: 104035 Summary: [12 regression] g++.dg/torture/pr57993-2.C fails with excess errors after r12-6586 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:74abb0beb420830e52dfc6b3ee74e77dae8e31a3, r12-6586 The rename appears to have resulted in excess errors. make -k check-gcc RUNTESTFLAGS="dg-torture.exp=g++.dg/torture/pr57993-2.C" FAIL: g++.dg/torture/pr57993-2.C -O0 (test for excess errors) FAIL: g++.dg/torture/pr57993-2.C -O1 (test for excess errors) FAIL: g++.dg/torture/pr57993-2.C -O2 (test for excess errors) FAIL: g++.dg/torture/pr57993-2.C -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: g++.dg/torture/pr57993-2.C -O3 -g (test for excess errors) FAIL: g++.dg/torture/pr57993-2.C -Os (test for excess errors) FAIL: g++.dg/torture/pr57993-2.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/pr57993-2.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) FAIL: g++.dg/torture/pr57993-2.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:173:3: warning: no return statement in function returning non-void [-Wreturn-type] /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:191:3: warning: no return statement in function returning non-void [-Wreturn-type] /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:204:3: warning: no return statement in function returning non-void [-Wreturn-type] /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:212:3: warning: no return statement in function returning non-void [-Wreturn-type] /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:135:15: warning: 'void Destroy_Bicubic_Patch(OBJECT*)' used but never defined /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:134:15: warning: 'void Invert_Bicubic_Patch(OBJECT*)' used but never defined /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:133:15: warning: 'void Transform_Bicubic_Patch(OBJECT*, TRANSFORM*)' used but never defined /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:131:15: warning: 'void Scale_Bicubic_Patch(OBJECT*, double*, TRANSFORM*)' used but never defined /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:129:15: warning: 'void Rotate_Bicubic_Patch(OBJECT*, double*, TRANSFORM*)' used but never defined /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:127:15: warning: 'void Translate_Bicubic_Patch(OBJECT*, double*, TRANSFORM*)' used but never defined /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:126:25: warning: 'BICUBIC_PATCH* Copy_Bicubic_Patch(OBJECT*)' used but never defined /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:124:15: warning: 'void Bicubic_Patch_UVCoord(double*, OBJECT*, INTERSECTION*)' used but never defined /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:122:15: warning: 'void Bicubic_Patch_Normal(double*, OBJECT*, INTERSECTION*)' used but never defined /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr57993-2.C:121:14: warning: 'int Inside_Bicubic_Patch(double*, OBJECT*)' used but never defined commit 74abb0beb420830e52dfc6b3ee74e77dae8e31a3 (HEAD, refs/bisect/bad) Author: Martin Liska Date: Fri Jan 14 15:21:40 2022 +0100 testsuite: rename 2 files.
Re: [Patch][V4][Patch 2/2]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables.
> On Jan 14, 2022, at 12:58 PM, Martin Sebor wrote: > > On 1/14/22 11:29, Qing Zhao wrote: >>> On Jan 14, 2022, at 12:11 PM, Martin Sebor wrote: >>> >>> On 1/14/22 09:30, Qing Zhao wrote: > On Jan 14, 2022, at 6:45 AM, Richard Biener > wrote: > > On Thu, Jan 13, 2022 at 2:45 AM Qing Zhao wrote: >> >> Hi, Richard, >> >> This is the updated version for the second patch, which is mainly the >> change for "Enable -Wuninitialized + -ftrivial-auto-var-init for >> address taken variables”. >> >> In this update, I mainly made the following change: >> >> 1. Delete “repl_var”, use the var_def_stmt, i.e, the call to >> .DEFERRED_INIT to record the warning suppressed info. >> 2. Add and change the comments in multiple places to make the change >> more readable. >> >> Now, for the deleted variable, we will get the necessary info to report >> warning from the call to .DEFERRED_INIT. >> >>A. the name string of DECL from the 3rd parameter of the call; >>B. the location of the DECL from the location of the call; >>C. the call can also be used to hold the information on whether the >> warning >> has been issued or not to suppress warning messages when needed; >> >> Please see the detailed description below for the problem and solution >> of this patch. >> >> This patch has been bootstrapped and regressing tested on both X86 and >> aarch64. >> >> Okay for GCC12? > > I think the change to split "%qD is used uninitialized" is bad for i8n > though it seems > like none of the strings passed to warn_uninit are currently marked > for localization. > I suppose there's lazy matching with the exact same strings passed to > warning_at around like 641 but after your change those will no longer > match up, Silly question: What does the above “641” mean? >>> >>> At around line 641 :) >> I thought of this, but I didn’t find a meaningful statement around line 641 >> in tree-ssa-uninit.c… >> 636 found_alloc = true; >> 637 break; >> 638 } >> 639 >> 640 if (!is_gimple_assign (def_stmt)) >> 641 break; >> 642 >> 643 tree_code code = gimple_assign_rhs_code (def_stmt); >> 644 if (code != ADDR_EXPR && code != POINTER_PLUS_EXPR) >> 645 break; >> >>> > at least for the "%qs ..." case constructed. I think a better way > (for i8n) would be > to pass down a flag whether it is "may" or "is" and have the full > translatable > strings literally passed to warning_at at the expense of some code > duplication. > Actually the extra flag is unnecessary, the OPT_W... we pass is already > fully > specifying that. The only issue with the above change is: among the 4 calls to “warn_uninit” as following: if (use_stmt) warn_uninit (OPT_Wuninitialized, def, SSA_NAME_VAR (def), -"%qD is used uninitialized", use_stmt); +"is used uninitialized", use_stmt); } } @@ -932,10 +1015,10 @@ warn_uninitialized_vars (bool wmaybe_uninit) tree use = USE_FROM_PTR (use_p); if (wlims.always_executed) warn_uninit (OPT_Wuninitialized, use, SSA_NAME_VAR (use), -"%qD is used uninitialized", stmt); +"is used uninitialized", stmt); else if (wmaybe_uninit) warn_uninit (OPT_Wmaybe_uninitialized, use, SSA_NAME_VAR (use), -"%qD may be used uninitialized", stmt); +"may be used uninitialized", stmt); } /* For limiting the alias walk below we count all @@ -1182,7 +1265,7 @@ warn_uninitialized_phi (gphi *phi, vec *worklist, warn_uninit (OPT_Wmaybe_uninitialized, uninit_op, SSA_NAME_VAR (uninit_op), - "%qD may be used uninitialized in this function", + "may be used uninitialized in this function", uninit_use_stmt, loc); All the strings passed map well with the OPT_W… except the last one, since the last one has an additional string “in this function” at the end. However, since the last call has the last argument “loc” been NULL, maybe we can use this to distinguish. >>> >>> Now that diagnostics are prefixed by something like "In function 'foo': >>> the "in this function" part is superfluous and could be removed from >>> all warning messages. >> Okay, so, you mean that it’s safe to just remove “in this function” from the >> last callsite? > > Yes, I would remove it. It might require some cleanup in the test > suite but I wouldn't expect it to be
[Bug target/103973] x86: 4-way comparison of floats/doubles with spaceship operator possibly suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103973 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 52195 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52195=edit gcc12-pr103973.patch Untested fix.
Re: [PATCH] cprop_hardreg: Workaround for narrow mode != lowpart targets
On 1/14/22 20:41, Andreas Krebbel via Gcc-patches wrote:
> On 1/14/22 08:37, Richard Biener wrote:
> ...
>> Can the gist of this bug be put into the GCC bugzilla so the rev can
>> refer to it?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
>
>> Can we have a testcase even?
> The testcase from Jakub is in the BZ. However, since it doesn't fail with
> head I didn't try to
> include it in my patch.
>
>> I'm not quite understanding the problem but is it that, say,
>>
>> (subreg:DI (reg:V2DI ..) 0)
>>
>> isn't the same as
>>
>> (lowpart:DI (reg:V2DI ...) 0)
>
> (reg:DI v0) does not match the lower order bits of (reg:TI v0)
>
>> ? The regcprop code looks more like asking whether the larger reg
>> is a composition of multiple other hardregs and will return the specific
>> hardreg corresponding to the lowpart - so like if on s390 the vector
>> registers overlap with some other regset. But then doing the actual
>> accesses via the other regset regs doesn't actually work? Isn't the
>> backend then lying to us (aka the mode_change_ok returns the
>> wrong answer)?
>
> can_change_mode_class should do the right thing. We return false in case
> somebody wants to change TI
> to DI for a vector register. However, the hook never gets called like this
> from regcprop. regcprop
> only asks whether it is ok to change (reg:TI r8) to (reg:DI r8) and that's
> indeed ok.
After writing this I'm wondering whether this would be a better fix:
diff --git a/gcc/regcprop.c b/gcc/regcprop.c
index 18132425ab2..b6a3f4e3804 100644
--- a/gcc/regcprop.c
+++ b/gcc/regcprop.c
@@ -402,7 +402,8 @@ maybe_mode_change (machine_mode orig_mode, machine_mode
copy_mode,
if (orig_mode == new_mode)
return gen_raw_REG (new_mode, regno);
- else if (mode_change_ok (orig_mode, new_mode, regno))
+ else if (mode_change_ok (orig_mode, new_mode, regno)
+ && mode_change_ok (copy_mode, new_mode, copy_regno))
{
int copy_nregs = hard_regno_nregs (copy_regno, copy_mode);
int use_nregs = hard_regno_nregs (copy_regno, new_mode);
Andreas
Re: reordering of trapping operations and volatile
On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, wrote: > Hello, > > On Thu, 13 Jan 2022, Martin Uecker wrote: > > > > > > Handling all volatile accesses in the very same way would be > > > > > possible but quite some work I don't see much value in. > > > > > > > > I see some value. > > > > > > > > But an alternative could be to remove volatile > > > > from the observable behavior in the standard > > > > or make it implementation-defined whether it > > > > is observable or not. > > > > > > But you are actually arguing for making UB be observable > > > > No, I am arguing for UB not to have the power > > to go back in time and change previous defined > > observable behavior. > > But right now that's equivalent to making it observable, > because we don't have any other terms than observable or > undefined. As aluded to later you would have to > introduce a new concept, something pseudo-observable, > which you then started doing. So, see below. > > > > That's > > > much different from making volatile not be > > > observable anymore (which obviously would > > > be a bad idea), and is also much harder to > > > > I tend to agree that volatile should be > > considered observable. But volatile is > > a bit implementation-defined anyway, so this > > would be a compromise so that implementations > > do not have to make all the implied changes > > if we revise the meaning of UB. > > Using volatile accesses for memory mapped IO is a much stronger use-case > than your wish of using volatile accesses to block moving of UB as a > debugging aid, and the former absolutely needs some guarantees, so I don't > think it would be a compromise at all. Mkaing volatile not be observable > would break the C language. > > > > Well, what you _actually_ want is an implied > > > dependency between some UB and volatile accesses > > > (and _only_ those, not e.g. with other UB), and the > > > difficulty now is to define "some" and to create > > > the dependency without making that specific UB > > > to be properly observable. > > > > Yes, this is what I actually want. > > > > > I think to define this > > > all rigorously seems futile (you need a new > > > category between observable and UB), so it comes > > > down to compiler QoI on a case by case basis. > > > > We would simply change UB to mean "arbitrary > > behavior at the point of time the erraneous > > construct is encountered at run-time" and > > not "the complete program is invalid all > > together". I see no problem in specifying this > > (even in a formally precise way) > > First you need to define "point in time", a concept which doesn't exist > yet in C. The obvious choice is of course observable behaviour in the > execution environment and its specified ordering from the abstract > machine, as clarified via sequence points. With that your "at the point > in time" becomes something like "after all side effects of previous > sequence point, but strictly before all side effects of next sequence > point". > > But doing that would have very far reaching consequences, as already > stated in this thread. The above would basically make undefined behaviour > be reliably countable, and all implementations would need to produce the > same counts of UB. That in turn disables many code movement and > commonization transformations, e.g. this: > > int a = ..., b = ...; > int x = a + b; > int y = a + b; > > can't be transformed into "y = x = a + b" anymore, because the addition > _might_ overflow, and if it does you have two UBs originally but would > have one UB after. I know that you don't want to inhibit this or similar > transformations, but that would be the result of making UB countable, > which is the result of forcing UB to happen at specific points in time. > So, I continue to see problems in precisely specifying what you want, _but > not more_. > > I think all models in which you order the happening of UB with respect to > existing side effects (per abstract machine, so it includes modification > of objects!) have this same problem, it always becomes a side effect > itself (one where you don't specify what actually happens, but a side > effect nontheless) and hence becomes observable. > The C++ committee is currently considering this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1494r2.html I think this explicit barrier-like solution is better than trying to use volatile accesses to achieve something similar. > > >
Re: [PATCH] cprop_hardreg: Workaround for narrow mode != lowpart targets
On Fri, Jan 14, 2022 at 11:42 AM Andreas Krebbel via Gcc-patches
wrote:
>
> On 1/14/22 08:37, Richard Biener wrote:
> ...
> > Can the gist of this bug be put into the GCC bugzilla so the rev can
> > refer to it?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
>
> > Can we have a testcase even?
> The testcase from Jakub is in the BZ. However, since it doesn't fail with
> head I didn't try to
> include it in my patch.
So I also noticed there was PR 101260 which had the exact same
analysis as this patch with respect to s390 and TI mode splitting and
regcprop.
So I marked PR 104034 as a duplicate of PR 101260.
Thanks,
Andrew
>
> > I'm not quite understanding the problem but is it that, say,
> >
> > (subreg:DI (reg:V2DI ..) 0)
> >
> > isn't the same as
> >
> > (lowpart:DI (reg:V2DI ...) 0)
>
> (reg:DI v0) does not match the lower order bits of (reg:TI v0)
>
> > ? The regcprop code looks more like asking whether the larger reg
> > is a composition of multiple other hardregs and will return the specific
> > hardreg corresponding to the lowpart - so like if on s390 the vector
> > registers overlap with some other regset. But then doing the actual
> > accesses via the other regset regs doesn't actually work? Isn't the
> > backend then lying to us (aka the mode_change_ok returns the
> > wrong answer)?
>
> can_change_mode_class should do the right thing. We return false in case
> somebody wants to change TI
> to DI for a vector register. However, the hook never gets called like this
> from regcprop. regcprop
> only asks whether it is ok to change (reg:TI r8) to (reg:DI r8) and that's
> indeed ok.
>
> Before cprop we have:
>
> (insn 175 176 174 3 (set (reg/v:TI 16 %f0 [orig:69 __comp ] [69])
> (reg:TI 8 %r8)) -1
> (nil))
>
>
> (insn 155 124 156 3 (set (reg:DI 6 %r6 [ __comp ])
> (reg:DI 16 %f0)) 1277 {*movdi_64}
> (nil))
>
>
> (insn 156 155 128 3 (set (reg:DI 7 %r7 [orig:69 __comp+8 ] [69])
> (unspec:DI [
> (reg:V2DI 16 %f0)
> (const_int 1 [0x1])
> ] UNSPEC_VEC_EXTRACT)) 409 {*vec_extractv2di}
> (expr_list:REG_DEAD (reg:V2DI 16 %f0)
> (nil)))
>
> So a copy of reg pair r8/r9 is kept in v0==f0. The problem comes from cprop
> assuming that (reg:DI
> f0) refers to the low part of f0 and as a consequence replaces (reg:DI 16
> %f0) with (reg:DI 9 %r9)
> what would be the DImode lowpart of (reg:TI r8)
>
> Insn 155 and 156 are the result of applying the following splitter:
>
> ; Split a VR -> GPR TImode move into 2 vector load GR from VR element.
> ; For the higher order bits we do simply a DImode move while the
> ; second part is done via vec extract. Both will end up as vlgvg.
> (define_split
> [(set (match_operand:TI 0 "register_operand" "")
> (match_operand:TI 1 "register_operand" ""))]
> "TARGET_VX && reload_completed
>&& GENERAL_REG_P (operands[0])
>&& VECTOR_REG_P (operands[1])"
> [(set (match_dup 2) (match_dup 4))
>(set (match_dup 3) (unspec:DI [(match_dup 5) (const_int 1)]
> UNSPEC_VEC_EXTRACT))]
> {
> operands[2] = operand_subword (operands[0], 0, 0, TImode);
> operands[3] = operand_subword (operands[0], 1, 0, TImode);
> operands[4] = gen_rtx_REG (DImode, REGNO (operands[1]));
> operands[5] = gen_rtx_REG (V2DImode, REGNO (operands[1]));
> })
>
> Introducing the (reg:DI 16 %f0) access to the TImode VR is something the
> middle end is not expected
> to do - because we prevent it in can_change_mode_class. However, I don't see
> anything wrong with
> doing that in the splitter. In our backend this is well-defined as being the
> first element in the
> vector register - the high part of the TImode vector register value.
>
> Unfortunately it confuses cprop :(
>
> Andreas
>
>
>
> >
> > How does the stage1 fix, aka "rewrite" of cprop, look like? How can we
> > be sure this hack isn't still present in 10 years from now?
> >
> > Thanks,
> > Richard.
> >
> >> Bootstrapped and regression-tested on s390x.
> >>
> >> Ok?
> >>
> >> gcc/ChangeLog:
> >>
> >> * target.def (narrow_mode_refers_low_part_p): Add new target hook.
> >> * config/s390/s390.c (s390_narrow_mode_refers_low_part_p):
> >> Implement new target hook for IBM Z.
> >> (TARGET_NARROW_MODE_REFERS_LOW_PART_P): New macro.
> >> * regcprop.c (maybe_mode_change): Disable transformation depending
> >> on the new target hook.
> >> ---
> >> gcc/config/s390/s390.c | 14 ++
> >> gcc/regcprop.c | 3 ++-
> >> gcc/target.def | 12 +++-
> >> 3 files changed, 27 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
> >> index 056002e4a4a..aafc6d63be6 100644
> >> --- a/gcc/config/s390/s390.c
> >> +++ b/gcc/config/s390/s390.c
> >> @@ -10488,6 +10488,18 @@ s390_hard_regno_mode_ok (unsigned int regno,
> >> machine_mode mode)
> >>return false;
> >> }
> >>
> >> +/* Implement
Re: [PATCH] cprop_hardreg: Workaround for narrow mode != lowpart targets
On 1/14/22 08:37, Richard Biener wrote:
...
> Can the gist of this bug be put into the GCC bugzilla so the rev can
> refer to it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
> Can we have a testcase even?
The testcase from Jakub is in the BZ. However, since it doesn't fail with head
I didn't try to
include it in my patch.
> I'm not quite understanding the problem but is it that, say,
>
> (subreg:DI (reg:V2DI ..) 0)
>
> isn't the same as
>
> (lowpart:DI (reg:V2DI ...) 0)
(reg:DI v0) does not match the lower order bits of (reg:TI v0)
> ? The regcprop code looks more like asking whether the larger reg
> is a composition of multiple other hardregs and will return the specific
> hardreg corresponding to the lowpart - so like if on s390 the vector
> registers overlap with some other regset. But then doing the actual
> accesses via the other regset regs doesn't actually work? Isn't the
> backend then lying to us (aka the mode_change_ok returns the
> wrong answer)?
can_change_mode_class should do the right thing. We return false in case
somebody wants to change TI
to DI for a vector register. However, the hook never gets called like this from
regcprop. regcprop
only asks whether it is ok to change (reg:TI r8) to (reg:DI r8) and that's
indeed ok.
Before cprop we have:
(insn 175 176 174 3 (set (reg/v:TI 16 %f0 [orig:69 __comp ] [69])
(reg:TI 8 %r8)) -1
(nil))
(insn 155 124 156 3 (set (reg:DI 6 %r6 [ __comp ])
(reg:DI 16 %f0)) 1277 {*movdi_64}
(nil))
(insn 156 155 128 3 (set (reg:DI 7 %r7 [orig:69 __comp+8 ] [69])
(unspec:DI [
(reg:V2DI 16 %f0)
(const_int 1 [0x1])
] UNSPEC_VEC_EXTRACT)) 409 {*vec_extractv2di}
(expr_list:REG_DEAD (reg:V2DI 16 %f0)
(nil)))
So a copy of reg pair r8/r9 is kept in v0==f0. The problem comes from cprop
assuming that (reg:DI
f0) refers to the low part of f0 and as a consequence replaces (reg:DI 16 %f0)
with (reg:DI 9 %r9)
what would be the DImode lowpart of (reg:TI r8)
Insn 155 and 156 are the result of applying the following splitter:
; Split a VR -> GPR TImode move into 2 vector load GR from VR element.
; For the higher order bits we do simply a DImode move while the
; second part is done via vec extract. Both will end up as vlgvg.
(define_split
[(set (match_operand:TI 0 "register_operand" "")
(match_operand:TI 1 "register_operand" ""))]
"TARGET_VX && reload_completed
&& GENERAL_REG_P (operands[0])
&& VECTOR_REG_P (operands[1])"
[(set (match_dup 2) (match_dup 4))
(set (match_dup 3) (unspec:DI [(match_dup 5) (const_int 1)]
UNSPEC_VEC_EXTRACT))]
{
operands[2] = operand_subword (operands[0], 0, 0, TImode);
operands[3] = operand_subword (operands[0], 1, 0, TImode);
operands[4] = gen_rtx_REG (DImode, REGNO (operands[1]));
operands[5] = gen_rtx_REG (V2DImode, REGNO (operands[1]));
})
Introducing the (reg:DI 16 %f0) access to the TImode VR is something the middle
end is not expected
to do - because we prevent it in can_change_mode_class. However, I don't see
anything wrong with
doing that in the splitter. In our backend this is well-defined as being the
first element in the
vector register - the high part of the TImode vector register value.
Unfortunately it confuses cprop :(
Andreas
>
> How does the stage1 fix, aka "rewrite" of cprop, look like? How can we
> be sure this hack isn't still present in 10 years from now?
>
> Thanks,
> Richard.
>
>> Bootstrapped and regression-tested on s390x.
>>
>> Ok?
>>
>> gcc/ChangeLog:
>>
>> * target.def (narrow_mode_refers_low_part_p): Add new target hook.
>> * config/s390/s390.c (s390_narrow_mode_refers_low_part_p):
>> Implement new target hook for IBM Z.
>> (TARGET_NARROW_MODE_REFERS_LOW_PART_P): New macro.
>> * regcprop.c (maybe_mode_change): Disable transformation depending
>> on the new target hook.
>> ---
>> gcc/config/s390/s390.c | 14 ++
>> gcc/regcprop.c | 3 ++-
>> gcc/target.def | 12 +++-
>> 3 files changed, 27 insertions(+), 2 deletions(-)
>>
>> diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
>> index 056002e4a4a..aafc6d63be6 100644
>> --- a/gcc/config/s390/s390.c
>> +++ b/gcc/config/s390/s390.c
>> @@ -10488,6 +10488,18 @@ s390_hard_regno_mode_ok (unsigned int regno,
>> machine_mode mode)
>>return false;
>> }
>>
>> +/* Implement TARGET_NARROW_MODE_REFERS_LOW_PART_P. */
>> +
>> +static bool
>> +s390_narrow_mode_refers_low_part_p (unsigned int regno)
>> +{
>> + if (reg_classes_intersect_p (VEC_REGS, REGNO_REG_CLASS (regno)))
>> +return false;
>> +
>> + return true;
>> +}
>> +
>> +
>> /* Implement TARGET_MODES_TIEABLE_P. */
>>
>> static bool
>> @@ -17472,6 +17484,8 @@ s390_vectorize_vec_perm_const (machine_mode vmode,
>> rtx target, rtx op0, rtx op1,
>> #undef TARGET_VECTORIZE_VEC_PERM_CONST
>> #define
Re: gcc/configure: out of date
Excerpts from Martin Liška's message of Januar 14, 2022 4:51 pm: > On 1/14/22 16:46, Martin Liška wrote: >> Hello. >> >> I noticed that when I run: >> ACLOCAL=~/bin/automake-1.15.1/bin/aclocal >> AUTOMAKE=~/bin/automake-1.15.1/bin/automake autoconf >> >> in gcc subfolder I get the following diff: > > Have it, started with: > Good spot! Thanks. Iain.
[Bug rtl-optimization/101260] [10/11/12 Regression] regcprop: Determine subreg offset depending on endianness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260 --- Comment #16 from Andrew Pinski --- I wonder if makes sense to create either a RTL testcase which fails on s390 still (or did in GCC 10)?
[Bug rtl-optimization/101260] [10/11/12 Regression] regcprop: Determine subreg offset depending on endianness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100342 --- Comment #15 from Andrew Pinski --- And PR 100342.
[Bug rtl-optimization/101260] [10/11/12 Regression] regcprop: Determine subreg offset depending on endianness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98694 --- Comment #14 from Andrew Pinski --- Hmm, PR 98694 seems related too.
[Bug rtl-optimization/101260] [10/11/12 Regression] regcprop: Determine subreg offset depending on endianness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260 --- Comment #13 from Andrew Pinski --- (In reply to Andrew Pinski from comment #12) > A patch was submitted here: > https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581172.html Another patch was submitted here too: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588407.html
[Bug rtl-optimization/101260] [10/11/12 Regression] regcprop: Determine subreg offset depending on endianness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260 --- Comment #12 from Andrew Pinski --- A patch was submitted here: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581172.html
[Bug rtl-optimization/101260] [10/11/12 Regression] regcprop: Determine subreg offset depending on endianness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260 Andrew Pinski changed: What|Removed |Added CC||krebbel at gcc dot gnu.org --- Comment #11 from Andrew Pinski --- *** Bug 104034 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/104034] Miscompilation of LLVM on s390x with -march=z13 -mtune=z14 in GCC 8.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- PR 101260 has a testcase that fails in GCC 11 so marking as a dup of that one. The anlysis is even the same. *** This bug has been marked as a duplicate of bug 101260 ***
[Bug rtl-optimization/104034] Miscompilation of LLVM on s390x with -march=z13 -mtune=z14 in GCC 8.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99221, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101260 --- Comment #1 from Andrew Pinski --- Looks so much related to PR 101260.
[Bug target/104005] Regression on arm+sve with -O2 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104005 rsandifo at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-01-14 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 CC||rsandifo at gcc dot gnu.org --- Comment #1 from rsandifo at gcc dot gnu.org --- Thanks for the report. I'll try to reproduce this next week.
[Bug rtl-optimization/104034] Miscompilation of LLVM on s390x with -march=z13 -mtune=z14 in GCC 8.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034 Andreas Krebbel changed: What|Removed |Added Last reconfirmed||2022-01-14 Ever confirmed|0 |1 Priority|P3 |P2 Keywords||wrong-code Host||s390x Status|UNCONFIRMED |NEW
[Bug rtl-optimization/104034] New: Miscompilation of LLVM on s390x with -march=z13 -mtune=z14 in GCC 8.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
Bug ID: 104034
Summary: Miscompilation of LLVM on s390x with -march=z13
-mtune=z14 in GCC 8.x
Product: gcc
Version: 8.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 52194
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52194=edit
Testcase
Initial analysis done by Jakub Jelinek as part of:
https://bugzilla.redhat.com/show_bug.cgi?id=2028609
The following testcase is miscompiled on s390x with
g++ -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -O2
-fPIC -fno-exceptions -fno-rtti -std=c++14 -mlong-double-128 -march=z13
-mtune=z14
both with the RHEL gcc 8.x and with upstream 8.5.0.
When miscompiled, it prints something like
__insertion_sort 0x3ffd74fd310 0x3ffd74fd348 0xdeadbeefcafebabe
0xdeadbeefcafebabe
__insertion_sort 0x3ffd74fd348 0x3ffd74fd348 0x10006b8 0xdeadbeefcafebabe
rather than
__insertion_sort 0x3ffd74fd310 0x3ffd74fd348 0x10006b8 0xdeadbeefcafebabe
__insertion_sort 0x3ffd74fd348 0x3ffd74fd348 0x10006b8 0xdeadbeefcafebabe
The interesting part is below, .cfi_* directives removed for brevity.
On entry, this function has 3 pointers in %r2, %r3 and %r4 registers, and
%r5 is pointer to the 16-byte function_ref - object with
trivially copyable class
containing 2 8-byte members.
_ZSt24__merge_sort_with_bufferIPPvS1_N4llvm12function_refIFbS0_S0_vT_S6_T0_T1_:
stmg%r6,%r15,48(%r15)
lgr %r14,%r15
lay %r15,-248(%r15)
aghi%r14,-32
std %f8,0(%r14)
std %f12,8(%r14)
std %f14,16(%r14)
std %f9,24(%r14)
sgrk%r11,%r3,%r2
lgr %r1,%r4
srag%r13,%r11,3
agr %r1,%r11
lmg %r8,%r9,0(%r5)
stmg%r8,%r9,160(%r15)
! The above stores the whole 16-byte function_ref correctly to %r15+160
cgijle %r11,48,.L13
vlvgp %v0,%r8,%r9
ldgr%f9,%r1
ldgr%f12,%r4
la %r1,200(%r15)
lgr %r10,%r3
stg %r11,176(%r15)
ldgr%f8,%r2
lgr %r6,%r9
vlgvg %r7,%v0,1
stmg%r8,%r9,184(%r15)
! So does the above
lgr %r8,%r1
.L14:
la %r11,56(%r2)
lgr %r4,%r8
lgr %r3,%r11
stmg%r6,%r7,200(%r15)
! But this one actually stores both 8-byte words the same to %r15+160, and
%r15+200 is passed as %r4 to the function
brasl
%r14,_ZSt16__insertion_sortIPPvN4llvm12function_refIFbS0_S0_vT_S6_T0_@PLT
In *.postreload, we have still correct:
(insn 16 12 166 2 (set (reg/v:TI 16 %f0 [orig:69 __comp ] [69])
(reg:TI 8 %r8)) 1268 {movti}
(nil))
...
(insn 137 136 140 3 (set (reg/v:TI 6 %r6 [orig:69 __comp ] [69])
(reg/v:TI 16 %f0 [orig:69 __comp ] [69])) 1268 {movti}
(nil))
The code spills it to 128-bit %f0 register and loads it back from it.
Next, split2 pass splits the latter (but not the former) into:
(insn 167 136 168 3 (set (reg:DI 6 %r6 [ __comp ])
(reg:DI 16 %f0)) 1269 {*movdi_64}
(nil))
(insn 168 167 140 3 (set (reg:DI 7 %r7 [orig:69 __comp+8 ] [69])
(unspec:DI [
(reg:V2DI 16 %f0)
(const_int 1 [0x1])
] UNSPEC_VEC_EXTRACT)) 402 {*vec_extractv2di}
(nil))
and finally cprop_hardreg seeing
(insn 187 188 186 3 (set (reg/v:TI 16 %f0 [orig:69 __comp ] [69])
(reg:TI 8 %r8)) 1268 {movti}
(nil))
changes insn 167 to:
(insn 167 136 168 3 (set (reg:DI 6 %r6 [ __comp ])
(reg:DI 9 %r9 [16])) 1269 {*movdi_64}
(nil))
I'm not sure if this is a bug in the
; Split a VR -> GPR TImode move into 2 vector load GR from VR element.
; For the higher order bits we do simply a DImode move while the
; second part is done via vec extract. Both will end up as vlgvg.
(define_split
[(set (match_operand:TI 0 "register_operand" "")
(match_operand:TI 1 "register_operand" ""))]
"TARGET_VX && reload_completed
&& GENERAL_REG_P (operands[0])
&& VECTOR_REG_P (operands[1])"
[(set (match_dup 2) (match_dup 4))
(set (match_dup 3) (unspec:DI [(match_dup 5) (const_int 1)]
UNSPEC_VEC_EXTRACT))]
{
operands[2] = operand_subword (operands[0], 0, 0, TImode);
operands[3] = operand_subword (operands[0], 1, 0, TImode);
operands[4] = gen_rtx_REG (DImode, REGNO (operands[1]));
operands[5] = gen_rtx_REG (V2DImode, REGNO (operands[1]));
})
splitter, in cprop_hardreg or the s390x representation of those TImodes in
floating point registers.
In GCC 9 it got "fixed" with https://gcc.gnu.org/r9-3763-gef976be1a23a517 but
that just means it went latent.
And I can't reproduce it even with upstream GCC 9 branch with r9-3763 reverted
- some
[Bug other/104033] New: [12 regression] g++.dg/cpp0x/constexpr-compare2.C fails with excess errors after r12-6578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104033 Bug ID: 104033 Summary: [12 regression] g++.dg/cpp0x/constexpr-compare2.C fails with excess errors after r12-6578 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:d686d5d85c23451c03799dc55e456b73065f7333, r12-6578 make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/cpp0x/constexpr-compare2.C" FAIL: g++.dg/cpp0x/constexpr-compare2.C -std=c++14 (test for excess errors) FAIL: g++.dg/cpp0x/constexpr-compare2.C -std=c++17 (test for excess errors) FAIL: g++.dg/cpp0x/constexpr-compare2.C -std=c++2a (test for excess errors) # of unexpected failures3 # of unsupported tests 1 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++14 -pedantic-errors -Wno-long-long -fdelete-null-pointer-checks -S -o constexpr-compare2.s^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C:7:17: error: non-constant condition for static assertion^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C:7:17: error: '(f != g)' is not a constant expression^M spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ exceptions_enabled603004.cc -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -S -o exceptions_enabled603004.s^M FAIL: g++.dg/cpp0x/constexpr-compare2.C -std=c++14 (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C:7:17: error: non-constant condition for static assertion /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C:7:17: error: '(f != g)' is not a constant expression spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -fdelete-null-pointer-checks -S -o constexpr-compare2.s^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C:7:17: error: non-constant condition for static assertion^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C:7:17: error: '(f != g)' is not a constant expression^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C:10:20: error: non-constant condition for static assertion^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C:10:20: error: '(::_FUN != ::_FUN)' is not a constant expression^M commit d686d5d85c23451c03799dc55e456b73065f7333 (HEAD, refs/bisect/bad) Author: Jakub Jelinek Date: Fri Jan 14 12:07:49 2022 +0100 c++: Reject in constant evaluation address comparisons of start of one var and end of another [PR89074]
Re: [Patch][V4][Patch 2/2]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables.
On 1/14/22 11:29, Qing Zhao wrote: On Jan 14, 2022, at 12:11 PM, Martin Sebor wrote: On 1/14/22 09:30, Qing Zhao wrote: On Jan 14, 2022, at 6:45 AM, Richard Biener wrote: On Thu, Jan 13, 2022 at 2:45 AM Qing Zhao wrote: Hi, Richard, This is the updated version for the second patch, which is mainly the change for "Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables”. In this update, I mainly made the following change: 1. Delete “repl_var”, use the var_def_stmt, i.e, the call to .DEFERRED_INIT to record the warning suppressed info. 2. Add and change the comments in multiple places to make the change more readable. Now, for the deleted variable, we will get the necessary info to report warning from the call to .DEFERRED_INIT. A. the name string of DECL from the 3rd parameter of the call; B. the location of the DECL from the location of the call; C. the call can also be used to hold the information on whether the warning has been issued or not to suppress warning messages when needed; Please see the detailed description below for the problem and solution of this patch. This patch has been bootstrapped and regressing tested on both X86 and aarch64. Okay for GCC12? I think the change to split "%qD is used uninitialized" is bad for i8n though it seems like none of the strings passed to warn_uninit are currently marked for localization. I suppose there's lazy matching with the exact same strings passed to warning_at around like 641 but after your change those will no longer match up, Silly question: What does the above “641” mean? At around line 641 :) I thought of this, but I didn’t find a meaningful statement around line 641 in tree-ssa-uninit.c… 636 found_alloc = true; 637 break; 638 } 639 640 if (!is_gimple_assign (def_stmt)) 641 break; 642 643 tree_code code = gimple_assign_rhs_code (def_stmt); 644 if (code != ADDR_EXPR && code != POINTER_PLUS_EXPR) 645 break; at least for the "%qs ..." case constructed. I think a better way (for i8n) would be to pass down a flag whether it is "may" or "is" and have the full translatable strings literally passed to warning_at at the expense of some code duplication. Actually the extra flag is unnecessary, the OPT_W... we pass is already fully specifying that. The only issue with the above change is: among the 4 calls to “warn_uninit” as following: if (use_stmt) warn_uninit (OPT_Wuninitialized, def, SSA_NAME_VAR (def), -"%qD is used uninitialized", use_stmt); +"is used uninitialized", use_stmt); } } @@ -932,10 +1015,10 @@ warn_uninitialized_vars (bool wmaybe_uninit) tree use = USE_FROM_PTR (use_p); if (wlims.always_executed) warn_uninit (OPT_Wuninitialized, use, SSA_NAME_VAR (use), -"%qD is used uninitialized", stmt); +"is used uninitialized", stmt); else if (wmaybe_uninit) warn_uninit (OPT_Wmaybe_uninitialized, use, SSA_NAME_VAR (use), -"%qD may be used uninitialized", stmt); +"may be used uninitialized", stmt); } /* For limiting the alias walk below we count all @@ -1182,7 +1265,7 @@ warn_uninitialized_phi (gphi *phi, vec *worklist, warn_uninit (OPT_Wmaybe_uninitialized, uninit_op, SSA_NAME_VAR (uninit_op), - "%qD may be used uninitialized in this function", + "may be used uninitialized in this function", uninit_use_stmt, loc); All the strings passed map well with the OPT_W… except the last one, since the last one has an additional string “in this function” at the end. However, since the last call has the last argument “loc” been NULL, maybe we can use this to distinguish. Now that diagnostics are prefixed by something like "In function 'foo': the "in this function" part is superfluous and could be removed from all warning messages. Okay, so, you mean that it’s safe to just remove “in this function” from the last callsite? Yes, I would remove it. It might require some cleanup in the test suite but I wouldn't expect it to be too bad. When there's no location (i.e., loc is UNKNOWN_LOCATION) the called code tries to derive a location from the context. When it can't, it won't point anywhere useful, so if that case ever comes up here it should probably be handled by using the location of the curly brace closing the function definition. You mean the following in the routine warn_uninit: /* Use either the location of the read statement or that of the PHI argument, or that of the uninitialized variable, in that order, whichever is valid. */ location_t location = UNKNOWN_LOCATION; if (gimple_has_location
[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104026 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #15 from rsandifo at gcc dot gnu.org --- I've pushed a patch to fix the problem Tobias mentioned in comment 11, which fixes the crashes I was seeing on SVE. I don't *think* anything else is needed, since VECT_PARTIAL_BIAS_UNSUPPORTED should never get stored into the loop_vec_info. I'd like to look at it again sometime that isn't last thing on a Friday though, so leaving open for now.
[Bug target/100952] [12 regression] several test case failures after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952 --- Comment #15 from seurer at gcc dot gnu.org --- Looking through test results I see that gcc.target/powerpc/pr56605.c and gcc.target/powerpc/prefix-no-update.c are still failing today.
[pushed] vect: Fix uninitialised variable PR104026
As noted by Tobias in the PR, the loop_vec_info constructor wasn't initializing the new partial_load_store_bias field. Tested on aarch64-linux-gnu and pushed as obvious. Richard gcc/ PR middle-end/104026 * tree-vect-loop.c (_loop_vec_info::_loop_vec_info): Initialize partial_load_store_bias. --- gcc/tree-vect-loop.c | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c index 1dbdb9e5fa0..f1410b03fb3 100644 --- a/gcc/tree-vect-loop.c +++ b/gcc/tree-vect-loop.c @@ -846,6 +846,7 @@ _loop_vec_info::_loop_vec_info (class loop *loop_in, vec_info_shared *shared) can_use_partial_vectors_p (param_vect_partial_vector_usage != 0), using_partial_vectors_p (false), epil_using_partial_vectors_p (false), +partial_load_store_bias (0), peeling_for_gaps (false), peeling_for_niter (false), no_data_dependencies (false), -- 2.25.1
[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104026 --- Comment #14 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:79ae13067f6afabcbae4784ada07dcbb7f00953e commit r12-6594-g79ae13067f6afabcbae4784ada07dcbb7f00953e Author: Richard Sandiford Date: Fri Jan 14 18:41:12 2022 + vect: Fix uninitialised variable PR104026 As noted by Tobias in the PR, the loop_vec_info constructor wasn't initializing the new partial_load_store_bias field. gcc/ PR middle-end/104026 * tree-vect-loop.c (_loop_vec_info::_loop_vec_info): Initialize partial_load_store_bias.
[Bug target/101022] rs6000: __builtin_altivec_vcmpequt expands to wrong pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Bill Schmidt --- Looks like this was fixed some time ago.
[Bug target/100952] [12 regression] several test case failures after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #14 from Bill Schmidt --- Which tests are still failing?
Re: [PATCH] RISC-V: Document the degree of position independence that medany affords
On Thu, 13 Jan 2022 21:54:45 PST (-0800), gcc-patches@gcc.gnu.org wrote: On Fri, Jan 14, 2022 at 4:42 AM Palmer Dabbelt wrote: The code generated by -mcmodel=medany is defined to be position-independent, but is not guarnteed to function correctly when linked into position-independent executables or libraries. See the recent discussion at the psABI specification [1] for more details. [1]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/245 gcc/ChangeLog: * doc/invoke.texi: Document the degree of position independence that -mcmodel=medany affords. Signed-off-by: Palmer Dabbelt --- gcc/doc/invoke.texi | 4 1 file changed, 4 insertions(+) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 5504971ea81..eaba12bb61f 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -27568,6 +27568,10 @@ Generate code for the medium-any code model. The program and its statically defined symbols must be within any single 2 GiB address range. Programs can be statically or dynamically linked. +The code generated by the medium-any code model is position-independent, but is +not guarnteed to function correctly when linked into position-independent +executables or libraries. Typo: guarnteed -> guaranteed Thanks. IDK why I still can't figure out how to spell that word ;) I think it would be more helpful from a user perspective if a hint to the solution (i.e. use -fPIC) would be there. What about something like this: """ The code generated by the medium-any code model is position-independent. However, to link such code into position-independent executables or libraries, the corresponding flags to enable position-independent code generation still need to be provided (e.g. -fPIC or -fPIE). """ I'd tried to make this more detailed, but everything I came up with was too verbose. What you've got reads well, but it's not entirely accurate: * A lot of distros are defaulting to PIE now and there's "-fpic" and "-fpie", so it's really more of a "maybe pass -fpic, -fpie, -fPIE or -fPIC but definitely don't pass the -no versions of those" requirement. * The code sequences generated by medany (without any of those PIC/pie options enabled) can be linked into position-independent executables, it's just might not result in symbol addresses that resolve as expected. Given that those constraints are well documented elsewhere (the GCC documentation for the arguments, and the psABI threads for the compiler/linker thing) I don't think it's strictly necessary to include everything here. The rest of these blurbs are pretty terse and require users to understand these non-local definitions, so it's certainly in line with what's there. That said, I do think this one is pretty tricky (it certainly tricked me), so if you or someone else has a better way of describing the actual constraints directly here then I'm all ears -- I couldn't come up with anything, though. [As an aside, when I had the -fPIC blurb in medany I'd also added it to medlow as it's exactly the same there, but that also seemed too verbose.] @item -mexplicit-relocs @itemx -mno-exlicit-relocs Use or do not use assembler relocation operators when dealing with symbolic -- 2.32.0
Re: [Patch][V4][Patch 2/2]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables.
> On Jan 14, 2022, at 12:11 PM, Martin Sebor wrote: > > On 1/14/22 09:30, Qing Zhao wrote: >>> On Jan 14, 2022, at 6:45 AM, Richard Biener >>> wrote: >>> >>> On Thu, Jan 13, 2022 at 2:45 AM Qing Zhao wrote: Hi, Richard, This is the updated version for the second patch, which is mainly the change for "Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables”. In this update, I mainly made the following change: 1. Delete “repl_var”, use the var_def_stmt, i.e, the call to .DEFERRED_INIT to record the warning suppressed info. 2. Add and change the comments in multiple places to make the change more readable. Now, for the deleted variable, we will get the necessary info to report warning from the call to .DEFERRED_INIT. A. the name string of DECL from the 3rd parameter of the call; B. the location of the DECL from the location of the call; C. the call can also be used to hold the information on whether the warning has been issued or not to suppress warning messages when needed; Please see the detailed description below for the problem and solution of this patch. This patch has been bootstrapped and regressing tested on both X86 and aarch64. Okay for GCC12? >>> >>> I think the change to split "%qD is used uninitialized" is bad for i8n >>> though it seems >>> like none of the strings passed to warn_uninit are currently marked >>> for localization. >>> I suppose there's lazy matching with the exact same strings passed to >>> warning_at around like 641 but after your change those will no longer match >>> up, >> Silly question: What does the above “641” mean? > > At around line 641 :) I thought of this, but I didn’t find a meaningful statement around line 641 in tree-ssa-uninit.c… 636 found_alloc = true; 637 break; 638 } 639 640 if (!is_gimple_assign (def_stmt)) 641 break; 642 643 tree_code code = gimple_assign_rhs_code (def_stmt); 644 if (code != ADDR_EXPR && code != POINTER_PLUS_EXPR) 645 break; > >>> at least for the "%qs ..." case constructed. I think a better way >>> (for i8n) would be >>> to pass down a flag whether it is "may" or "is" and have the full >>> translatable >>> strings literally passed to warning_at at the expense of some code >>> duplication. >>> Actually the extra flag is unnecessary, the OPT_W... we pass is already >>> fully >>> specifying that. >> The only issue with the above change is: among the 4 calls to >> “warn_uninit” as following: >>if (use_stmt) >> warn_uninit (OPT_Wuninitialized, def, SSA_NAME_VAR (def), >> -"%qD is used uninitialized", use_stmt); >> +"is used uninitialized", use_stmt); >> } >> } >> @@ -932,10 +1015,10 @@ warn_uninitialized_vars (bool wmaybe_uninit) >> tree use = USE_FROM_PTR (use_p); >> if (wlims.always_executed) >> warn_uninit (OPT_Wuninitialized, use, SSA_NAME_VAR (use), >> -"%qD is used uninitialized", stmt); >> +"is used uninitialized", stmt); >> else if (wmaybe_uninit) >> warn_uninit (OPT_Wmaybe_uninitialized, use, SSA_NAME_VAR >> (use), >> -"%qD may be used uninitialized", stmt); >> +"may be used uninitialized", stmt); >> } >> /* For limiting the alias walk below we count all >> @@ -1182,7 +1265,7 @@ warn_uninitialized_phi (gphi *phi, vec >> *worklist, >>warn_uninit (OPT_Wmaybe_uninitialized, uninit_op, >>SSA_NAME_VAR (uninit_op), >> - "%qD may be used uninitialized in this function", >> + "may be used uninitialized in this function", >>uninit_use_stmt, loc); >> All the strings passed map well with the OPT_W… except the last one, since >> the last one has an additional string “in this function” at the end. >> However, since the last call has the last argument “loc” been NULL, maybe we >> can use this to distinguish. > > Now that diagnostics are prefixed by something like "In function 'foo': > the "in this function" part is superfluous and could be removed from > all warning messages. Okay, so, you mean that it’s safe to just remove “in this function” from the last callsite? > > When there's no location (i.e., loc is UNKNOWN_LOCATION) the called > code tries to derive a location from the context. When it can't, it > won't point anywhere useful, so if that case ever comes up here it > should probably be handled by using the location of the curly brace > closing the function definition. You mean the following in the routine warn_uninit: /* Use either the location of the read statement or that
[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031
--- Comment #3 from Andrew Pinski ---
Reduced testcase without any headers:
struct vector
{
vector(){} ~vector(){}
};
struct Info {
vector args;
int arity = 0;
};
struct RegisterPrimOp
{
[[gnu::noipa, gnu::noinline]]
RegisterPrimOp(Info info) {
if (info.arity != 0)
__builtin_trap();
}
};
static RegisterPrimOp s_op({
.args = vector{},
.arity = 0,
});
int main() {}
[Bug fortran/103782] [9/10/11/12 Regression] internal error occurs when overloading intrinsic since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a4a8ae123cd70188e4b4bf5e288a84e0a76fb0fd commit r12-6593-ga4a8ae123cd70188e4b4bf5e288a84e0a76fb0fd Author: Harald Anlauf Date: Thu Jan 13 21:50:45 2022 +0100 Fortran: fix ICE overloading elemental intrinsics gcc/fortran/ChangeLog: PR fortran/103782 * expr.c (gfc_simplify_expr): Adjust logic for when to scalarize a call of an intrinsic which may have been overloaded. gcc/testsuite/ChangeLog: PR fortran/103782 * gfortran.dg/overload_4.f90: New test.
[PATCH 3/3] tree-cfg: check placement of returns_twice calls
When a returns_twice call has an associated abnormal edge, the edge
corresponds to the "second return" from the call. It wouldn't make sense
if any executable statements appeared between the call and the
destination of the edge (they wouldn't be re-executed upon the "second
return"), so verify that.
gcc/ChangeLog:
* tree-cfg.c (gimple_verify_flow_info): Check placement of
returns_twice calls.
---
gcc/tree-cfg.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index a99f1acb4..70bd31d3d 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -5644,6 +5644,7 @@ gimple_verify_flow_info (void)
}
/* Verify that body of basic block BB is free of control flow. */
+ bool seen_nondebug_stmt = false;
for (; !gsi_end_p (gsi); gsi_next ())
{
gimple *stmt = gsi_stmt (gsi);
@@ -5664,6 +5665,38 @@ gimple_verify_flow_info (void)
gimple_label_label (label_stmt), bb->index);
err = 1;
}
+
+ /* Check that no statements appear between a returns_twice call
+and its associated abnormal edge. */
+ if (gimple_code (stmt) == GIMPLE_CALL
+ && gimple_call_flags (stmt) & ECF_RETURNS_TWICE)
+ {
+ const char *misplaced = NULL;
+ /* TM is an exception: it points abnormal edges just after the
+call that starts a transaction, i.e. it must end the BB. */
+ if (gimple_call_builtin_p (stmt, BUILT_IN_TM_START))
+ {
+ if (single_succ_p (bb)
+ && bb_has_abnormal_pred (single_succ (bb))
+ && !gsi_one_nondebug_before_end_p (gsi))
+ misplaced = "not last";
+ }
+ else
+ {
+ if (seen_nondebug_stmt
+ && bb_has_abnormal_pred (bb))
+ misplaced = "not first";
+ }
+ if (misplaced)
+ {
+ error ("returns_twice call is %s in basic block %d",
+misplaced, bb->index);
+ print_gimple_stmt (stderr, stmt, 0, TDF_SLIM);
+ err = 1;
+ }
+ }
+ if (!is_gimple_debug (stmt))
+ seen_nondebug_stmt = true;
}
gsi = gsi_last_nondebug_bb (bb);
--
2.33.1
[PATCH 2/3] tree-cfg: do not duplicate returns_twice calls
A returns_twice call may have associated abnormal edges that correspond
to the "second return" from the call. If the call is duplicated, the
copies of those edges also need to be abnormal, but e.g. tracer does not
enforce that. Just prohibit the (unlikely to be useful) duplication.
gcc/ChangeLog:
* tree-cfg.c (gimple_can_duplicate_bb_p): Reject blocks with
calls that may return twice.
---
gcc/tree-cfg.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index b7fe313b7..a99f1acb4 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -6304,12 +6304,15 @@ gimple_can_duplicate_bb_p (const_basic_block bb)
{
gimple *g = gsi_stmt (gsi);
- /* An IFN_GOMP_SIMT_ENTER_ALLOC/IFN_GOMP_SIMT_EXIT call must be
+ /* Prohibit duplication of returns_twice calls, otherwise associated
+abnormal edges also need to be duplicated properly.
+An IFN_GOMP_SIMT_ENTER_ALLOC/IFN_GOMP_SIMT_EXIT call must be
duplicated as part of its group, or not at all.
The IFN_GOMP_SIMT_VOTE_ANY and IFN_GOMP_SIMT_XCHG_* are part of such a
group, so the same holds there. */
if (is_gimple_call (g)
- && (gimple_call_internal_p (g, IFN_GOMP_SIMT_ENTER_ALLOC)
+ && (gimple_call_flags (g) & ECF_RETURNS_TWICE
+ || gimple_call_internal_p (g, IFN_GOMP_SIMT_ENTER_ALLOC)
|| gimple_call_internal_p (g, IFN_GOMP_SIMT_EXIT)
|| gimple_call_internal_p (g, IFN_GOMP_SIMT_VOTE_ANY)
|| gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_BFLY)
--
2.33.1
[PATCH 1/3] tree-ssa-sink: do not sink to in front of setjmp
gcc/ChangeLog:
* tree-ssa-sink.c (select_best_block): Punt if selected block
has incoming abnormal edges.
gcc/testsuite/ChangeLog:
* gcc.dg/setjmp-7.c: New test.
---
gcc/testsuite/gcc.dg/setjmp-7.c | 13 +
gcc/tree-ssa-sink.c | 6 ++
2 files changed, 19 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/setjmp-7.c
diff --git a/gcc/testsuite/gcc.dg/setjmp-7.c b/gcc/testsuite/gcc.dg/setjmp-7.c
new file mode 100644
index 0..44b5bcbfa
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/setjmp-7.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-guess-branch-probability -w" } */
+/* { dg-require-effective-target indirect_jumps } */
+
+struct __jmp_buf_tag { };
+typedef struct __jmp_buf_tag jmp_buf[1];
+struct globals { jmp_buf listingbuf; };
+extern struct globals *const ptr_to_globals;
+void foo()
+{
+if ( _setjmp ( ((*ptr_to_globals).listingbuf )))
+ ;
+}
diff --git a/gcc/tree-ssa-sink.c b/gcc/tree-ssa-sink.c
index 66d7ae89e..016ecbaec 100644
--- a/gcc/tree-ssa-sink.c
+++ b/gcc/tree-ssa-sink.c
@@ -208,6 +208,12 @@ select_best_block (basic_block early_bb,
temp_bb = get_immediate_dominator (CDI_DOMINATORS, temp_bb);
}
+ /* Placing a statement before a setjmp-like function would be invalid
+ (it cannot be reevaluated when execution follows an abnormal edge).
+ If we selected a block with abnormal predecessors, just punt. */
+ if (bb_has_abnormal_pred (best_bb))
+return early_bb;
+
/* If we found a shallower loop nest, then we always consider that
a win. This will always give us the most control dependent block
within that loop nest. */
--
2.33.1
Re: [RFC PATCH] tree-ssa-sink: do not sink to in front of setjmp
> I approved the initial sink patch (maybe not clearly enough). I wasn't entirely happy with that patch. The new version solves this better. > Can you open > a bugreport about the missing CFG verification and list the set of FAILs > (all errors in some passes similar to the one you fixed in sinking I guess)? > It indeed sounds like something to tackle during next stage1 (unless you > already narrowed down the culprit to a single offender...) Most of the failures were related to transactional memory, and the rest are seemingly solved by forbidding duplication of returns_twice calls. In reply to this email I'm sending three patches, the first is a revised patch for tree-ssa-sink, the second forbids duplication of setjmp-like calls, and the third implements the checks in verify_flow_info: tree-ssa-sink: do not sink to in front of setjmp tree-cfg: do not duplicate returns_twice calls tree-cfg: check placement of returns_twice calls gcc/testsuite/gcc.dg/setjmp-7.c | 13 +++ gcc/tree-cfg.c | 40 +++-- gcc/tree-ssa-sink.c | 6 + 3 files changed, 57 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/setjmp-7.c -- 2.33.1
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 101475, which changed state. Bug 101475 Summary: missing -Wstringop-overflow storing a compound literal https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101475 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/101475] missing -Wstringop-overflow storing a compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101475 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed in r12-6592.
[Bug middle-end/101475] missing -Wstringop-overflow storing a compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101475 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:72332337e3d8acbb21398b8d123f1bfe77a8327e commit r12-6592-g72332337e3d8acbb21398b8d123f1bfe77a8327e Author: Martin Sebor Date: Fri Jan 14 11:13:08 2022 -0700 Use enclosing object size if it's smaller than member [PR 101475]. Resolves: PR middle-end/101475 - missing -Wstringop-overflow storing a compound literal gcc/ChangeLog: PR middle-end/101475 * pointer-query.cc (handle_component_ref): Use the size of the enclosing object if it's smaller than the member. gcc/testsuite/ChangeLog: PR middle-end/101475 * gcc.dg/Wstringop-overflow-15.c: Remove xfails. * gcc.dg/Wstringop-overflow-68.c: Adjust, remove xfails. * gcc.dg/Wstringop-overflow-88.c: New test.
[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031
--- Comment #2 from Andrew Pinski ---
I can remove std::string but not figure out how to remove std::vector yet:
#include
#include
struct string
{
string(int){}
};
struct allocator
{
allocator(){}
};
struct vector
{
vector(allocator t = allocator{}){}
vector(string, allocator t = allocator{}){}
vector(std::initializer_list&, allocator t = allocator{}){}
};
#if 1
typedef std::vector t;
#else
typedef vector t;
#endif
struct Info {
t args;
int arity;
};
struct RegisterPrimOp
{
RegisterPrimOp(Info && info) __attribute__((noipa, noinline)) {
if (info.arity != 0)
__builtin_trap();
}
};
static RegisterPrimOp s_op({
.args = {1},
.arity = 0,
});
int main() {}
Re: [Patch][V4][Patch 2/2]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables.
On 1/14/22 09:30, Qing Zhao wrote:
On Jan 14, 2022, at 6:45 AM, Richard Biener wrote:
On Thu, Jan 13, 2022 at 2:45 AM Qing Zhao wrote:
Hi, Richard,
This is the updated version for the second patch, which is mainly the change for
"Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables”.
In this update, I mainly made the following change:
1. Delete “repl_var”, use the var_def_stmt, i.e, the call to .DEFERRED_INIT to
record the warning suppressed info.
2. Add and change the comments in multiple places to make the change more
readable.
Now, for the deleted variable, we will get the necessary info to report warning
from the call to .DEFERRED_INIT.
A. the name string of DECL from the 3rd parameter of the call;
B. the location of the DECL from the location of the call;
C. the call can also be used to hold the information on whether the warning
has been issued or not to suppress warning messages when needed;
Please see the detailed description below for the problem and solution of this
patch.
This patch has been bootstrapped and regressing tested on both X86 and aarch64.
Okay for GCC12?
I think the change to split "%qD is used uninitialized" is bad for i8n
though it seems
like none of the strings passed to warn_uninit are currently marked
for localization.
I suppose there's lazy matching with the exact same strings passed to
warning_at around like 641 but after your change those will no longer match up,
Silly question: What does the above “641” mean?
At around line 641 :)
at least for the "%qs ..." case constructed. I think a better way
(for i8n) would be
to pass down a flag whether it is "may" or "is" and have the full translatable
strings literally passed to warning_at at the expense of some code duplication.
Actually the extra flag is unnecessary, the OPT_W... we pass is already fully
specifying that.
The only issue with the above change is: among the 4 calls to “warn_uninit”
as following:
if (use_stmt)
warn_uninit (OPT_Wuninitialized, def, SSA_NAME_VAR (def),
-"%qD is used uninitialized", use_stmt);
+"is used uninitialized", use_stmt);
}
}
@@ -932,10 +1015,10 @@ warn_uninitialized_vars (bool wmaybe_uninit)
tree use = USE_FROM_PTR (use_p);
if (wlims.always_executed)
warn_uninit (OPT_Wuninitialized, use, SSA_NAME_VAR (use),
-"%qD is used uninitialized", stmt);
+"is used uninitialized", stmt);
else if (wmaybe_uninit)
warn_uninit (OPT_Wmaybe_uninitialized, use, SSA_NAME_VAR (use),
-"%qD may be used uninitialized", stmt);
+"may be used uninitialized", stmt);
}
/* For limiting the alias walk below we count all
@@ -1182,7 +1265,7 @@ warn_uninitialized_phi (gphi *phi, vec *worklist,
warn_uninit (OPT_Wmaybe_uninitialized, uninit_op,
SSA_NAME_VAR (uninit_op),
- "%qD may be used uninitialized in this function",
+ "may be used uninitialized in this function",
uninit_use_stmt, loc);
All the strings passed map well with the OPT_W… except the last one, since the
last one has an additional string “in this function” at the end.
However, since the last call has the last argument “loc” been NULL, maybe we
can use this to distinguish.
Now that diagnostics are prefixed by something like "In function 'foo':
the "in this function" part is superfluous and could be removed from
all warning messages.
When there's no location (i.e., loc is UNKNOWN_LOCATION) the called
code tries to derive a location from the context. When it can't, it
won't point anywhere useful, so if that case ever comes up here it
should probably be handled by using the location of the curly brace
closing the function definition.
Martin
Instead of doing
+ if (gimple_call_internal_p (var_def_stmt, IFN_DEFERRED_INIT))
+ {
+ /* Ignore the call to .DEFERRED_INIT that define the original
+var itself as the following case:
+ temp = .DEFERRED_INIT (4, 2, â~@~\alt_reloc");
+ alt_reloc = temp;
+In order to avoid generating warning for the fake usage
+at alt_reloc = temp.
...
I thought of many options, none really very appealing so I guess we have to
go with this for now.
I agree with you, this is really ugly, I am not very comfortable myself either.
But looks like no better way to resolve it….
So OK with the i8n thing sorted out - please post one hopefully last update
for the patch.
Will do it.
Thanks for your patience,
Thank you!
Qing
Richard.
thanks.
Qing.
Enable -Wuninitialized + -ftrivial-auto-var-init for address
taken variables.
With -ftrivial-auto-var-init, the address taken auto variable is replaced with
a
[Bug fortran/89069] ICE in select type with function returning class array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069 --- Comment #3 from Antony Lewis --- This bug is still valid as of gcc 11.2.1 20220114 15 | end module test | 1 internal compiler error: Segmentation fault 0x160a5b7 internal_error(char const*, ...) ???:0 0x764849 gfc_class_data_get(tree_node*) ???:0 0x7b0111 gfc_trans_block_construct(gfc_code*) ???:0 0x762224 gfc_generate_function_code(gfc_namespace*) ???:0 0x73c1d1 gfc_generate_module_code(gfc_namespace*) ???:0 0x6dd185 gfc_parse_file() ???:0
[Bug tree-optimization/104012] [12 regression] -Wformat-truncation warnings not taking previous length check into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012 --- Comment #6 from Martin Sebor --- To expand a bit on the fuzziness at level 1. The logic is documented under the -Wformat-overflow warning like so: Numeric arguments that are known to be bounded to a subrange of their type, or string arguments whose output is bounded either by their directive’s precision or by a finite set of string literals, are assumed to take on the value within the range that results in the most bytes on output.
[Bug target/100085] Bad code for union transfer from __float128 to vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Bill Schmidt --- This was fixed a while back in r12-1316 by Xiong Hu Luo.
[COMMITTED] test to verify -Wformat-overflow uses context-sensitive ranges
Converting the strlen/sprintf pass to Ranger has considerably improved the accuracy of -Wformat-overflow warnings: they can avoid triggering for safe input even at -O0 while at the same time detect provable overflow. The conversion didn't come with any tests so in r12-6591 I committed one that verifies both of these improvements. https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359299.html Martin
[arm] MVE: Relax addressing modes for full loads and stores
Hi Christophe, This patch relaxes the addressing modes for the mve full load and stores (by full loads and stores I mean non-widening or narrowing loads and stores resp). The code before was requiring a LO_REGNUM for these, where this is only a requirement if the load is widening or the store narrowing. So with this your patch should not be necessary. Regression tested on arm-none-eabi-gcc. Can you please confirm this fixes the issue you were seeing too? gcc/ChangeLog: * config/arm/arm.h (MVE_STN_LDW_MODE): New MACRO. * config/arm/arm.c (mve_vector_mem_operand): Relax constraint on base register for non widening loads or narrowing stores. Kind Regards, Andre Vieiradiff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h index dacce2b7f086eeffb0cd36b26f102f77130a92fa..f39786d0f9e19e81841a45f6d7e92e408272fe23 100644 --- a/gcc/config/arm/arm.h +++ b/gcc/config/arm/arm.h @@ -1099,6 +1099,10 @@ extern const int arm_arch_cde_coproc_bits[]; ((MODE) == V2DImode ||(MODE) == V4SImode || (MODE) == V8HImode \ || (MODE) == V16QImode) +/* Modes used in MVE's narrowing stores or widening loads. */ +#define MVE_STN_LDW_MODE(MODE) \ + ((MODE) == V4QImode || (MODE) == V8QImode || (MODE) == V4HImode) + #define VALID_MVE_SF_MODE(MODE) \ ((MODE) == V8HFmode || (MODE) == V4SFmode || (MODE) == V2DFmode) diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index bb75921f32df6185711d5304c044ce67a2d5671e..f5e09cb00b5478546d29c05cc885aeaa89501d39 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -13438,27 +13438,28 @@ mve_vector_mem_operand (machine_mode mode, rtx op, bool strict) case E_V16QImode: case E_V8QImode: case E_V4QImode: - if (abs (val) <= 127) - return (reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM) - || reg_no >= FIRST_PSEUDO_REGISTER; - return FALSE; + if (abs (val) > 127) + return FALSE; + break; case E_V8HImode: case E_V8HFmode: case E_V4HImode: case E_V4HFmode: - if (val % 2 == 0 && abs (val) <= 254) - return reg_no <= LAST_LO_REGNUM - || reg_no >= FIRST_PSEUDO_REGISTER; - return FALSE; + if (val % 2 != 0 || abs (val) > 254) + return FALSE; + break; case E_V4SImode: case E_V4SFmode: - if (val % 4 == 0 && abs (val) <= 508) - return (reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM) - || reg_no >= FIRST_PSEUDO_REGISTER; - return FALSE; + if (val % 4 != 0 || abs (val) > 508) + return FALSE; + break; default: return FALSE; } + return reg_no >= FIRST_PSEUDO_REGISTER + || (MVE_STN_LDW_MODE (mode) + ? reg_no <= LAST_LO_REGNUM + : (reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)); } return FALSE; }
Re: GSoC: Working on the static analyzer
HI David, I've been tinkering with the static analyzer for the last few days. I find the project of adding SARIF output to the analyzer intresting. I'm writing this to let you know that I'm trying to learn the codebase. Thank you. On Tue, Jan 11, 2022, 7:09 PM David Malcolm wrote: > On Tue, 2022-01-11 at 11:03 +0530, Mir Immad via Gcc wrote: > > Hi everyone, > > Hi, and welcome. > > > I intend to work on the static analyzer. Are these documents enough to > > get > > started: https://gcc.gnu.org/onlinedocs/gccint and > > > https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html#Analyzer-Internals > > Yes. > > There are also some high-level notes here: > https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer > > Also, given that the analyzer is part of GCC, the more general > introductions to hacking on GCC will be useful. > > I recommend creating a trivial C source file with a bug in it (e.g. a > 3-line function with a use-after-free), and stepping through the > analyzer to get a sense of how it works. > > Hope this is helpful; don't hesitate to ask questions. > Dave > >
Re: [Patch][V4][Patch 2/2]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables.
> On Jan 14, 2022, at 6:45 AM, Richard Biener
> wrote:
>
> On Thu, Jan 13, 2022 at 2:45 AM Qing Zhao wrote:
>>
>> Hi, Richard,
>>
>> This is the updated version for the second patch, which is mainly the change
>> for "Enable -Wuninitialized + -ftrivial-auto-var-init for address taken
>> variables”.
>>
>> In this update, I mainly made the following change:
>>
>> 1. Delete “repl_var”, use the var_def_stmt, i.e, the call to .DEFERRED_INIT
>> to record the warning suppressed info.
>> 2. Add and change the comments in multiple places to make the change more
>> readable.
>>
>> Now, for the deleted variable, we will get the necessary info to report
>> warning from the call to .DEFERRED_INIT.
>>
>>A. the name string of DECL from the 3rd parameter of the call;
>>B. the location of the DECL from the location of the call;
>>C. the call can also be used to hold the information on whether the
>> warning
>> has been issued or not to suppress warning messages when needed;
>>
>> Please see the detailed description below for the problem and solution of
>> this patch.
>>
>> This patch has been bootstrapped and regressing tested on both X86 and
>> aarch64.
>>
>> Okay for GCC12?
>
> I think the change to split "%qD is used uninitialized" is bad for i8n
> though it seems
> like none of the strings passed to warn_uninit are currently marked
> for localization.
> I suppose there's lazy matching with the exact same strings passed to
> warning_at around like 641 but after your change those will no longer match
> up,
Silly question: What does the above “641” mean?
> at least for the "%qs ..." case constructed. I think a better way
> (for i8n) would be
> to pass down a flag whether it is "may" or "is" and have the full translatable
> strings literally passed to warning_at at the expense of some code
> duplication.
> Actually the extra flag is unnecessary, the OPT_W... we pass is already fully
> specifying that.
The only issue with the above change is: among the 4 calls to “warn_uninit”
as following:
if (use_stmt)
warn_uninit (OPT_Wuninitialized, def, SSA_NAME_VAR (def),
-"%qD is used uninitialized", use_stmt);
+"is used uninitialized", use_stmt);
}
}
@@ -932,10 +1015,10 @@ warn_uninitialized_vars (bool wmaybe_uninit)
tree use = USE_FROM_PTR (use_p);
if (wlims.always_executed)
warn_uninit (OPT_Wuninitialized, use, SSA_NAME_VAR (use),
-"%qD is used uninitialized", stmt);
+"is used uninitialized", stmt);
else if (wmaybe_uninit)
warn_uninit (OPT_Wmaybe_uninitialized, use, SSA_NAME_VAR (use),
-"%qD may be used uninitialized", stmt);
+"may be used uninitialized", stmt);
}
/* For limiting the alias walk below we count all
@@ -1182,7 +1265,7 @@ warn_uninitialized_phi (gphi *phi, vec *worklist,
warn_uninit (OPT_Wmaybe_uninitialized, uninit_op,
SSA_NAME_VAR (uninit_op),
- "%qD may be used uninitialized in this function",
+ "may be used uninitialized in this function",
uninit_use_stmt, loc);
All the strings passed map well with the OPT_W… except the last one, since the
last one has an additional string “in this function” at the end.
However, since the last call has the last argument “loc” been NULL, maybe we
can use this to distinguish.
>
> Instead of doing
>
> + if (gimple_call_internal_p (var_def_stmt, IFN_DEFERRED_INIT))
> + {
> + /* Ignore the call to .DEFERRED_INIT that define the original
> +var itself as the following case:
> + temp = .DEFERRED_INIT (4, 2, â~@~\alt_reloc");
> + alt_reloc = temp;
> +In order to avoid generating warning for the fake usage
> +at alt_reloc = temp.
> ...
>
> I thought of many options, none really very appealing so I guess we have to
> go with this for now.
I agree with you, this is really ugly, I am not very comfortable myself either.
But looks like no better way to resolve it….
>
> So OK with the i8n thing sorted out - please post one hopefully last update
> for the patch.
Will do it.
>
> Thanks for your patience,
Thank you!
Qing
> Richard.
>
>> thanks.
>>
>> Qing.
>>
>>
>> Enable -Wuninitialized + -ftrivial-auto-var-init for address
>> taken variables.
>>
>> With -ftrivial-auto-var-init, the address taken auto variable is replaced
>> with
>> a temporary variable during gimplification, and the original auto variable
>> might
>> be eliminated by compiler optimization completely. As a result, the current
>> uninitialized warning analysis cannot get enough information from the IR,
>> therefore the uninitialized warnings for address taken variable cannot be
>> issued based on the current implemenation of
Re: git hooks: too strict check
On Fri, Jan 14, 2022 at 11:14 AM Michael Matz via Gcc wrote: > > Hello, > > On Fri, 14 Jan 2022, Martin Liška wrote: > > > Hello. > > > > I'm working on a testsuite clean-up where some of the files are wrongly > > named. > > More precisely, so files have .cc extension and should use .C. However > > there's > > existing C test-case and it leads to: > > > > marxin@marxinbox:~/Programming/gcc/gcc/testsuite> find . -name test-asm.* > > ./jit.dg/test-asm.C > > ./jit.dg/test-asm.c > > You can't have that, the check is correct. There are filesystems (NTFS > for instance) that are case-preserving but case-insensitive, on those you > really can't have two files that differ only in casing. HFS for Macs behaves this way by default, too, for reference. > You need to find a different solution, either consistently use .cc instead > of .C, live with the inconsistency or rename the base name of these files. > > > Ciao, > Michael. > > > > > test-kunlun me/rename-testsuite-files > > Enumerating objects: 804, done. > > Counting objects: 100% (804/804), done. > > Delta compression using up to 16 threads > > Compressing objects: 100% (242/242), done. > > Writing objects: 100% (564/564), 142.13 KiB | 7.48 MiB/s, done. > > Total 564 (delta 424), reused 417 (delta 295), pack-reused 0 > > remote: Resolving deltas: 100% (424/424), completed with 222 local objects. > > remote: *** The following filename collisions have been detected. > > remote: *** These collisions happen when the name of two or more files > > remote: *** differ in casing only (Eg: "hello.txt" and "Hello.txt"). > > remote: *** Please re-do your commit, chosing names that do not collide. > > remote: *** > > remote: *** Commit: 7297e1de9bed96821d2bcfd034bad604ce035afb > > remote: *** Subject: Rename tests in jit sub-folder. > > remote: *** > > remote: *** The matching files are: > > remote: *** > > remote: *** gcc/testsuite/jit.dg/test-quadratic.C > > remote: *** gcc/testsuite/jit.dg/test-quadratic.c > > remote: *** > > remote: *** gcc/testsuite/jit.dg/test-switch.C > > remote: *** gcc/testsuite/jit.dg/test-switch.c > > remote: *** > > remote: *** gcc/testsuite/jit.dg/test-asm.C > > remote: *** gcc/testsuite/jit.dg/test-asm.c > > remote: *** > > remote: *** gcc/testsuite/jit.dg/test-alignment.C > > remote: *** gcc/testsuite/jit.dg/test-alignment.c > > > > Can we please do something about it? > > > > Thanks, > > Martin > >
[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 Bug 85741 depends on bug 104012, which changed state. Bug 104012 Summary: [12 regression] -Wformat-truncation warnings not taking previous length check into account https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/104012] [12 regression] -Wformat-truncation warnings not taking previous length check into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012 Martin Sebor changed: What|Removed |Added Resolution|--- |INVALID Blocks||85741 Status|UNCONFIRMED |RESOLVED --- Comment #5 from Martin Sebor --- I can reproduce the warning now with the command line options provided in comment #4: -O0 and -Wformat-truncation=2 are needed to trigger it. The interaction of the warning with optimizations (or their absence) is documented in the manual: When the exact number of bytes written by a format directive cannot be determined at compile-time it is estimated based on heuristics that depend on the level argument and on optimization. While enabling optimization will in most cases improve the accuracy of the warning, it may also result in false positives. -Wformat-truncation=2 Level 2 warns also about calls to bounded functions whose return value is used and that might result in truncation given an argument of sufficient length or magnitude. Not enabling optimization and using -Wformat-truncation=2 increases the chance that the heuristic of assuming the argument with greatest magnitude (for %04d it would be INT_MIN) will be used. GCC still does some value and range propagation even at -O0 but it doesn't inline function calls (like those to std::string members) or do other optimizations that might otherwise help it track data flow more accurately. Regardless of optimization, the intent of level 2 is to guide the programmer to provide a buffer that's big enough for the largest possible output (i.e., you have to either prove to GCC that the truncation isn't possible or handle it). At level 1 it's more like the other way around (GCC has to prove that the call will result in truncation in order to warn, although there's some fuzziness here and some heuristics apply as well). In short, this is not a bug. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 [Bug 85741] [meta-bug] bogus/missing -Wformat-overflow
