[Bug ipa/94947] [8/9/10/11 Regression] -fipa-pta + pthread_once crash since r6-5684-g47e5754e17e9ac3b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94947 Martin Liška changed: What|Removed |Added Known to work||5.4.0 Status|UNCONFIRMED |NEW Known to fail||11.0, 6.4.0 CC||rguenth at gcc dot gnu.org Last reconfirmed||2020-05-05 Summary|-fipa-pta + pthread_once|[8/9/10/11 Regression] |crash |-fipa-pta + pthread_once ||crash since ||r6-5684-g47e5754e17e9ac3b Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r6-5684-g47e5754e17e9ac3b.
[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 --- Comment #14 from Martin Liška --- Created attachment 48448 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48448=edit Reduced test-case
[Bug c++/94946] [10/11 Regression] error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded since r10-7998-g5f1cd1da1a805c3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |rejects-valid
--- Comment #1 from Martin Liška ---
Reduced test-case:
$ cat qt.ii
class a {
template a(b());
template a(b(__attribute__((fastcall)) c)());
};
[Bug middle-end/4210] should not warning with dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 --- Comment #33 from Vincent Lefèvre --- (In reply to Niels Möller from comment #32) > 4. I also wonder what happens if, for some reason, a constant invalid shift > count is passed through all the way to code generation? Most architectures > would represent a constant shift count for a 32-bit value as 5-bit field in > the opcode, and then the invalid shift counts aren't representable at all. > Will gcc silently ignore higher bits, That's undefined behavior, so that GCC can do whatever it wants for the generated code. > or is it an internal compiler error, This would not be acceptable.
[Bug middle-end/93086] build_nonstandard_integer_type should take signop instead of int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93086 --- Comment #2 from Andrew Pinski --- I have a patch, in some places I am able to remove some extra varibles, in others I need to add one. There was an mix use of 0/1 and false/true even in the same file for the argument of build_nonstandard_integer_type. This new argument type makes it more explicit what is wanted there. I did not do signed_or_unsigned_type_for yet either; I will have one after I test my current patch; this part will require much more changes to the front-end as I am going to change the language hook too. Note there are a few more places where signop; especially in gimple to rtl expansion code.
[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 --- Comment #13 from Christoph --- I tried to help with reducing the test case, but could not achieve something substantial. Then I went back to our test cases and tried to pick the simples one I could find. I removed as much code from main() as I could. The resulting test case looks only slightly smaller (7 MiB instead of 8 MiB) but it should boil down to a smaller test case. Not sure which route is going to lead to faster results.
[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 --- Comment #12 from Christoph --- Created attachment 48447 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48447=edit output for injection test case
[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 --- Comment #11 from Christoph --- Created attachment 48446 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48446=edit New, smaller test case (called injection)
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #14 from Segher Boessenkool --- So, hrm, we could in principle attach a REG_EQ* note to any single_set instruction?
[Bug c++/94038] [8/9/10 Regression] Compiling with -Wall causes function template body to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038
Patrick Palka changed:
What|Removed |Added
Summary|Compiling with -Wall causes |[8/9/10 Regression]
|function template body to |Compiling with -Wall causes
|get needlessly instantiated |function template body to
||get needlessly instantiated
Known to work||5.5.0
Known to fail||10.0, 6.4.0, 7.4.0, 8.3.0,
||9.3.0
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Target Milestone|--- |10.0
Last reconfirmed||2020-05-04
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #5 from Patrick Palka ---
Fixed for GCC 11.
However, it looks like GCC 5.2-5.5 successfully compile the added testcase
g++.dg/warn/pr94038.C (with -O and -Wall), buh GCC 5.1, 6.1 and later do not,
so I am leaving this PR open and marking it as a 8/9/10 regression.
Here's the exact testcase that exhibits a regression relative to gcc 5.5:
$ cat testcase.C
template
constexpr int
foo()
{
static_assert(T(1) == 0, "");
return 0;
}
template
constexpr int
bar()
{
return foo();
}
constexpr int
baz(int a)
{
return a;
}
static_assert(decltype(baz(bar())){} == 0, "");
$ g++-10 -std=c++11 -O -Wall testcase.C
testcase.C: In instantiation of ‘constexpr int foo() [with T = int]’:
testcase.C:17:16: required from ‘constexpr int bar() [with T = int]’
testcase.C:26:36: required from here
testcase.C:9:22: error: static assertion failed
9 | static_assert(T(1) == 0, "");
| ~^~~~
[Bug c++/94938] [10/11 Regression] internal compiler error: in value_dependent_expression_p, at cp/pt.c:26522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Marek Polacek --- I have a (different) patch.
[Bug c++/94038] Compiling with -Wall causes function template body to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a700b4a9f18fd6213de51f4259ee9a8ce7eefdbb commit r11-56-ga700b4a9f18fd6213de51f4259ee9a8ce7eefdbb Author: Patrick Palka Date: Mon May 4 18:30:32 2020 -0400 c++: Avoid unnecessary copying in cp_fold [PR94038] When folding a CALL_EXPR, we can avoid copying it until folding changes one of its arguments. And when folding a TREE_VEC, we can avoid using an intermediate releasing_vec by copying the TREE_VEC as soon as folding changes one of its arguments, like we do in the CALL_EXPR case. Incidentally, the CALL_EXPR change also fixes the testcase in PR94038. The reason is that the call to maybe_constant_value from cp_fold on the call 'bar()' now reuses the result of the earlier call to maybe_constant_value from fold_for_warn, via the cv_cache. This earlier call passes uid_sensitive=true, whereas the call from cp_fold passes uid_sensitive=false, and so by reusing the cached result of the earlier call we now avoid instantiating bar at all. gcc/cp/ChangeLog: PR c++/94038 * cp-gimplify.c (cp_fold) : Move some variable declarations closer to their uses. Copy the CALL_EXPR only when one of its arguments has changed. : Instead of first collecting the folded arguments into a releasing_vec, just make a copy of the TREE_VEC as soon as folding changes one of its arguments. gcc/testsuite/ChangeLog: PR c++/94038 * g++.dg/warn/pr94038.C: New test.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #13 from Eric Botcazou --- Since Richard kindly invited me to the party, I feel entitled to voice my personal opinion :-) which is apparently aligned with Richard's. I think that we should allow REG_EQUAL notes for insns with exactly one SET of a register, the contents of the note being the value present in this register after the execution of the insn at run time, and disregarding side effects. IMO that's the spirit of the current implementation and thus also probably the most straightforward way out.
[Bug ipa/94947] New: -fipa-pta + pthread_once crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94947
Bug ID: 94947
Summary: -fipa-pta + pthread_once crash
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: corydoras at ridiculousfish dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
fish-shell is seeing a SIGSEGV under std::call_once with -fipa-pta, which I
have reduced to the following:
1. Store a noop void->void function pointer into a local variable
2. Point a global variable at the local
3. Use pthread_once to invoke a trampoline, which in turn dereferences the
global to call the noop
This crashes with `-O1 -fipa-pta`, and the crash disappears if `fipa-pta` is
deleted.
Original test case (requires musl):
https://gist.github.com/ridiculousfish/0a24a98e7634b78e77a0351501576ee8
Reduced test case (also available at
https://gist.github.com/ridiculousfish/3cff64438154a20765e527be11f7cc76):
```
extern "C" void pthread_once(int *, void());
namespace std
{
extern __thread void (*__once_call)();
extern "C" void __once_proxy();
}; // namespace std
static void noop() {}
using voidfunc = void (*)();
static voidfunc *vp;
static void call_vp()
{
(*vp)();
}
int main()
{
using namespace std;
voidfunc vf = noop;
vp =
__once_call = call_vp;
int once{0};
pthread_once(, __once_proxy);
return 0;
}
```
To reproduce, on Linux:
g++ -O1 -fipa-pta -std=c++11 -lpthread output.cpp
./a.out
and it should SIGSEGV under `call_vp`
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-pkgversion='Arch Linux 9.3.0-1'
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.3.0 (Arch Linux 9.3.0-1)
(Originally reported as https://github.com/fish-shell/fish-shell/issues/6962)
[Bug bootstrap/94918] [8/9/10/11 regression] Ada bootstrap errors on Cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918 --- Comment #7 from Eric Botcazou --- The Ada bits have been installed, but approval from a global maintainer is needed for the libgcc bits.
[Bug libstdc++/94906] memory corruption in std::pmr::monotonic_buffer_resource
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94906 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bb27781b64162e1769df15e0c97e8d2145d2d10d commit r11-53-gbb27781b64162e1769df15e0c97e8d2145d2d10d Author: Jonathan Wakely Date: Mon May 4 21:13:28 2020 +0100 libstdc++: Fix incorrect size calculation in PMR resource (PR 94906) Calculating the size of a chunk being returned to the upstream allocator was done with a 32-bit type, so it wrapped if the chunk was 4GB or larger. I don't know how to test this without allocating 4GB, so there's no test in the testsuite. It has been tested manually with allocations sizes and alignments exceeding 4GB. PR libstdc++/94906 * src/c++17/memory_resource.cc (monotonic_buffer_resource::_Chunk::release): Use size_t for shift operands.
[Bug bootstrap/94918] [8/9/10/11 regression] Ada bootstrap errors on Cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:4b0a1274faa64cbbe3c3b5db1129b3d2b3b530bb commit r8-10236-g4b0a1274faa64cbbe3c3b5db1129b3d2b3b530bb Author: Eric Botcazou Date: Mon May 4 23:32:39 2020 +0200 Fix Ada bootstrap on Cygwin64 This fixes a compilation error preventing bootstrap with Ada on x86_64-pc-cygwin. 2020-05-04 Mikael Pettersson PR bootstrap/94918 * mingw32.h: Prevent windows.h from including emmintrin.h on Cygw64.
[Bug bootstrap/94918] [8/9/10/11 regression] Ada bootstrap errors on Cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:a34b818215174f6cbe46e2e2bfae874fde7aec72 commit r9-8566-ga34b818215174f6cbe46e2e2bfae874fde7aec72 Author: Eric Botcazou Date: Mon May 4 23:32:39 2020 +0200 Fix Ada bootstrap on Cygwin64 This fixes a compilation error preventing bootstrap with Ada on x86_64-pc-cygwin. 2020-05-04 Mikael Pettersson PR bootstrap/94918 * mingw32.h: Prevent windows.h from including emmintrin.h on Cygw64.
[Bug bootstrap/94918] [8/9/10/11 regression] Ada bootstrap errors on Cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918 --- Comment #3 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:cc7e4de998cd2a31eb7c834fd427e7f16a99d60a commit r11-52-gcc7e4de998cd2a31eb7c834fd427e7f16a99d60a Author: Eric Botcazou Date: Mon May 4 23:32:39 2020 +0200 Fix Ada bootstrap on Cygwin64 This fixes two compilation errors preventing bootstrap with Ada on x86_64-pc-cygwin. 2020-05-04 Mikael Pettersson PR bootstrap/94918 * mingw32.h: Prevent windows.h from including emmintrin.h on Cygw64. * s-oscons-tmplt.c (Serial_Port_Descriptor): Use System.Win32.HANDLE also on Cygwin.
[Bug bootstrap/94918] [8/9/10/11 regression] Ada bootstrap errors on Cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:1c615f4a935b805e3c030d8261452a17efb138ac commit r10-8091-g1c615f4a935b805e3c030d8261452a17efb138ac Author: Eric Botcazou Date: Mon May 4 23:32:39 2020 +0200 Fix Ada bootstrap on Cygwin64 This fixes two compilation errors preventing bootstrap with Ada on x86_64-pc-cygwin. 2020-05-04 Mikael Pettersson PR bootstrap/94918 * mingw32.h: Prevent windows.h from including emmintrin.h on Cygw64. * s-oscons-tmplt.c (Serial_Port_Descriptor): Use System.Win32.HANDLE also on Cygwin.
[Bug bootstrap/94918] [8/9/10/11 regression] Ada bootstrap errors on Cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2020-05-04 Summary|Ada bootstrap errors on |[8/9/10/11 regression] Ada |Cygwin64|bootstrap errors on ||Cygwin64 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Eric Botcazou --- The g-sercom.adb failure is indeed a small oversight.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #12 from rsandifo at gcc dot gnu.org --- Just noticed that Eric wasn't on cc: (although he might have preferred that it stay that way).
[Bug middle-end/4210] should not warning with dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #32 from Niels Möller ---
I've checked out the gcc sources, to see if I can understand how to move the
warning around. The example input I'm looking at now is
unsigned
shift_dead (unsigned x)
{
if (0)
return x >> 32;
else
return x >> 1;
}
unsigned
shift_invalid (unsigned x)
{
return x >> 32;
}
where I'd like gcc -Wall to warn for the second function, but not from the
first (currently, it warns for both). The warning is emitted from
build_binary_op, in gcc/c/c-typeck.c, close to line 11880. Deleting it there
silences the warning for *both* functions above.
I have a few questions. Keep in mind that I only have a very vague
understanding of the different phases in gcc, so any guidance is appreciated.
1. There's similar code in c_fully_fold_internal, in gcc/c/c-fold.c, close to
line 400. But that code does *not* emit any warning for the example above,
which surprised me a bit. Maybe that's only for the case that both operands to
the shift operator are constants?
2. More importantly, if the warning is deleted from build_binary_op, we need to
add a check for this case, and an appropriate warning, somewhere later in the
compilation process. It has to be done after dead code is identified, i.e., in
a phase processing only non-dead code. And preferably as early as possibly,
when we're still working close to the parse-tree representation. Is there such
a place? Some other functions traversing the tree are c_gimplify_expr
(gcc/c-family/c-gimplify.c) and verify_tree (gcc/c-family/c-common.c), are any
of those called after elimination of dead code?
3. Alternatively, if there's no place after dead code elimination where the
parse tree is still easily available, a different alternative could be to leave
the check for invalid shift counts in c-typeck.c, but instead of emitting a
warning, construct a special tree object representing an expression with
invalid/undefined behavior, and any meta data needed to emit a warning or error
to describe it? Then emission of the warning could be postponed to later, say,
close to the conversion to SSA form?
4. I also wonder what happens if, for some reason, a constant invalid shift
count is passed through all the way to code generation? Most architectures
would represent a constant shift count for a 32-bit value as 5-bit field in the
opcode, and then the invalid shift counts aren't representable at all. Will gcc
silently ignore higher bits, or is it an internal compiler error, or would it
make sense to produce a friendly warning at this late stage of the compilation?
[Bug middle-end/94941] Expansion of some internal fns can drop the lhs on the floor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94941 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from rsandifo at gcc dot gnu.org --- Fixed in master and on the GCC 10 branch.
[Bug middle-end/94941] Expansion of some internal fns can drop the lhs on the floor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94941 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:688c8da3eb4cc7482f9844e0e87c11f5003bfbef commit r10-8090-g688c8da3eb4cc7482f9844e0e87c11f5003bfbef Author: Richard Sandiford Date: Mon May 4 21:22:16 2020 +0100 internal-fn: Avoid dropping the lhs of some calls [PR94941] create_output_operand coerces an output operand to the insn's predicates, using a suggested rtx location if convenient. But if that rtx location is actually required rather than optional, the builder of the insn has to emit a move afterwards. (We could instead add a new interface that does this automatically, but that's future work.) This PR shows that we were failing to emit the move for some of the vector load internal functions. I think there are other routines in internal-fn.c that potentially have the same problem, but this patch is supposed to be a conservative subset suitable for backporting to GCC 10. 2020-05-04 Richard Sandiford gcc/ PR middle-end/94941 * internal-fn.c (expand_load_lanes_optab_fn): Emit a move if the chosen lhs is different from the gcall lhs. (expand_mask_load_optab_fn): Likewise. (expand_gather_load_optab_fn): Likewise. gcc/testsuite/ PR middle-end/94941 * gcc.target/aarch64/sve/acle/general/unoptimized_1.c: New test.
[Bug middle-end/94941] Expansion of some internal fns can drop the lhs on the floor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94941 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:3af3bec2e4d344bd54a134d8b2263f44d788c3d8 commit r11-50-g3af3bec2e4d344bd54a134d8b2263f44d788c3d8 Author: Richard Sandiford Date: Mon May 4 21:21:16 2020 +0100 internal-fn: Avoid dropping the lhs of some calls [PR94941] create_output_operand coerces an output operand to the insn's predicates, using a suggested rtx location if convenient. But if that rtx location is actually required rather than optional, the builder of the insn has to emit a move afterwards. (We could instead add a new interface that does this automatically, but that's future work.) This PR shows that we were failing to emit the move for some of the vector load internal functions. I think there are other routines in internal-fn.c that potentially have the same problem, but this patch is supposed to be a conservative subset suitable for backporting to GCC 10. 2020-05-04 Richard Sandiford gcc/ PR middle-end/94941 * internal-fn.c (expand_load_lanes_optab_fn): Emit a move if the chosen lhs is different from the gcall lhs. (expand_mask_load_optab_fn): Likewise. (expand_gather_load_optab_fn): Likewise. gcc/testsuite/ PR middle-end/94941 * gcc.target/aarch64/sve/acle/general/unoptimized_1.c: New test.
[Bug fortran/93366] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93366 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- Patch posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545091.html
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #11 from rsandifo at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #9) > "clobber" is a red herring; it is impossible to make a REG_EQ* note for > a clobber, a clobber does not set a new value (that is the whole point > of a clobber). It's not possible to attach a REG_EQ* note to an auto-inc-dec either though (that was my point). So a clobber doesn't seem any less of a red herring than the auto-inc-dec itself. Both set registers in the sense of changing them, and neither can be described by a REG_EQ* note. > I think we could allow auto-modify, sure, just as long as it stays clear > what lhs the REG_EQ* note is talking about; and, as you say, everything > needs to be audited for it :-/ Yeah. But to be clear: I don't think this is more obviously a change from the status quo than going in the other direction would be. The point is that the status quo is ambiguous: the documentation can be read either way, and the implementation isn't consistent (hence the bug). So it's a question of how we resolve the ambiguity. If we want passes to be able to assume without checking that insns with REG_EQ* notes don't also include auto inc-dec, we'll need to audit places that create the notes, or that update insns with existing notes. I think it comes down to what the REG_EQ* notes are supposed to achieve (conceptually, ignoring documentation and the current implementation for now). The "weak" guarantee is that the SET_DEST has the specified value after the instruction. The "strong" guarantee extends the weak guarantee by saying that the SET_SRC of the definition can be replaced by the REG_EQ* note without changing behaviour. Having auto-inc-dec in the SET_SRC of the definition is OK for the weak guarantee but not the strong guarantee. But the same would be true of any SET_SRC with side effects. So to frame the question in a different way: let's assume there's a target-specific intrinsic that has side effects that can be described using unspec_volatile, and that the intrinsic also sets a register. Normally this would be described as: (set (reg X) (unspec_volatile ...)) But if, in a particular context, the target could predict what the value of X was, could it attach a REG_EQ* note to say that? It would then be valid to simplify later uses of X, even though the definition of X can't change. IMO this is easier to answer for REG_EQUIV. That mostly exists to allow the RA to rematerialise a value instead of reloading it. So it's all about replacing the uses of the register rather than about replacing the definition. (I'm not saying that the RA would handle a REG_EQUIV note on the above unspec_volatile correctly -- haven't checked either way -- but in principle it could.) The weak guarantee makes life harder for consumers of the notes that want the strong guarantee, since they then have to check for side effects themselves. The weak guarantee is easy for producers of the notes and for consumers that only care about users of the register. The strong guarantee makes life harder for producers of the notes, or for optimisations that modify insns with existing notes. The strong guarantee is easy for consumers of the notes because it's more conservative. The weak guarantee potentially allows more optimisation than the strong guarantee. I don't think there's much in it. But I guess I personally prefer the weak guarantee for the "more optimisation" reason. There's also a very tenuous analogy with REG_RETURNED, which is explicitly for saying what the return value is, rather than saying how the definition can be rewritten. But whichever we go for, I think it should be a decision about side effects vs. no side effects, with auto inc-dec being just one of several potential side effects. I don't see any reason why the auto-inc-dec case would be different from the unspec_volatile case.
[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #10 from Marek Polacek --- Mine. A reduced test would be very much appreciated, thanks Martin.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #10 from Segher Boessenkool --- Oh, and ideally, we would replace the whole REG_EQ* stuff with a more powerful interface that is to-the-side, not embedded in the instruction stream. For known exact values, nonzero_bits, known ranges, the works.
[Bug c++/94946] [10/11 Regression] error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded since r10-7998-g5f1cd1da1a805c3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946 Martin Liška changed: What|Removed |Added Known to work||9.3.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Last reconfirmed||2020-05-04 Status|UNCONFIRMED |NEW Known to fail||10.0, 11.0
[Bug c++/94946] New: [10/11 Regression] error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded since r10-7998-g5f1cd1da1a805c3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946 Bug ID: 94946 Summary: [10/11 Regression] error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded since r10-7998-g5f1cd1da1a805c3d Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: needs-reduction Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jason at gcc dot gnu.org Target Milestone: --- Created attachment 48445 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48445=edit Unreduced test-case It's a recent regression on i586 target seen on libqt5-qtwebkit package: $ g++ qt.ii -c -m32 -fmax-errors=1 ^C marxin@marxinbox:~/BIG/osc/openSUSE:Factory:Staging:N/libqt5-qtwebkit> export PATH=/home/marxin/bin/gcc/bin/:/home/marxin/bin/cvise/usr/local/bin:$PATH && export LD_LIBRARY_PATH=/home/marxin/bin/gcc/lib64/:$LD_LIBRARY_PATH marxin@marxinbox:~/BIG/osc/openSUSE:Factory:Staging:N/libqt5-qtwebkit> g++ qt.ii -c -m32 -fmax-errors=1 In file included from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/jit/JITStubRoutine.h:32, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/heap/JITStubRoutineSet.h:29, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/heap/Heap.h:33, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/heap/DeferGC.h:29, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/runtime/ConcurrentJITLock.h:29, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/bytecode/ArrayProfile.h:29, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28: /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/assembler/MacroAssemblerCodeRef.h:184:5: error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded with ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ In file included from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/jit/JITStubRoutine.h:32, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/heap/JITStubRoutineSet.h:29, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/heap/Heap.h:33, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/heap/DeferGC.h:29, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/runtime/ConcurrentJITLock.h:29, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/bytecode/ArrayProfile.h:29, from /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28: /home/abuild/rpmbuild/BUILD/qtwebkit-5.212.0-alpha3/Source/JavaScriptCore/assembler/MacroAssemblerCodeRef.h:94:5: note: previous declaration ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ compilation terminated due to -fmax-errors=1. I'm reducing that right now.
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #14 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #13) > But, in general (non-interrupt) code, what is supposed to happen if you > compile for a d32 VFP and run on d16 one ? (and the code uses the extra > registers) Well obviously that won't work. But if you build the interrupt routine with a d16 system and then call a function from it that requires d32 then that should still work if running on a d32 CPU. I think we can probably make that work, but it's probably a bit of a dance to get it all right. Hence the suggestion that this be done in a library function.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #9 from Segher Boessenkool --- "clobber" is a red herring; it is impossible to make a REG_EQ* note for a clobber, a clobber does not set a new value (that is the whole point of a clobber). I think we could allow auto-modify, sure, just as long as it stays clear what lhs the REG_EQ* note is talking about; and, as you say, everything needs to be audited for it :-/
[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 Martin Liška changed: What|Removed |Added Summary|ICE with if constexpr (in |[10/11 Regression] ICE with |cp_get_fndecl_from_callee, |if constexpr (in |at cp/cvt.c:1000) |cp_get_fndecl_from_callee, ||at cp/cvt.c:1000) since ||r10-2835-g14da3939da3adcef Known to fail||10.0, 11.0 Keywords||ice-on-valid-code CC||mpolacek at gcc dot gnu.org Known to work||9.3.0 --- Comment #8 from Martin Liška --- Reduced command line: $ g++ -c -c -std=c++17 -Wall -fsyntax-only -c pr94937.ii
[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 --- Comment #9 from Martin Liška --- Created attachment 48444 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48444=edit Semi-reduced test-case I'll carry on with the reduction, but it goes down slowly.
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #13 from Christophe Lyon --- > > Why do we need a library function for that? It would have to be special with > > the stack: push FP registers, but do not restore SP, so that the dual > > restore function can pop them and restore SP. > > Because it's a lot of code to work out how many FP registers there are. You > can't assume that the FPU used to compile the interrupt handler is the same > as that being used at run time. Ha, I had missed that point in your comment #5. I'll re-iterate on my WIP patch. But, in general (non-interrupt) code, what is supposed to happen if you compile for a d32 VFP and run on d16 one ? (and the code uses the extra registers)
[Bug middle-end/94940] [10/11 Regression] spurious -Warray-bounds for a zero length array member of union since r10-4300-g49fb45c81f4ac068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94940 --- Comment #5 from Martin Liška --- Thank you for the analysis, I'm gonna report that to qemu guys.
[Bug sanitizer/94849] Improper parameter validation in libsanitizer for fopen64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849 Martin Liška changed: What|Removed |Added Resolution|--- |MOVED Status|ASSIGNED|RESOLVED --- Comment #9 from Martin Liška --- Let's close it as moved.
[Bug c++/94929] [8 Regression] GCC 8 chokes on std::max in alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929 --- Comment #6 from Marek Polacek --- (In reply to David Seifert from comment #5) > (In reply to Marek Polacek from comment #3) > > I'm going to backport the fix to 8 if it passes the usual testing. > > Hi Marek, > could you also test the inlined code. Defining some const and then using it > alignas worked previously, the problem comes from doing all of it in > alignas(). Both the original testcase in this PR and the test in Comment 2 now compile even with GCC 8.
[Bug tree-optimization/94800] Failure to optimize yet another popcount idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94800 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 48443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48443=edit gcc11-pr94800.patch Untested fix.
[Bug c++/94929] [8 Regression] GCC 8 chokes on std::max in alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929 --- Comment #5 from David Seifert --- (In reply to Marek Polacek from comment #3) > I'm going to backport the fix to 8 if it passes the usual testing. Hi Marek, could you also test the inlined code. Defining some const and then using it alignas worked previously, the problem comes from doing all of it in alignas().
[Bug c++/94929] [8 Regression] GCC 8 chokes on std::max in alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Done in r8-10235-gf6965321b1c00bfb2b9c8407df56bcf38f096088.
[Bug c++/90736] [9 Regression] Bogus error with alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90736 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:f6965321b1c00bfb2b9c8407df56bcf38f096088 commit r8-10235-gf6965321b1c00bfb2b9c8407df56bcf38f096088 Author: Marek Polacek Date: Mon May 4 13:25:42 2020 -0400 c++: Bogus error with alignof [PR90736] PR c++/90736 - bogus error with alignof. * constexpr.c (adjust_temp_type): Use cv_unqualified type.
[Bug libstdc++/94747] Confusing code in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- Fixed e6b31fc7172
[Bug c++/94938] [10/11 Regression] internal compiler error: in value_dependent_expression_p, at cp/pt.c:26522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938 --- Comment #2 from Marek Polacek --- value_dependent_expression_p (called via the new uses_template_parms call) doesn't expect a non-constant expression. So one possible fix would be: --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -10624,7 +10624,8 @@ uses_template_parms (tree t) else if (t == error_mark_node) dependent_p = false; else -dependent_p = value_dependent_expression_p (t); +dependent_p = (potential_constant_expression (t) + && value_dependent_expression_p (t)); processing_template_decl = saved_processing_template_decl;
[Bug c++/94827] crash on requires clause in tparam list since r10-4424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Nathan Sidwell --- Cleanup pushed f1621d18f55
[Bug target/94795] Failure to use fast sbb method on x86 for spreading any set bit to all bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94795 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|ASSIGNED|RESOLVED Component|rtl-optimization|target --- Comment #6 from Uroš Bizjak --- Implemented for gcc-11.
[Bug rtl-optimization/94795] Failure to use fast sbb method on x86 for spreading any set bit to all bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94795 --- Comment #5 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:9decd08b7b153a593a0b61e4f5373cb9574a1973 commit r11-45-g9decd08b7b153a593a0b61e4f5373cb9574a1973 Author: Uros Bizjak Date: Mon May 4 18:53:30 2020 +0200 i386: Use SBB more [PR94650] When returning 0 or -1, "SBB reg,reg" instruction that borrows carry flag can be used. Carry flag can be generated by converting compare with zero to a LTU compare with one, so e.g. return -(x == 0) generates: cmpq$1, %rdi sbbq%rax, %rax instead of: xorl%eax, %eax testq %rdi, %rdi sete%al negq%rax A similar conversion can be used for return -(x != 0) where NEG insn can be used instead of compare. According to x86 ISA, NEG insn sets carry flag when the source operand is != 0, resulting in: negq%rdi sbbq%rax, %rax The conversion avoids partial register stall with SETcc instructions. PR target/94795 * config/i386/i386.md (*neg_ccc): New insn pattern. (EQ compare->LTU compare splitter): New splitter. (NE compare->NEG splitter): Ditto. testsuite/ChangeLog: PR target/94795 * gcc.target/i386/pr94795-1.c: New test. * gcc.target/i386/pr94795-2.c: New test.
[Bug rtl-optimization/94945] New: Missed optimization: Carry chain not recognized in manually unrolled loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94945
Bug ID: 94945
Summary: Missed optimization: Carry chain not recognized in
manually unrolled loop
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: madhur4127 at gmail dot com
Target Milestone: ---
Context: Big integer addition using ADC (_addcarry_u64).
See Godbolt link: https://godbolt.org/z/rMxe6W
Example:
Suppose the case of big integer addition:
// pa, pb: pointer to big integer A, B
// n: size of big integer A, B
// pr: pointer to result
void add(const uint64_t * __restrict__ pa, const uint64_t * __restrict__ pb,
uint64_t * __restrict__ pr, unsigned n) {
unsigned char carry = 0;
unsigned i;
for(i = 0; i
[Bug fortran/94931] request: print include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931 --- Comment #7 from Steve Kargl --- On Mon, May 04, 2020 at 08:23:17AM +, ryofurue at gmail dot com wrote: > > But, then the question is, why don't you need the -L option? as in > > gfortran -I/usr/include mysourcefile.f -L/usr/lib -lnetcdff -netcdf > > > Why is this asymmetry? It seems that there are "standard" places to place > libraries but not include files . . . I think you're seeing the effects of shared libraries. The loader has library information: % ldconfig -r | grep netcdf 453:-lnetcdf.15 => /usr/local/lib/libnetcdf.so.15 My advice is to always have the correct -L options.
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #12 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #11) > (In reply to Richard Earnshaw from comment #10) > > (In reply to Christophe Lyon from comment #9) > > > > My initial thoughts are along the lines of... > > > > Only try to save FP registers that this function directly clobbers. > > > What's the point of saving these if a callee clobbers other registers? > > > > > > > They need to be done early enough to ensure that any code in *this* function > > does not clobber them. Any additional registers would have to be saved by a > > library call that does that. > > > Why do we need a library function for that? It would have to be special with > the stack: push FP registers, but do not restore SP, so that the dual > restore function can pop them and restore SP. Because it's a lot of code to work out how many FP registers there are. You can't assume that the FPU used to compile the interrupt handler is the same as that being used at run time.
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #11 from Christophe Lyon --- (In reply to Richard Earnshaw from comment #10) > (In reply to Christophe Lyon from comment #9) > > > My initial thoughts are along the lines of... > > > Only try to save FP registers that this function directly clobbers. > > What's the point of saving these if a callee clobbers other registers? > > > > They need to be done early enough to ensure that any code in *this* function > does not clobber them. Any additional registers would have to be saved by a > library call that does that. > Why do we need a library function for that? It would have to be special with the stack: push FP registers, but do not restore SP, so that the dual restore function can pop them and restore SP.
[Bug tree-optimization/92177] [10/11 regression] gcc.dg/vect/bb-slp-22.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177
Richard Biener changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #7 from Richard Biener ---
The SLP reorgs made making this testcase target agnostic really really hard.
It was supposed to test multiplication vectorization but now tests nothing. I
don't see how to reliably test this unless we scan for details in the
vectorizer
dumps that are prone to change. Currently we have for example
on x86_64:
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
SLPing BB part
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
-->vectorizing SLP node starting from: _5 = x_48(D) + 1;
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vect_is_simple_use: operand x_48(D), type of def: external
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vect_is_simple_use: operand 1, type of def: constant
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
transform binary/unary operation.
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
created new init_stmt: vect_cst__63 = _42;
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
created new init_stmt: vect_cst__12 = { 1, 1, 1, 1 };
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
add new stmt: vect__5.19_13 = vect_cst__63 + vect_cst__12;
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
-->vectorizing SLP node starting from: _6 = _5 * a0_44;
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vect_is_simple_use: operand x_48(D) + 1, type of def: internal
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vect_is_simple_use: vectype vector(4) unsigned int
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vect_is_simple_use: operand _1 + 23, type of def: external
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
transform binary/unary operation.
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
created new init_stmt: vect_cst__71 = _70;
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
add new stmt: vect__6.20_72 = vect__5.19_13 * vect_cst__71;
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
-->vectorizing SLP node starting from: out[0] = _6;
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vect_is_simple_use: operand _5 * a0_44, type of def: internal
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vect_is_simple_use: vectype vector(4) unsigned int
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vect_is_simple_use: operand _7 * a1_45, type of def: internal
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vect_is_simple_use: operand _5 * a2_46, type of def: internal
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vect_is_simple_use: operand _7 * a3_47, type of def: internal
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
transform store. ncopies = 1
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
create vector_type-pointer variable to type: vector(4) unsigned int
vectorizing a pointer ref: out[0]
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
created [0]
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
add new stmt: MEM [(unsigned int *)] =
vect__6.20_72;
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14: note:
vectorizing stmts using SLP.
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/bb-slp-22.c:35:14:
optimized: basic block part vectorized using 16 byte vectors
we could match 'vectorizing SLP node starting from: _6 = _5 * a0_44;
which means we are actually vectorizing a multiplication. Like with
the following. Rainer - can you test this?
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-22.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-22.c
index 6dc2375f5d1..f25a225666e 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-22.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-22.c
@@ -63,6 +63,6 @@ int main (void)
return 0;
}
-/* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp2" {
target { ! {vect_int_mult } } } } } */
-/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" {
target vect_int_mult } } } */
+/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" } } */
+/* { dg-final { scan-tree-dump "vectorizing SLP node starting from: _\[0-9\]+
= _\[0-9\]+ \\\* a0" "slp2" { target vect_int_mult } } } */
[Bug tree-optimization/94800] Failure to optimize yet another popcount idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94800
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-05-04
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
Rather than adding yet another popcount pattern, I wonder if we shouldn't just
canonicalize the x + (x << cst) to x * (1 + (1 << cst)) and
(x << cst1) + (x << cst2) to x * ((1 << cst1) + (1 << cst2)), and this PR would
fall naturally out of that. We already have code to emit the best
multiplication expansion and if it is not the fastest on some target, we should
tweak it anyway, because users could write the multiplication by constant.
Testcase to consider:
unsigned long long int
foo (unsigned long long int x)
{
unsigned long long int a = x + (x << 8);
unsigned long long int b = a + (a << 16);
unsigned long long int c = b + (b << 32);
return c;
}
unsigned long long int
bar (unsigned long long int x)
{
return x * 0x0101010101010101ULL;
}
unsigned int
baz (unsigned int x)
{
unsigned int a = x + (x << 8);
unsigned int b = a + (a << 16);
return b;
}
unsigned int
qux (unsigned int x)
{
return x * 0x01010101U;
}
unsigned long long int
quux (unsigned long long int x)
{
unsigned long long int a = (x << 2) + (x << 10);
unsigned long long int b = a + (a << 16);
unsigned long long int c = b + (b << 32);
return c;
}
unsigned long long int
corge (unsigned long long int x)
{
unsigned long long int a = x + (x << 4);
unsigned long long int b = a + (a << 8);
unsigned long long int c = b + (b << 16);
unsigned long long int d = c + (c << 32);
return d;
}
unsigned long long int
corge2 (unsigned long long int x)
{
unsigned long long int a = x * 0x11;
unsigned long long int b = a * 0x101;
unsigned long long int c = b * 0x10001;
unsigned long long int d = c * 0x10001ULL;
return d;
}
[Bug c++/94944] compile error accessing member function of dependent base class template in exception specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94944 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-05-04 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Keywords||rejects-valid Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed. Not a regression AFAICT.
[Bug middle-end/94940] [10/11 Regression] spurious -Warray-bounds for a zero length array member of union since r10-4300-g49fb45c81f4ac068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94940
Martin Sebor changed:
What|Removed |Added
Blocks||56456
Summary|[10/11 Regression] array|[10/11 Regression] spurious
|subscript i is outside |-Warray-bounds for a zero
|array bounds of ‘int[0]’|length array member of
|since |union since
|r10-4300-g49fb45c81f4ac068 |r10-4300-g49fb45c81f4ac068
Component|tree-optimization |middle-end
--- Comment #4 from Martin Sebor ---
When the array is a member of a declared object of a struct type (e in the
small test case in comment #0) it has no elements and attempting to access any
of them is invalid.
In the original translation unit the array is a member of an object of a union
type: union intelvf_msg. The object, msg, is defined in function
intelvf_mbox_set_mtu(), and the array is used to alias other members.
Presumably GCC supports this sort of aliasing as long as it's done through the
union type (as mentioned in -fstrict-aliasing), so the warning could be relaxed
not to trigger for them.
Here's a test case that more closely corresponds to the translation unit,
reproduces the warning, and shows that GCC doesn't make assumptions about the
two arrays being distinct:
$ cat pr94940_c4.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout
pr94940_c4.c
struct S { int a[2]; };
union U {
struct S s;
int a[0];
};
static void f (union U *p, int i, int j)
{
int t = p->s.a[j];
p->a[i] = 0;
if (t == p->s.a[j]) // not eleminated
__builtin_abort ();
}
void sink (void*);
void g (int i, int j)
{
union U u = { .s = { { 1, 2 } } };
f (, i, j);
sink ();
}
pr94940_c4.c: In function ‘g’:
pr94940_c4.c:11:7: warning: array subscript i is outside array bounds of
‘int[0]’ [-Warray-bounds]
11 | p->a[i] = 0;
| ^~~
pr94940_c4.c:5:7: note: while referencing ‘a’
5 | int a[0];
| ^
pr94940_c4.c:20:11: note: defined here ‘u’
20 | union U u = { .s = { { 1, 2 } } };
| ^
;; Function g (g, funcdef_no=1, decl_uid=1944, cgraph_uid=2, symbol_order=1)
g (int i, int j)
{
int t;
union U u;
int _10;
[local count: 1073741824]:
MEM[(union U *)] = 8589934593;
t_9 = u.s.a[j_5(D)];
u.a[i_4(D)] = 0;
_10 = u.s.a[j_5(D)];
if (t_9 == _10)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
sink ();
u ={v} {CLOBBER};
return;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c++/94944] compile error accessing member function of dependent base class template in exception specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94944
--- Comment #1 from eracpp ---
The example may be simplified further by removing the function parameters:
template
struct B {
void foo() {}
};
template
struct D : B {
void foo() noexcept(noexcept(B::foo())) {}
};
template struct D;
Which still yields the same error:
error: cannot call member function 'void B::foo() [with T = int]' without
object
8 | void foo() noexcept(noexcept(B::foo())) {}
|
And the `this->B::foo()` workaround still applies.
[Bug c++/94944] New: compile error accessing member function of dependent base class template in exception specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94944
Bug ID: 94944
Summary: compile error accessing member function of dependent
base class template in exception specification
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eracpp at eml dot cc
Target Milestone: ---
GCC fails to compile a qualified invocation of a member function of a dependent
base class template when used within an exception specification:
template
struct B {
void foo(T t) {}
};
template
struct D : B {
void foo(T t) noexcept(noexcept(B::foo(t))) {}
};
template struct D;
The error message is as follows:
error: cannot call member function 'void B::foo(T) [with T = int]' without
object
8 | void foo(T t) noexcept(noexcept(B::foo(t))) {}
|
Clang and MSVC accept the code as given without error:
https://gcc.godbolt.org/z/MW2iQz
Note, a workaround accepted by all three major compilers is to qualify the
invocation with `this->`:
void foo(T t) noexcept(noexcept(this->B::foo(t))) {}
[Bug c++/88759] `decltype(auto)` as return type of abbreviated function template strips cv-qualifications and referenceness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88759 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Fixed for GCC 10 by the patch for PR69448.
[Bug c++/54366] [meta-bug] decltype issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54366 Bug 54366 depends on bug 88759, which changed state. Bug 88759 Summary: `decltype(auto)` as return type of abbreviated function template strips cv-qualifications and referenceness https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88759 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/94864] Failure to combine vunpckhpd+movsd into single vunpckhpd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864 --- Comment #3 from Segher Boessenkool --- vec_duplicate of vec_select is just a vec_select. Any vec_merge is a vec_select as well, as you say. Canonicalisation should make vec_select always. We probably should have canonicalisation rules for this, so that we do not get all those rtxes in the instruction stream at all.
[Bug c++/94929] [8 Regression] GCC 8 chokes on std::max in alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- I'm going to backport the fix to 8 if it passes the usual testing.
[Bug tree-optimization/93674] [8/9 Regression] GCC eliminates conditions it should not, when strict-enums is on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #21 from Richard Earnshaw --- Now fixed on all live branches
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #10 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #9) > > My initial thoughts are along the lines of... > > Only try to save FP registers that this function directly clobbers. > What's the point of saving these if a callee clobbers other registers? > They need to be done early enough to ensure that any code in *this* function does not clobber them. Any additional registers would have to be saved by a library call that does that. > Shouldn't that be something like save-nothing vs save-all-FP-regs if there > is a callee? > > Do you mean save direct clobbers only when the handler is a leaf function? Well, obviously if it's a leaf function, saving only the registers that are clobbered is enough, and the compiler can do the analysis to ensure that. > > > Provide libgcc routines to save/restore the FP context. > Do you mean such routines should push all FP regs+status regs? All registers that are are call clobbered. There's no need to do the call-saved registers as the compiler can do that on an as-needed case already.
[Bug c++/94896] [10/11 regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Patch reverted from 10/11.
[Bug c++/94775] [8/9 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:251c85372e088017e79894f50156901d112affee commit r10-8088-g251c85372e088017e79894f50156901d112affee Author: Marek Polacek Date: Mon May 4 10:41:24 2020 -0400 Revert "tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775]" Revert: 2020-04-30 Marek Polacek PR c++/94775 * tree.c (check_base_type): Return true only if TYPE_USER_ALIGN match. (check_aligned_type): Check if TYPE_USER_ALIGN match.
[Bug c++/94775] [8/9/10/11 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 Marek Polacek changed: What|Removed |Added Summary|[8/9 Regression] ICE in |[8/9/10/11 Regression] ICE |strip_typedefs, at |in strip_typedefs, at |cp/tree.c:1734 since|cp/tree.c:1734 since |r8-4668-g8a5ee94a082b3d48 |r8-4668-g8a5ee94a082b3d48 --- Comment #14 from Marek Polacek --- Patch reverted from 10/11.
[Bug c++/94745] No error emitted for unknown -Wno-meow argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745 --- Comment #4 from Louis Dionne --- Thanks for your replies, all. We resolved the problem on our side by not trying to workaround the lack of error, which means that we might end up passing `-Wno-foo` to GCC when it's not supported. I think that follows the design intent explained by Jonathan. Thanks again!
[Bug c++/94775] [8/9 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 --- Comment #12 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:05be85b649173b10d0bf10255eb15275c2dcf509 commit r11-42-g05be85b649173b10d0bf10255eb15275c2dcf509 Author: Marek Polacek Date: Mon May 4 10:26:43 2020 -0400 Revert "tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775]" This reverts commit 6318fe77395fc0dd59419bc4d69cd06ac0158e54. Revert: 2020-04-30 Marek Polacek PR c++/94775 * tree.c (check_base_type): Return true only if TYPE_USER_ALIGN match. (check_aligned_type): Check if TYPE_USER_ALIGN match.
[Bug c++/94896] [10/11 regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #6 from Christophe Lyon --- For the record, this introduces regressions on arm-linux-gnueabihf too: g++.dg/cpp0x/alignas3.C -std=c++14 (internal compiler error) g++.dg/cpp0x/alignas3.C -std=c++17 (internal compiler error) g++.dg/cpp0x/alignas3.C -std=c++2a (internal compiler error) g++.dg/other/pr54300.C -std=gnu++14 (internal compiler error) g++.dg/other/pr54300.C -std=gnu++17 (internal compiler error) g++.dg/other/pr54300.C -std=gnu++2a (internal compiler error) g++.dg/other/pr54300.C -std=gnu++98 (internal compiler error)
[Bug tree-optimization/92177] [10/11 regression] gcc.dg/vect/bb-slp-22.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Summary|[10 regression] |[10/11 regression]
|gcc.dg/vect/bb-slp-22.c |gcc.dg/vect/bb-slp-22.c
|FAILs |FAILs
Priority|P1 |P2
--- Comment #6 from Jakub Jelinek ---
Doesn't look like a release blocker though, it seems this isn't a wrong-code
issue.
sparc*-*-solaris* is not a vect_int_mult target, as it can't vectorize integer
multiplication, but on the testcase in question it doesn't vectorize that:
[bb-slp-22.c:29:24] _5 = x_48(D) + 1;
[bb-slp-22.c:29:19] _6 = _5 * a0_44;
- [bb-slp-22.c:29:14] [bb-slp-22.c:29:10] out[0] = _6;
[bb-slp-22.c:30:24] _7 = y_49(D) + 1;
[bb-slp-22.c:30:19] _8 = _7 * a1_45;
- [bb-slp-22.c:30:14] [bb-slp-22.c:30:10] out[1] = _8;
[bb-slp-22.c:31:19] _9 = _5 * a2_46;
- [bb-slp-22.c:31:14] [bb-slp-22.c:31:10] out[2] = _9;
[bb-slp-22.c:32:19] _10 = _7 * a3_47;
- [bb-slp-22.c:32:14] [bb-slp-22.c:32:10] out[3] = _10;
+ _70 = {_9, _10};
+ [bb-slp-22.c:29:14] vect_cst__71 = _70;
+ _72 = {_6, _8};
+ [bb-slp-22.c:29:14] vect_cst__73 = _72;
+ [bb-slp-22.c:29:14] MEM [(unsigned int *)] =
vect_cst__73;
+ [bb-slp-22.c:29:14] _75 = &[bb-slp-22.c:29:10] out[0] + 8;
+ [bb-slp-22.c:29:14] MEM [(unsigned int *)_75] =
vect_cst__71;
It just vectorizes the stores. So looks like a testsuite issue to me. Either
it needs to look for a different message in the dump file etc.
[Bug c++/94896] [10/11 regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- Will revert, sorry about that.
[Bug fortran/94925] Undesired runtime warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94925 --- Comment #2 from Fred Krogh --- I'm unclear on comment 1. Are you saying the code is such that this diagnostic can not be turned off and that is the way it should be, or that there is an a problem in gfortran with the if that is guarding the diagnostic. And if the latter, why not mark the status as confirmed. Thanks.
[Bug c++/94907] [10/11 Regression] ICE: Segmentation fault (in check_return_expr) since r10-8016-gbce54ed494fd0e61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94907 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 48442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48442=edit gcc11-pr94907.patch It seems wrong to call synthesize_method again on a decl on which it has been called already.
[Bug tree-optimization/93891] CSE where clobber writes the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93891 --- Comment #6 from Richard Biener --- Not yet fixed.
[Bug tree-optimization/93891] CSE where clobber writes the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93891 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:367766f40a031ff064857681dc4da3309f0ce57d commit r11-41-g367766f40a031ff064857681dc4da3309f0ce57d Author: Richard Biener Date: Tue Feb 25 11:46:02 2020 +0100 tree-optimization/93891 - improve same-store disambiguation We need a reference to assess alignment, fall back to the original reference tree if available. 2020-05-04 Richard Biener PR tree-optimization/93891 * tree-ssa-sccvn.c (vn_reference_lookup_3): Fall back to the original reference tree for assessing access alignment.
[Bug libstdc++/94936] pmr::synchronized_pool_resource crashes without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94936 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ec40967f1323069da3a5a45286f71fa4f80926df commit r11-40-gec40967f1323069da3a5a45286f71fa4f80926df Author: Jonathan Wakely Date: Mon May 4 13:34:23 2020 +0100 libstdc++: Make pmr::synchronized_pool_resource work without libpthread (PR 94936) I implicitly assumed that programs using pmr::synchronized_pool_resource would also be using multiple threads, and so the weak symbols in gthr-posix.h would be resolved by linking to libpthread. If that isn't true then it crashes when trying to use pthread_key_create. This commit makes the pool resource check __gthread_active_p() before using thread-specific data, and just use a single set of memory pools when there's only a single thread. PR libstdc++/94936 * src/c++17/memory_resource.cc (synchronized_pool_resource::_TPools): Add comment about single-threaded behaviour. (synchronized_pool_resource::_TPools::move_nonempty_chunks()): Hoist class member access out of loop. (synchronized_pool_resource::synchronized_pool_resource()) (synchronized_pool_resource::~synchronized_pool_resource()) (synchronized_pool_resource::release()): Check __gthread_active_p before creating and/or deleting the thread-specific data key. (synchronized_pool_resource::_M_thread_specific_pools()): Adjust assertions. (synchronized_pool_resource::do_allocate(size_t, size_t)): Add fast path for single-threaded case. (synchronized_pool_resource::do_deallocate(void*, size_t, size_t)): Likewise. Return if unable to find a pool that owns the allocation. * testsuite/20_util/synchronized_pool_resource/allocate_single.cc: New test. * testsuite/20_util/synchronized_pool_resource/cons_single.cc: New test. * testsuite/20_util/synchronized_pool_resource/release_single.cc: New test.
[Bug fortran/94909] Rejects valid code for recursion where there is none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94909 --- Comment #3 from Neil Carlson --- Richard, this is just a typical declaration of an abstract type. An extension of this type will have to define the deferred dot_ function with an interface that happens to match the interface of dot. The dot function will call that dot_ function, not itself, so there is no evident recursion here in this unit of code.
[Bug tree-optimization/94914] Failure to optimize check of high part of 64-bit result of 32 by 32 multiplication into overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914 --- Comment #5 from Jakub Jelinek --- (In reply to Marc Glisse from comment #4) > I thought we might already simplify (u >> 32) != 0 to u >= cst (other > possible forms are u != (uint64_t)(uint32_t)u, u & cst != 0, etc, I am > trying to think which one looks most canonical). We don't simplify that and am not sure it would actually be simplification in many cases. But perhaps we should have some canonical form if we don't already. > I expect in interesting cases the code will use z = (uint64_t)x * y twice, > once to check for overflow, and once as (uint32_t)z to get the actual result > (or there is a separate x*y and we want to CSE it with the overflow version). I'm afraid that is something that can't be matched in match.pd though, we'd need to do it elsewhere (e.g. tree-ssa-forwprop.c or tree-ssa-math-opts.c (next to match_uaddsub_overflow there?)).
[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 Richard Biener changed: What|Removed |Added Known to work||11.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #40 from Richard Biener --- And the missed optimization is now fixed as much as possible.
[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 --- Comment #39 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f9e1ea10e657af9fb02fafecf1a600740fd34409 commit r11-39-gf9e1ea10e657af9fb02fafecf1a600740fd34409 Author: Richard Biener Date: Thu Apr 30 10:47:15 2020 +0200 tree-optimization/39612 - avoid issueing loads in SM when possible Currently store-motion emits a load of the value in the loop preheader even when the original loop does not contain any read of the reference. This avoids doing this. In the conditional store-motion case we need to mark the sunk stores with no-warning since the control dependence is too tricky to figure out for the uninit warning. 2020-05-04 Richard Biener PR tree-optimization/39612 * tree-ssa-loop-im.c (im_mem_ref::loaded): New member. (set_ref_loaded_in_loop): New. (mark_ref_loaded): Likewise. (gather_mem_refs_stmt): Call mark_ref_loaded for loads. (execute_sm): Avoid issueing a load when it was not there. (execute_sm_if_changed): Avoid issueing warnings for the conditional store. * gcc.dg/tree-ssa/pr39612.c: New testcase.
[Bug fortran/93581] [9 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93581 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Tobias Burnus --- Now also FIXED on GCC 9. – Before it was committed to GCC mainline = GCC 10.
[Bug fortran/93581] [9 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93581 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:da710a35525cc7631b778fa4a5cfd20c366c01a4 commit r9-8565-gda710a35525cc7631b778fa4a5cfd20c366c01a4 Author: Tobias Burnus Date: Mon May 4 13:47:41 2020 +0200 ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951 gcc/testsuite/ Backport from mainline. 2020-03-08 Paul Thomas PR fortran/93581 * resolve.c (gfc_resolve_ref): Modify array refs to be elements if the ref chain ends in INQUIRY_LEN. * trans-array.c (gfc_get_dataptr_offset): Provide the offsets for INQUIRY_RE and INQUIRY_IM. gcc/testsuite/ Backport from mainline. 2020-03-08 Paul Thomas PR fortran/93581 * gfortran.dg/inquiry_type_ref_6.f90 : New test.
[Bug ipa/93385] [10/11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #33 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:375a77925c320a273d3b1ef3182f29f31aaa8edf commit r11-38-g375a77925c320a273d3b1ef3182f29f31aaa8edf Author: Martin Jambor Date: Mon May 4 13:53:54 2020 +0200 tree-inline: Simplify IPA-CP type conversion (PR 93385) when callers and callees do not quite agree on the type of a parameter, usually with ill-defined K or with smilarly wrong LTO input, IPA-CP can attempt to try and substitute a wrong type for a parameter (see e.g. gcc.dg/torture/pr48063.c). Function tree_function_versioning attempts to handle this in order not to create invalid gimple but it then creates the mapping using setup_one_parameter which also handles the same situation to avoid similar problems when inlining and in more defined way. So this patch simply removes the conversion attempts in tree_function_versioning itself. It is helpful for my upcoming fix of PR 93385 because then I do not need to teach ipa_param_body_adjustments to distinguish between successful and unsuccessful mappings - setup_one_parameter uses force_value_to_type for conversions which simly maps the worst cases to zero. 2020-05-04 Martin Jambor PR ipa/93385 * tree-inline.c (tree_function_versioning): Leave any type conversion of replacements to setup_one_parameter and its friend force_value_to_type.
[Bug target/94942] [10/11 Regression] ICE: in extract_constrain_insn, at recog.c:2195 (insn does not satisfy its constraints) with -O -flive-range-shrinkage -ftree-vrp -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94942 --- Comment #2 from Jakub Jelinek --- Created attachment 48441 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48441=edit gcc11-pr94942.patch Untested fix.
[Bug target/94650] Missed x86-64 peephole optimization: x >= large power of two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94650 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #4 from Uroš Bizjak --- Implemented for gcc-11.
[Bug c/78155] missing warning on invalid isalpha et al.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78155 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #6 from Bruno Haible --- Created attachment 48440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48440=edit Test case Another test case is the attached program, alpha.c. When run on glibc systems on x86, x86_64, and other CPUs (not powerpc), it sign-extends the 'char' argument; so the character 'ÿ' (in ISO-8859-1 encoding) becomes EOF, and the function returns 0. $ LC_ALL=de_DE.ISO-8859-1 xterm $ ./a.out ÿ not alphabetic The corrected program (with a cast to 'unsigned char' in the isalpha() argument) behaves as expected: $ LC_ALL=de_DE.ISO-8859-1 xterm $ ./a.out ÿ alphabetic
[Bug target/94650] Missed x86-64 peephole optimization: x >= large power of two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94650 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:8ea03e9016cbca5a7ee2b4befa4d5c32467b0982 commit r11-37-g8ea03e9016cbca5a7ee2b4befa4d5c32467b0982 Author: Uros Bizjak Date: Mon May 4 13:49:14 2020 +0200 i386: Use SHR to compare with large power-of-two constants [PR94650] Convert unsigned compares where m >= LARGE_POWER_OF_TWO and LARGE_POWER_OF_TWO represent an immediate where bit 33+ is set to use a SHR instruction and compare the result to 0. This avoids loading a large immediate with MOVABS insn. movabsq $1099511627775, %rax cmpq%rax, %rdi ja .L5 gets converted to: shrq$40, %rdi jne .L5 PR target/94650 * config/i386/predicates.md (shr_comparison_operator): New predicate. * config/i386/i386.md (compare->shr splitter): New splitters. testsuite/ChangeLog: PR target/94650 * gcc.targeti/i386/pr94650.c: New test.
[Bug fortran/94943] [10 Regression] A module does not export allocatable attribute of herein arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94943 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |10.0 Priority|P3 |P4 Known to work||9.3.1 Summary|A module does not export|[10 Regression] A module |allocatable attribute of|does not export allocatable |herein arrays. |attribute of herein arrays.
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #9 from Christophe Lyon --- > My initial thoughts are along the lines of... > Only try to save FP registers that this function directly clobbers. What's the point of saving these if a callee clobbers other registers? Shouldn't that be something like save-nothing vs save-all-FP-regs if there is a callee? Do you mean save direct clobbers only when the handler is a leaf function? > Provide libgcc routines to save/restore the FP context. Do you mean such routines should push all FP regs+status regs? > Or we could say simply: > interrupt routines should be compiled as if with -mgeneral-regs-only and if > they want to call some routine that uses FP then they must take it upon > themselves to save and restore the FP context.
[Bug tree-optimization/94914] Failure to optimize check of high part of 64-bit result of 32 by 32 multiplication into overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914 --- Comment #4 from Marc Glisse --- I thought we might already simplify (u >> 32) != 0 to u >= cst (other possible forms are u != (uint64_t)(uint32_t)u, u & cst != 0, etc, I am trying to think which one looks most canonical). I expect in interesting cases the code will use z = (uint64_t)x * y twice, once to check for overflow, and once as (uint32_t)z to get the actual result (or there is a separate x*y and we want to CSE it with the overflow version).
[Bug target/94942] [10/11 Regression] ICE: in extract_constrain_insn, at recog.c:2195 (insn does not satisfy its constraints) with -O -flive-range-shrinkage -ftree-vrp -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94942 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||jakub at gcc dot gnu.org Last reconfirmed||2020-05-04 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #1 from Jakub Jelinek --- Started with r10-2846-gbc4aa158c9490e76573bee3eec90f893b7d0b1ae Looking.
[Bug tree-optimization/94914] Failure to optimize check of high part of 64-bit result of 32 by 32 multiplication into overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914 --- Comment #3 from Jakub Jelinek --- Created attachment 48439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48439=edit gcc11-pr94914.patch Untested fix.
[Bug fortran/94943] New: A module does not export allocatable attribute of herein arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94943 Bug ID: 94943 Summary: A module does not export allocatable attribute of herein arrays. Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: artu72 at gmail dot com Target Milestone: --- Created attachment 48438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48438=edit contains the compiler version, command line, errors, and the module file and the routine that uses it with .s files. A module contains several arrays with ALLOCATABLE attribute. When compiling, the routine that uses the module complains that array is not an allocatable one neither a pointer. Expected behavior (as in 9.3.1 version) : no error reported and compilation completes. Current behavior: error reported, as in the attachment. I attach an archive with following files: commandline : the command mpif90 arising the error deallocate_vars.f90 : routine that uses the sel module deallocate_vars.s (no .i file generated, I include this instead) error : error issued by the compiler sel_mod.f90 : module containing the arrays sel_mod.s version : version of gfortran mpif90 wraps as gfortran -I/usr/include/openmpi-x86_64 -pthread -I/usr/lib64/openmpi/lib -Wl,-rpath -Wl,/usr/lib64/openmpi/lib -Wl,--enable-new-dtags -L/usr/lib64/openmpi/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
[Bug target/94942] New: [10/11 Regression] ICE: in extract_constrain_insn, at recog.c:2195 (insn does not satisfy its constraints) with -O -flive-range-shrinkage -ftree-vrp -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94942
Bug ID: 94942
Summary: [10/11 Regression] ICE: in extract_constrain_insn, at
recog.c:2195 (insn does not satisfy its constraints)
with -O -flive-range-shrinkage -ftree-vrp -mavx512vl
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Created attachment 48437
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48437=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -flive-range-shrinkage -ftree-vrp -mavx512vl
testcase.c
testcase.c: In function 'foo':
testcase.c:16:31: warning: division by zero [-Wdiv-by-zero]
16 | W v = (k | k >> m + (W){4}) % 0;
| ^
testcase.c:20:1: error: insn does not satisfy its constraints:
20 | }
| ^
(insn 365 309 359 2 (set (reg:V8HI 20 xmm0 [511])
(vec_duplicate:V8HI (reg:HI 52 xmm16))) "testcase.c":15:5 5054
{*vec_dupv8hi}
(expr_list:REG_DEAD (reg:HI 52 xmm16)
(nil)))
during RTL pass: cprop_hardreg
testcase.c:20:1: internal compiler error: in extract_constrain_insn, at
recog.c:2195
0x6d467c _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0x6d4709 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:118
0x6c3d6c extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2195
0xf4aadc copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.c:802
0xf4bd4e execute
/repo/gcc-trunk/gcc/regcprop.c:1367
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-36-20200504110332-g6b5c7ee0df6-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-36-20200504110332-g6b5c7ee0df6-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200504 (experimental) (GCC)
[Bug c/94903] [8/9 Regression] internal compiler error: in assign_temp, at function.c:982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94903 --- Comment #3 from Richard Biener --- Feel free to backport, it certainly doesn't have high priority.
[Bug tree-optimization/94914] Failure to optimize check of high part of 64-bit result of 32 by 32 multiplication into overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- They are used also __builtin_*_overflow* builtins. And, we already match ((__typeof (x)) -1) / y < x into __builtin_mul_overflow_p (x, y, __typeof (x)) for x and y unsigned types with the same precision, so I think this request is just for another matcher. I'll handle it.
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #3 from Antony Lewis --- Although my reduced test in the other id case is one problem, it appears that is not the only memory leak. Someone tested else on various gcc versions and still found: versionmemory leak 7.3.0 no 8.2.0 no 7.5.0 yes 8.4.0 yes 9.2.0 yes 9.3.0 yes So it certainly looks like a regression.
[Bug c/94903] [8/9 Regression] internal compiler error: in assign_temp, at function.c:982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94903 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This got fixed with r10-4402-g5f6705b7b57c0461766f784d6d495986163692bb aka PR92352. And because it was ice-on-invalid, it wasn't backported. Started to ICE with r6-6108-g451773378f6808ce2b1e1d4eaed40b164ad590da Richard, if you think I should backport this, I can.
