[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541 --- Comment #5 from frankhb1989 at gmail dot com --- (In reply to Jonathan Wakely from comment #4) > This might strictly conform to the requirements, but it's stupid. Why would > you do that? > > Allocator equality doesn't care about the value type, as evidenced by the > requirement that a==b is equivalent to a==Y::rebind::other(b). So if the > result of == doesn't care about the value type, then why would > is_always_equal depend on it? Because I find no standard rules to prevent such stupid things. With such cases, the container implementations are potentially broken: if the node allocator is not is_always_true nor POCCA, and it actually throws on comparison, then the noexcept specification will cause the program terminate. This is quite counterintuitive, and I don't see this is intended anyway. Probably the easiest resolution is to add one more requirement of invariant on is_always_equal in the standard to ensure that each rebind result will keep is_always_equal unchanged. This is likely to be a DR as is_always_equal has been explicitly used as the part of noexcept specifications of containers' operator= in the standard, and I don't see the way to fix it merely for individual node-based container implementations. (Not sure traits like POCCA need the additional requirement, though.) And the noexcept exceptions provided in the current implementations are really inconsistent, for instance, between move operator= of std::list and std::map. Whether the fix above is adopted, at least one container implementation in libstdc++ is not conforming. Allocator-extended move constructors are similarly broken despite the explicit noexcept specifications required in the standard. However, if it is resolved by the fix in the standard, the implementation can remain unchanged.
[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478 --- Comment #26 from Martin Liška --- > Looking good! It fixes the testcase. Full build and check started. Great, then I'm going to send the patch to mailing list. Thanks a lot for the testing.
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549 --- Comment #3 from rdapp at linux dot ibm.com --- This fails a lot more than it should. I'm looking into it.
[Bug target/91528] [10 Regression] ICE in ix86_expand_prologue at i386.c:7844 since r274481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528 --- Comment #8 from Richard Biener --- (In reply to Uroš Bizjak from comment #5) > Created attachment 46753 [details] > Conditionally generate DRAP reg for realigned stack > > This should be the correct patch, we call targetm.calls.get_drap_rtx only > when crtl->drap_reg is null (get_drap_rtx also emits DRAP initialization > sequence). > > Richi, can you please put the patch through your testing with forced STV on > -march=westmere? I'm bootstrapping with the patch, but this means little > with generic bootstrap. The patch passed bootstrap with -march=westmere for all languages with STV forced to convert all chains. Testing is a bit fragile since for example we build most gcc.target/i386/avx512*.c tests with some -mavx512 flags and expect no AVX512 insns to be used before the CPUID verification - of course with all chains actually converted some AVX512 insns creep in into the CPUID verification path and the tests fail with an illegal instruction (so techincally the testcases are invalid since the main driver with the CPUID check is compiled with -mavx512*).
[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541 --- Comment #6 from frankhb1989 at gmail dot com --- (In reply to frankhb1989 from comment #5) > > And the noexcept exceptions provided in the current implementations are > really inconsistent, for instance, between move operator= of std::list and > std::map. Whether the fix above is adopted, at least one container > implementation in libstdc++ is not conforming. > Correction: if the additional requirement is adopted, there will be no need to modify libstdc++ code for conformance. The inconsistency will remain literally (`_Node_alloc_traits::_S_nothrow_move()` in the std::list vs. implicit `_Alloc_traits::_S_nothrow_move() ...` implied by _Rb_tree), though.
[Bug target/91528] [10 Regression] ICE in ix86_expand_prologue at i386.c:7844 since r274481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528 --- Comment #9 from Uroš Bizjak --- (In reply to Richard Biener from comment #8) > (In reply to Uroš Bizjak from comment #5) > > Created attachment 46753 [details] > > Conditionally generate DRAP reg for realigned stack > > > > This should be the correct patch, we call targetm.calls.get_drap_rtx only > > when crtl->drap_reg is null (get_drap_rtx also emits DRAP initialization > > sequence). > > > > Richi, can you please put the patch through your testing with forced STV on > > -march=westmere? I'm bootstrapping with the patch, but this means little > > with generic bootstrap. > > The patch passed bootstrap with -march=westmere for all languages with > STV forced to convert all chains. Great! > Testing is a bit fragile since for example we build most > gcc.target/i386/avx512*.c tests with some -mavx512 flags and expect no > AVX512 insns to be > used before the CPUID verification - of course with all chains actually > converted some AVX512 insns creep in into the CPUID verification path and > the tests fail with an illegal instruction (so techincally the testcases > are invalid since the main driver with the CPUID check is compiled with > -mavx512*). Dynamic re-alignment and prologue/epilogue construction code is sprinkled with many (helpful!) asserts, so the compilation would break left and right if we got realignment functionality wrong. Based on your testing, I feel confident enough that my patch is OK, so let's proceed with this one and keep an eye on testers and fuzzers.
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #4 from rdapp at linux dot ibm.com ---
Would this be ok?
diff --git a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
index 44d85c04bfb..0d83384cd0a 100644
--- a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
+++ b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
@@ -1,5 +1,5 @@
-/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-vrp2-details" } */
+/* { dg-do compile { target x86_64-*-* s390x-*-* } } */
+/* { dg-options "-O2 -fdump-tree-vrp2-details -m64" } */
/* { dg-final { scan-tree-dump-times "gimple_simplified to" 4 "vrp2" } } */
void v1 (unsigned long *in, unsigned long *out, unsigned int n)
[Bug fortran/91552] ICE with valid array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91552 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it's very old: ==31707== Warning: set address range perms: large range [0x5577040, 0x25577050) (undefined) ==31707== Invalid read of size 8 ==31707==at 0x4B604A9: __gmpn_mul_basecase_coreihwl (tmp-coreihwl_mul_basecase.s:153) ==31707==by 0x4B80A3F: ??? (in /usr/lib64/libgmp.so.10.3.2) ==31707== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==31707== f951: internal compiler error: Segmentation fault 0x4d99e4f ??? /usr/src/debug/glibc-2.29-7.3.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x4b604a9 ??? /usr/src/debug/gmp-6.1.2-4.2.x86_64/mpn/tmp-coreihwl_mul_basecase.s:153
[Bug fortran/91553] ICE in gfc_real2complex, at fortran/arith.c:2208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91553 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #5 from Uroš Bizjak ---
(In reply to rdapp from comment #4)
> Would this be ok?
>
> diff --git a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
> b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
> index 44d85c04bfb..0d83384cd0a 100644
> --- a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
> +++ b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
> @@ -1,5 +1,5 @@
> -/* { dg-do compile } */
> -/* { dg-options "-O2 -fdump-tree-vrp2-details" } */
> +/* { dg-do compile { target x86_64-*-* s390x-*-* } } */
> +/* { dg-options "-O2 -fdump-tree-vrp2-details -m64" } */
> /* { dg-final { scan-tree-dump-times "gimple_simplified to" 4 "vrp2" } } */
>
> void v1 (unsigned long *in, unsigned long *out, unsigned int n)
This approach is not OK, you should use lp64 effective target instead of -m64
option. Please see many examples in testsuite/gcc.dg.
Also, x86 is a multilib target, described as { i?86-*-* x86_64-*-* }.
[Bug fortran/90519] ICE (segfault) on derived type which has a recursive allocatable component of the same type, and a static component of another type which has a "final" attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90519 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #2 from G. Steinmetz --- One possible simplification might be this legal code : $ cat z1.f90 module m type t contains final :: g end type type t2 type(t) :: a type(t2), allocatable :: b(:) end type contains subroutine g(x) type(t) :: x end end $ gfortran-10-20190825 -c z1.f90 during RTL pass: expand z1.f90:14:0: 14 | end | internal compiler error: Segmentation fault 0xb3acef crash_signal ../../gcc/toplev.c:326 0x87d5ca expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:8273 0x78393e expand_expr ../../gcc/expr.h:281 0x78393e expand_call_stmt ../../gcc/cfgexpand.c:2731 0x78393e expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3710 0x78393e expand_gimple_stmt ../../gcc/cfgexpand.c:3875 0x7884c7 expand_gimple_basic_block ../../gcc/cfgexpand.c:5915 0x78ab66 execute ../../gcc/cfgexpand.c:6538
[Bug fortran/91557] New: [7/8/9/10 Regression] Bogus warning about unused dummy argument _formal_*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91557 Bug ID: 91557 Summary: [7/8/9/10 Regression] Bogus warning about unused dummy argument _formal_* Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- There is an _old_ issue with -Wall (-Wunused-dummy-argument) and _legal_ code with contained procedures. It does not depend on specific types. Starting with z0.f90 and refactoring it to z1.f90 : $ cat z0.f90 program p integer :: a, b a = 1 call g (a, b) end subroutine g (a, b) integer :: a, b integer :: x, y call h (x, y) if ( a > 0 ) y = y - 1 b = y - x + 1 end $ gfortran-10-20190825 -c z0.f90 -Wall $ $ cat z1.f90 program p integer :: a, b a = 1 call g contains subroutine g integer :: x, y call h (x, y) if ( a > 0 ) y = y - 1 b = y - x + 1 end end $ gfortran-6 -c z1.f90 -Wall $ $ gfortran-7 -c z1.f90 -Wall z1.f90:8:19: call h (x, y) 1 Warning: Unused dummy argument '_formal_0' at (1) [-Wunused-dummy-argument] z1.f90:8:19: call h (x, y) 1 Warning: Unused dummy argument '_formal_1' at (1) [-Wunused-dummy-argument] $ gfortran-10-20190825 -c z1.f90 -Wall z1.f90:9:19: 9 | call h (x, y) | 1 Warning: Unused dummy argument '_formal_2' at (1) [-Wunused-dummy-argument] z1.f90:9:19: 9 | call h (x, y) | 1 Warning: Unused dummy argument '_formal_3' at (1) [-Wunused-dummy-argument] The numbering (0/1->2/3) has changed between 20190818 and 20190825. Might be one root cause of pr91556.
[Bug target/91528] [10 Regression] ICE in ix86_expand_prologue at i386.c:7844 since r274481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528 --- Comment #10 from Richard Biener --- (In reply to Uroš Bizjak from comment #9) > (In reply to Richard Biener from comment #8) > > (In reply to Uroš Bizjak from comment #5) > > > Created attachment 46753 [details] > > > Conditionally generate DRAP reg for realigned stack > > > > > > This should be the correct patch, we call targetm.calls.get_drap_rtx only > > > when crtl->drap_reg is null (get_drap_rtx also emits DRAP initialization > > > sequence). > > > > > > Richi, can you please put the patch through your testing with forced STV > > > on > > > -march=westmere? I'm bootstrapping with the patch, but this means little > > > with generic bootstrap. > > > > The patch passed bootstrap with -march=westmere for all languages with > > STV forced to convert all chains. > > Great! > > > Testing is a bit fragile since for example we build most > > gcc.target/i386/avx512*.c tests with some -mavx512 flags and expect no > > AVX512 insns to be > > used before the CPUID verification - of course with all chains actually > > converted some AVX512 insns creep in into the CPUID verification path and > > the tests fail with an illegal instruction (so techincally the testcases > > are invalid since the main driver with the CPUID check is compiled with > > -mavx512*). > > Dynamic re-alignment and prologue/epilogue construction code is sprinkled > with many (helpful!) asserts, so the compilation would break left and right > if we got realignment functionality wrong. > > Based on your testing, I feel confident enough that my patch is OK, so let's > proceed with this one and keep an eye on testers and fuzzers. Will you apply it?
[Bug libstdc++/91547] std::string_view find_last_not_of can trigger unsigned integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91547 --- Comment #3 from Mateusz Szychowski --- > The behaviour of that function is perfectly well defined. > Yes because it is not useful and causes to print when there is no bug at all > and wrapping behavior is expected. It was a decison that GCC does not > implement this option due to the very valid code just being printed out about > it. Okay, thank you for time and for explaining me why it isn't implemented in GCC.
[Bug c/88944] Suggested alternative C stdbool.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88944 --- Comment #4 from Jonathan Wakely --- The patch is pending, not committed.
[Bug target/91528] [10 Regression] ICE in ix86_expand_prologue at i386.c:7844 since r274481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528 --- Comment #11 from Uroš Bizjak --- (In reply to Richard Biener from comment #10) > Will you apply it? Sure, later today.
[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541 --- Comment #7 from Jonathan Wakely --- I can't believe that this has ever caused a real problem, or ever will cause a real problem.
[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #8 from frankhb1989 at gmail dot com ---
(In reply to frankhb1989 from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > This might strictly conform to the requirements, but it's stupid. Why would
> > you do that?
> >
> > Allocator equality doesn't care about the value type, as evidenced by the
> > requirement that a==b is equivalent to a==Y::rebind::other(b). So if the
> > result of == doesn't care about the value type, then why would
> > is_always_equal depend on it?
>
> ..., and it actually throws on
> comparison, then ... .
>
... My bad. I should have meant that it might throw when the result of the
result of == for node_allocator is `false`. This is even more stupid: `a ==
Y::rebind::other(b)` does not effectively imply that two values of type
`Y::rebind::other` will always be equal, even that there are requirements of
"reflexive, symmetric, and transitive" on "a1 == a2", consistent false negative
results are not prevented because such requirements are not also forced on "a
== b", so such definitions are allowed:
bool operator==(const X&, const X&) noexcept
{
return true;
}
bool operator==(const Y& a1, const Y& a2) noexcept
{
return &a1 == &a2;
}
bool operator==(const X& a, const Y& b) noexcept
{
return a == Y::rebind::other(b);
}
bool operator==(const Y& b, const X& a) noexcept
{
return b == Y::rebind::other(a);
}
where `T` is the container `value_type` equivalent to `value_type` of allocator
type `X` and `U` is the container node type equivalent `value_type` of
allocator type `Y`.
[Bug fortran/91550] [8/9/10 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2652
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91550 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.4
[Bug fortran/91551] [9/10 Regression] ICE in sort_actual, at fortran/intrinsic.c:4193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91551 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #9 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #8)
> bool operator==(const Y& a1, const Y& a2) noexcept
> {
> return &a1 == &a2;
No, this is not allowed.
A copy of an allocator must compare equal to the original, so for "X u(a);" it
holds that "u == a". And a rebound copy of an allocator must also compare
equal, so for "X u(b);" it holds that "Y(u) == b && u == X(b)".
You're trying harder and harder to show a problem, and I simply don't believe
this can ever be a problem in real code. Any valid example you can construct
will be something completely stupid that I don't care about supporting because
we have far more important things to worry about.
[Bug c/91554] if (!__builtin_constant_p (x)) warning_function() works in inline when x is int, not when x is void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-08-27
Version|unknown |9.2.1
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Already the frontend (or GENERIC expression simplification) generates
;; Function thefun (null)
;; enabled by -tree-original
{
if (1)
{
thefun_called_with_nonnull_arg ();
}
return real_thefun (a, b);
I couldn't quickly spot who does this though...
[Bug fortran/91556] Severe regression with real types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 --- Comment #8 from Richard Biener --- Happens all over SPEC sources as well :/ Tacking more -std=legacy into FFLAGS...
[Bug fortran/91557] [7/8/9/10 Regression] Bogus warning about unused dummy argument _formal_*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91557 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |7.5
[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541 --- Comment #10 from Jonathan Wakely --- I don't think it's possible to construct an example where this would misbehave. If allocator_traits::is_always_equal is true for X then it implies that operator== will return true for all values of X, **and also** for any values of Y that are constructed from values of X. Even if allocator_traits::is_always_equal is actually false (because some values of Y can compare non-equal), **for the specific values we care about** (i.e. ones constructed by copying an X), operator== will always return true. That means we don't need to reallocate, and so no exceptions are possible. What really matters is whether we need to reallocate, **not** whether allocator_traits::is_always_equal is true or not. As long as we don't reallocate, we won't get exceptions, and so we won't try to throw from a noexcept function. So you're worrying about nothing and wasting your time and mine.
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #6 from rdapp at linux dot ibm.com ---
(In reply to Uroš Bizjak from comment #5)
> This approach is not OK, you should use lp64 effective target instead of
> -m64 option. Please see many examples in testsuite/gcc.dg.
>
> Also, x86 is a multilib target, described as { i?86-*-* x86_64-*-* }.
Would this one do?
diff --git a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
index 44d85c04bfb..a5d953b46c7 100644
--- a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
+++ b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { { i?86-*-* x86_64-*-* s390*-*-* } && lp64 } } }
*/
/* { dg-options "-O2 -fdump-tree-vrp2-details" } */
/* { dg-final { scan-tree-dump-times "gimple_simplified to" 4 "vrp2" } } */
[Bug libstdc++/81806] Split in pbds works in O(n) instead of O(log n)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806 --- Comment #8 from Jonathan Wakely --- (In reply to Xi Ruoyao from comment #7) > Oh I didn't expect an ABI breakage. I thought "pb_ds is a source code > library so there is no ABI in libstdc++.so". Now I understand that we > should not break old third-party libraries compiled with the old pb_ds > headers (is there any? :) The libstdc++ ABI is larger than the set of symbols exported from libstdc++.so std::vector is defined entirely in headers, not exported from libstdc++.so, but we can't just change its layout. That would make it impossible to link objects compiled with different versions of GCC because they would disagree on the layout of std::vector. So this isn't about third-party libraries, it's about all code that uses pb_ds. If you compile foo.o with one version of GCC and bar.o with another version of GCC, then you should be able to link them together.
[Bug libstdc++/81806] Split in pbds works in O(n) instead of O(log n)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-27 Ever confirmed|0 |1
[Bug libstdc++/81806] Split in pbds works in O(n) instead of O(log n)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806 --- Comment #9 from Jonathan Wakely --- **But**, as I said, I think it's OK to change the pb_ds types. We can use inline namespaces to change the mangled names of the affected types, and the user base of pb_ds is probably so tiny that it won't actually hurt anybody. Changing std::vector would not be OK, because everybody uses it.
[Bug libstdc++/91531] _Rb_tree's copy assignment should respect to POCCA regardless of is_always_equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91531 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-27 Ever confirmed|0 |1 Severity|normal |minor --- Comment #1 from Jonathan Wakely --- Meh. Confirmed, but I'm not going to work on this myself as I don't think it matters in practice.
[Bug libgomp/91530] Several libgomp.*/scan-* tests FAIL without avx_runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91530 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Aug 27 10:45:55 2019 New Revision: 274947 URL: https://gcc.gnu.org/viewcvs?rev=274947&root=gcc&view=rev Log: PR libgomp/91530 * testsuite/libgomp.c/scan-11.c: Add -msse2 option for sse2_runtime targets. * testsuite/libgomp.c/scan-12.c: Likewise. * testsuite/libgomp.c/scan-13.c: Likewise. * testsuite/libgomp.c/scan-14.c: Likewise. * testsuite/libgomp.c/scan-15.c: Likewise. * testsuite/libgomp.c/scan-16.c: Likewise. * testsuite/libgomp.c/scan-17.c: Likewise. * testsuite/libgomp.c/scan-18.c: Likewise. * testsuite/libgomp.c/scan-19.c: Likewise. * testsuite/libgomp.c/scan-20.c: Likewise. * testsuite/libgomp.c++/scan-9.C: Likewise. * testsuite/libgomp.c++/scan-10.C: Likewise. * testsuite/libgomp.c++/scan-11.C: Likewise. * testsuite/libgomp.c++/scan-12.C: Likewise. * testsuite/libgomp.c++/scan-14.C: Likewise. * testsuite/libgomp.c++/scan-15.C: Likewise. * testsuite/libgomp.c++/scan-13.C: Likewise. Use sse2_runtime instead of i?86-*-* x86_64-*-* as target for scan-tree-dump-times. * testsuite/libgomp.c++/scan-16.C: Likewise. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.c++/scan-10.C trunk/libgomp/testsuite/libgomp.c++/scan-11.C trunk/libgomp/testsuite/libgomp.c++/scan-12.C trunk/libgomp/testsuite/libgomp.c++/scan-13.C trunk/libgomp/testsuite/libgomp.c++/scan-14.C trunk/libgomp/testsuite/libgomp.c++/scan-15.C trunk/libgomp/testsuite/libgomp.c++/scan-16.C trunk/libgomp/testsuite/libgomp.c++/scan-9.C trunk/libgomp/testsuite/libgomp.c/scan-11.c trunk/libgomp/testsuite/libgomp.c/scan-12.c trunk/libgomp/testsuite/libgomp.c/scan-13.c trunk/libgomp/testsuite/libgomp.c/scan-14.c trunk/libgomp/testsuite/libgomp.c/scan-15.c trunk/libgomp/testsuite/libgomp.c/scan-16.c trunk/libgomp/testsuite/libgomp.c/scan-17.c trunk/libgomp/testsuite/libgomp.c/scan-18.c trunk/libgomp/testsuite/libgomp.c/scan-19.c trunk/libgomp/testsuite/libgomp.c/scan-20.c
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #7 from Uroš Bizjak ---
(In reply to rdapp from comment #6)
> (In reply to Uroš Bizjak from comment #5)
> > This approach is not OK, you should use lp64 effective target instead of
> > -m64 option. Please see many examples in testsuite/gcc.dg.
> >
> > Also, x86 is a multilib target, described as { i?86-*-* x86_64-*-* }.
>
> Would this one do?
>
> diff --git a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
> b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
> index 44d85c04bfb..a5d953b46c7 100644
> --- a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
> +++ b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile } */
> +/* { dg-do compile { target { { i?86-*-* x86_64-*-* s390*-*-* } && lp64 } }
> } */
> /* { dg-options "-O2 -fdump-tree-vrp2-details" } */
> /* { dg-final { scan-tree-dump-times "gimple_simplified to" 4 "vrp2" } } */
Yes, I think so.
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549 --- Comment #8 from rdapp at linux dot ibm.com --- > Yes, I think so. Is this an OK to commit? :) I checked it on s390 and x86_64 with -m64 and -m31/-m32.
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549 --- Comment #9 from Uroš Bizjak --- (In reply to rdapp from comment #8) > > Yes, I think so. > > Is this an OK to commit? :) > > I checked it on s390 and x86_64 with -m64 and -m31/-m32. OK. Please go ahead.
[Bug lto/41731] The linker plugin should support translations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41731 --- Comment #2 from joseph at codesourcery dot com --- https://gcc.gnu.org/ml/gcc-patches/2009-10/msg01016.html
[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #27 from Martin Liška --- Patch has been sent: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01813.html
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549 --- Comment #10 from rdapp at gcc dot gnu.org --- Author: rdapp Date: Tue Aug 27 12:08:58 2019 New Revision: 274951 URL: https://gcc.gnu.org/viewcvs?rev=274951&root=gcc&view=rev Log: PR testsuite/91549 gcc/testsuite/ChangeLog: * gcc.dg/wrapped-binop-simplify.c: Test only on x86, s390 with lp64. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
[Bug libgomp/91530] Several libgomp.*/scan-* tests FAIL without avx_runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91530
--- Comment #5 from Jakub Jelinek ---
Created attachment 46764
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46764&action=edit
gcc10-pr91530-sse2.patch
Patch to hopefully fix the scan-{13,17}.c FAILs without avx_runtime.
[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-08-27
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Martin Liška ---
There's a reduced test-case:
$ cat pr91470.ii
int input_location, global_trees_0, gfc_conv_intrinsic_findloc_body,
gfc_conv_intrinsic_findloc_loopblock, gfc_conv_intrinsic_findloc_tmp,
gfc_conv_intrinsic_findloc_found, gfc_conv_intrinsic_findloc_loop;
enum tree_code { COND_EXPR };
struct A {};
struct B {
int pre;
int expr;
};
void fn1(B *, B *);
void fn2(int *, int *);
int *fn3(int *);
void fn4(int, tree_code, int *, int *, int *, int);
void fn5(B *, int *);
void fn6() {
A array_arg, value_arg, dim_arg, mask_arg, kind_arg, back_arg;
int *forward_branch;
B arrayse, valuese, maskse, backse;
int i;
value_arg = array_arg;
mask_arg = dim_arg;
back_arg = kind_arg;
for (i = 0; i < 2; i++) {
fn5(&maskse, &gfc_conv_intrinsic_findloc_loop);
fn1(&arrayse, __null);
fn2(&gfc_conv_intrinsic_findloc_body, &valuese.pre);
fn4(input_location, COND_EXPR, &global_trees_0,
&gfc_conv_intrinsic_findloc_tmp, &gfc_conv_intrinsic_findloc_found, 0);
if (i == 0)
forward_branch = fn3(&gfc_conv_intrinsic_findloc_loopblock);
}
fn4(input_location, COND_EXPR, &global_trees_0, &backse.expr, forward_branch,
0);
}
[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Tue Aug 27 12:37:30 2019 New Revision: 274952 URL: https://gcc.gnu.org/viewcvs?rev=274952&root=gcc&view=rev Log: PR c++/91415 * c-common.c (verify_tree): For LSHIFT_EXPR, RSHIFT_EXPR, COMPONENT_REF and ARRAY_REF in cxx_dialect >= cxx17 mode handle it like COMPOUND_EXPR rather than normal expression. * g++.dg/warn/sequence-pt-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/sequence-pt-4.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
--- Comment #3 from rguenther at suse dot de ---
On Tue, 27 Aug 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
>
> Martin Liška changed:
>
>What|Removed |Added
>
>Keywords|needs-reduction |
> Status|UNCONFIRMED |NEW
>Last reconfirmed||2019-08-27
> CC||marxin at gcc dot gnu.org
> Ever confirmed|0 |1
>
> --- Comment #2 from Martin Liška ---
> There's a reduced test-case:
>
> $ cat pr91470.ii
> int input_location, global_trees_0, gfc_conv_intrinsic_findloc_body,
> gfc_conv_intrinsic_findloc_loopblock, gfc_conv_intrinsic_findloc_tmp,
> gfc_conv_intrinsic_findloc_found, gfc_conv_intrinsic_findloc_loop;
> enum tree_code { COND_EXPR };
> struct A {};
> struct B {
> int pre;
> int expr;
> };
> void fn1(B *, B *);
> void fn2(int *, int *);
> int *fn3(int *);
> void fn4(int, tree_code, int *, int *, int *, int);
> void fn5(B *, int *);
> void fn6() {
> A array_arg, value_arg, dim_arg, mask_arg, kind_arg, back_arg;
> int *forward_branch;
> B arrayse, valuese, maskse, backse;
> int i;
> value_arg = array_arg;
> mask_arg = dim_arg;
> back_arg = kind_arg;
> for (i = 0; i < 2; i++) {
> fn5(&maskse, &gfc_conv_intrinsic_findloc_loop);
> fn1(&arrayse, __null);
> fn2(&gfc_conv_intrinsic_findloc_body, &valuese.pre);
> fn4(input_location, COND_EXPR, &global_trees_0,
> &gfc_conv_intrinsic_findloc_tmp, &gfc_conv_intrinsic_findloc_found,
> 0);
> if (i == 0)
> forward_branch = fn3(&gfc_conv_intrinsic_findloc_loopblock);
> }
> fn4(input_location, COND_EXPR, &global_trees_0, &backse.expr,
> forward_branch,
> 0);
> }
So this is basically
int x;
for (int i = 0; i < 2; ++i)
if (i == 0) x = bar();
baz(x);
with making sure we do _not_ thread / header copy / unroll this.
The uninit pass warns about the default def flowing into the loop PHI
node here.
[Bug libstdc++/91558] New: [C++11] should not be constexpr until C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558 Bug ID: 91558 Summary: [C++11] should not be constexpr until C++14 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: yichen.yan at inf dot ethz.ch Target Milestone: --- Detail: Constexpr for is in C++14 if I don't misunderstand. But a lot of testcases under libstdc++-v3/testsuite/26_numerics/complex/ (e.g. dr844.cc) runs with C++11 and check for constexpr (and pass). I haven't found some manual or doc explaining that, and wonder if this is a bug or some feature?
[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415 --- Comment #10 from Jakub Jelinek --- Partially fixed, needs more work, so keeping this open.
[Bug ipa/91468] Suspicious codes in ipa-prop.c and ipa-cp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91468 --- Comment #3 from Martin Jambor --- I have proposed a patch on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01820.html
[Bug c/91554] if (!__builtin_constant_p (x)) warning_function() works in inline when x is int, not when x is void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554
--- Comment #2 from Zack Weinberg ---
Additional fun detail:
```
static inline int
thefun (void *a, void *b)
{
if (!__builtin_constant_p((__UINTPTR_TYPE__)b) || b != 0)
thefun_called_with_nonnull_arg();
return real_thefun(a, b);
}
```
still warns for any use of `thefun`, but
```
static inline int
thefun (void *a, void *b)
{
if (!__builtin_constant_p((short)(__UINTPTR_TYPE__)b) || b != 0)
thefun_called_with_nonnull_arg();
return real_thefun(a, b);
}
```
works as intended! `(int)(__UINTPTR_TYPE__)` also works as intended on targets
where __UINTPTR_TYPE__ is bigger than int.
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/builtins.c;h=f902e246f1f347be4d4dc04e339fa865393039fe#l8462
looks suspicious to me. Note also the STRIP_NOPS shortly above, which might
explain why it matters whether the pointer is cast to a different-sized integer
type.
[Bug c/91554] if (!__builtin_constant_p (fn_arg)) warning_function() works in inline when fn_arg is int, not when it is void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554 --- Comment #3 from Richard Biener --- It's obviously 8462 /* If this expression has side effects, show we don't know it to be a 8463 constant. Likewise if it's a pointer or aggregate type since in 8464 those case we only want literals, since those are only optimized 8465 when generating RTL, not later. 8466 And finally, if we are compiling an initializer, not code, we 8467 need to return a definite result now; there's not going to be any 8468 more optimization done. */ 8469 if (TREE_SIDE_EFFECTS (arg) 8470 || AGGREGATE_TYPE_P (TREE_TYPE (arg)) 8471 || POINTER_TYPE_P (TREE_TYPE (arg)) 8472 || cfun == 0 8473 || folding_initializer 8474 || force_folding_builtin_constant_p) 8475 return integer_zero_node; that causes this, I guess you want to use __builtin_constant_p (b != 0) instead. The docs don't explain what a "constant at compile time" is so whether for example the address of a global or the address of an automatic var would be "constant". But I'd say the above incorrectly disregards the NULL-pointer case.
[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478 --- Comment #28 from Martin Liška --- Author: marxin Date: Tue Aug 27 13:36:15 2019 New Revision: 274955 URL: https://gcc.gnu.org/viewcvs?rev=274955&root=gcc&view=rev Log: Share a prevailing name for remove debug info symbols w/ LTO. 2019-08-27 Martin Liska PR lto/91478 * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): First find a WEAK HIDDEN symbol in symbol table that will be preserved. Later, use the symbol name for all removed symbols. Modified: trunk/libiberty/ChangeLog trunk/libiberty/simple-object-elf.c
[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #29 from Martin Liška --- Should be fixed now.
[Bug libquadmath/91559] New: math/x2y2m1q.c assumes FE_TONEAREST defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91559 Bug ID: 91559 Summary: math/x2y2m1q.c assumes FE_TONEAREST defined Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: joel at gcc dot gnu.org Target Milestone: --- newlib has been updated to always provide an fenv.h with prototypes for the required methods. Unfortunately, this has triggered code in math/x2y2m1q.c which incorrectly assumes FE_TONEAREST is always defined. Per POSIX, the rounding mode and exception mode constants only need to be supported if they are defined. A check for existence of fenv.h is an insufficient check. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html ../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath/math/x2y2m1q.c:57:26: error: 'FE_TONEAREST' undeclared (first use in this function) 57 | SET_RESTORE_ROUNDF128 (FE_TONEAREST); | ^~~~ This showed up on x86_64 but is likely to show up on all newlib targets which do not have the target specific fenv support. The solution is just to wrap all calls using fenv.h constants with an #ifdef on the constant used as POSIX indicates.
[Bug c/91554] if (!__builtin_constant_p (fn_arg)) warning_function() works in inline when fn_arg is int, not when it is void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554 --- Comment #4 from Zack Weinberg --- (In reply to Richard Biener from comment #3) > I guess you want to use > > __builtin_constant_p (b != 0) > > instead. That wouldn't do what I want. The goal is to warn for any argument _other than_ a compile-time null pointer. `!__builtin_constant_p(b) || b != 0` does just that (it might be easier to understand the De Morgan equivalent `!(__builtin_constant_p(b) && b == 0)`. This is in aid of deprecating the second argument to gettimeofday (see https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=75453bbda865c7d51df39177caef40b16e086dcf#l53 and https://sourceware.org/git/?p=glibc.git;a=blob;f=manual/time.texi;h=cb234bd08fae1841034a2bdccf4e1d246be23034#l557 ). > The docs don't explain what a "constant at compile time" is > so whether for example the address of a global or the address of an > automatic var would be "constant". But I'd say the above incorrectly > disregards the NULL-pointer case. It seems like this code pre-dates tree optimizations, I would suggest removing these lines 8470 || AGGREGATE_TYPE_P (TREE_TYPE (arg)) 8471 || POINTER_TYPE_P (TREE_TYPE (arg)) (and fixing the comment above to match) and seeing if that breaks anything.
[Bug target/91560] New: Try harder for AVX non-AVX2 cross-lane permutations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91560
Bug ID: 91560
Summary: Try harder for AVX non-AVX2 cross-lane permutations
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
On:
typedef float __v8sf __attribute__((vector_size (32)));
typedef double __v4df __attribute__((vector_size (32)));
typedef int __v8si __attribute__((vector_size (32)));
typedef long long __v4di __attribute__((vector_size (32)));
#ifdef __clang__
#define S(x, y, t, ...) __builtin_shufflevector (x, y, __VA_ARGS__)
#else
#define S(x, y, t, ...) __builtin_shuffle (x, y, (t) { __VA_ARGS__ })
#endif
__v8sf f1 (__v8sf x, __v8sf y) { return S (x, y, __v8si, 0, 8, 9, 10, 11, 12,
13, 14 ); }
__v8sf f2 (__v8sf x, __v8sf y) { return S (x, y, __v8si, 0, 1, 8, 9, 10, 11,
12, 13 ); }
__v8sf f3 (__v8sf x, __v8sf y) { return S (x, y, __v8si, 0, 1, 2, 3, 8, 9, 10,
11 ); }
__v8sf f4 (__v8sf x, __v8sf y) { return S (x, y, __v8si, 7, 7, 7, 7, 7, 7, 7, 7
); }
__v4df f5 (__v4df x, __v4df y) { return S (x, y, __v4di, 0, 4, 5, 6 ); }
__v4df f6 (__v4df x, __v4df y) { return S (x, y, __v4di, 0, 1, 4, 5 ); }
__v4df f7 (__v4df x, __v4df y) { return S (x, y, __v4di, 3, 3, 3, 3 ); }
LLVM generates for -O2 -mavx -mno-avx2 shorter code for f1 and f2 (but worse
code for f5), GCC simply gives up for f1/f2 and then expands the shuffle as
lots of BIT_FIELD_REF extractions plus vector creation.
Wonder if ix86_expand_vec_perm_const_1 for the if (TARGET_AVX && !TARGET_AVX2)
and 32-byte vectors shouldn't try harder (though, with rightly estimated
costs).
The above permutations are what is used for OpenMP scans in scan-13.c (and
variant thereof with double instead of float) and reason why we don't vectorize
using 32-byte vectors.
[Bug target/91560] Try harder for AVX non-AVX2 cross-lane permutations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91560 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||uros at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- For f1 clang emits: vpermilps $144, %xmm1, %xmm2 # xmm2 = xmm1[0,0,1,2] vextractf128$1, %ymm1, %xmm3 vblendps$8, %xmm1, %xmm3, %xmm1 # xmm1 = xmm3[0,1,2],xmm1[3] vpermilps $147, %xmm1, %xmm1 # xmm1 = xmm1[3,0,1,2] vinsertf128 $1, %xmm1, %ymm2, %ymm1 vblendps$1, %ymm0, %ymm1, %ymm0 # ymm0 = ymm0[0],ymm1[1,2,3,4,5,6,7] and for f2: vextractf128$1, %ymm1, %xmm2 vshufpd $1, %xmm2, %xmm1, %xmm2 # xmm2 = xmm1[1],xmm2[0] vmovddup%xmm1, %xmm1# xmm1 = xmm1[0,0] vinsertf128 $1, %xmm2, %ymm1, %ymm1 vblendps$3, %ymm0, %ymm1, %ymm0 # ymm0 = ymm0[0,1],ymm1[2,3,4,5,6,7]
[Bug libstdc++/91558] [C++11] should not be constexpr until C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Jonathan Wakely --- (In reply to Yichen Yan from comment #0) > Detail: > Constexpr for is in C++14 if I don't misunderstand. But a lot of > testcases under libstdc++-v3/testsuite/26_numerics/complex/ (e.g. dr844.cc) Are you sure? That test doesn't seem to care about constexpr. > runs with C++11 and check for constexpr (and pass). > > I haven't found some manual or doc explaining that, and wonder if this is a > bug or some feature? The mailing lists are a better place to ask a question like that. Adding constexpr to std::complex was done by r166171 many years ago. I think at the time implementations were allowed to add constexpr as a conforming extension. I don't see a compelling reason to change it now.
[Bug tree-optimization/90970] A suspicious code in builtins.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90970 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-27 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I've got a patch for it.
[Bug libstdc++/91558] [C++11] should not be constexpr until C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558 Jonathan Wakely changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #2 from Jonathan Wakely --- Also, C++11 requires constexpr for the standard specializations, std::complex, std::complex, and std::complex. The effect of instantiating the primary template is unspecified by the standard, so we're allowed to make it constexpr.
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #9 from Martin Liška ---
(In reply to Jason Merrill from comment #8)
> (In reply to Jan Hubicka from comment #2)
> > 2.ii:62:3: warning: ‘ml_bssnrest_’ violates the C++ One Definition Rule
> > [-Wodr]
> >62 | } ml_bssnrest_;
> > | ^
> > 1.ii:2:8: note: type ‘struct ’ defined in anonymous namespace cannot
> > match across the translation unit boundary
> > 2 | struct {
> > |^
> > 2.ii:2:15: note: the incompatible type defined in another translation unit
> > 2 | extern struct {
> > | ^
> > 1.ii:62:3: note: ‘ml_bssnrest_’ was previously declared here
> >62 | } ml_bssnrest_;
> > | ^
> >
> > Now I wonder why C++ FE makes the struct anonymous namespace when it is
> > declared with extern "C".
> > I have checked that type_in_anonymous_namespace_p(prevailing_type) returns
> > true because mangled name is which comes from C++ FE.
> >
> > I will check in the patch to avoid ICE. Jason, can you please look if it is
> > correct to consider these types anonymous?
>
> They aren't in the anonymous namespace, but they are themselves anonymous,
> so they have no linkage. The standard says,
>
> A type without linkage shall not be used as the type of a variable or
> function with external linkage unless
> — the entity has C language linkage (7.5), or
> — the entity is declared within an unnamed namespace (7.3.1), or
> — the entity is not odr-used (3.2) or is defined in the same translation
> unit.
>
> Here 1.ii is OK under the third bullet, and 2.ii under the first bullet.
> Within extern "C" I guess we need to do structural comparison for anonymous
> types rather than rely on the ODR.
Honza?
[Bug c++/90613] [10 Regression] Debug info size increase after r271467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90613 --- Comment #1 from Martin Liška --- @Nathan: May I please remind this?
[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 --- Comment #5 from Martin Liška --- @Richi: Can we close this?
[Bug target/89623] Can't build mips-wrs-vxworks cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89623 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Then let's close this.
[Bug c/89549] [7/8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 --- Comment #10 from Martin Liška --- @David: May I please remind this?
[Bug libstdc++/91558] [C++11] should not be constexpr until C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558 --- Comment #3 from Yichen Yan --- (In reply to Jonathan Wakely from comment #1) > (In reply to Yichen Yan from comment #0) > > Detail: > > Constexpr for is in C++14 if I don't misunderstand. But a lot of > > testcases under libstdc++-v3/testsuite/26_numerics/complex/ (e.g. dr844.cc) > > Are you sure? That test doesn't seem to care about constexpr. Yes, check_ret_type require its template argument and argument to be constexpr. > > runs with C++11 and check for constexpr (and pass). > > > > I haven't found some manual or doc explaining that, and wonder if this is a > > bug or some feature? > > The mailing lists are a better place to ask a question like that. > > Adding constexpr to std::complex was done by r166171 many years ago. I think > at the time implementations were allowed to add constexpr as a conforming > extension. I don't see a compelling reason to change it now. I see. Thanks for your reply.
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #10 from Jan Hubicka --- > > > > They aren't in the anonymous namespace, but they are themselves anonymous, > > so they have no linkage. The standard says, > > > > A type without linkage shall not be used as the type of a variable or > > function with external linkage unless > > — the entity has C language linkage (7.5), or > > — the entity is declared within an unnamed namespace (7.3.1), or > > — the entity is not odr-used (3.2) or is defined in the same translation > > unit. > > > > Here 1.ii is OK under the third bullet, and 2.ii under the first bullet. > > Within extern "C" I guess we need to do structural comparison for anonymous > > types rather than rely on the ODR. > > Honza? In order to disable this for ODR merging, we need to arrange the (already long) TYPE_DECL condition in tree.c:need_assembler_name_p to be false for them or C++ get_assembler_name langhook to return NULL in this case. I wonder how we can arrange that? Honza
[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 --- Comment #6 from Richard Biener --- Hmm, I think I eventually wanted to backport it...
[Bug rtl-optimization/88652] sel-sched.c:1545:11: runtime error: index 2 out of bounds for type 'long unsigned int [2]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88652 --- Comment #5 from Martin Liška --- > > Looks like you're right :) I'll fix that, then. > Any update on this, please?
[Bug target/88617] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11238 since r248029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88617 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- @Daniel: Can you please take a look?
[Bug target/88615] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88615 Martin Liška changed: What|Removed |Added CC||amodra at gcc dot gnu.org, ||gcc-bugzilla at gcc dot gnu.org --- Comment #1 from Martin Liška --- Can you s390x guys take a look?
[Bug lto/88140] [9/10 Regression] ICE: verify_gimple failed since r266325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140 --- Comment #13 from Martin Liška --- @Honza: Can we close this?
[Bug target/88083] ICE in find_constant_pool_ref_1, at config/s390/s390.c:8231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88083 --- Comment #2 from Martin Liška --- @Ilya: Can we close this?
[Bug lto/88081] [7/8/9/10 Regression] ICE in lto_varpool_replace_node, at lto/lto-symtab.c:109
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081 --- Comment #6 from Martin Liška --- @Honza: Reminder.
[Bug c++/69572] [C++11] invalid alignas accepted in many contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69572 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- related/dup: bug 90847
[Bug lto/87501] lto1: error: Alias and target's section differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87501 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org
[Bug c++/69571] [C++11] invalid alignas on a typedef accepted, reduces alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69571 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- related/dup: bug 90847
[Bug lto/88140] [9/10 Regression] ICE: verify_gimple failed since r266325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140 --- Comment #14 from Jan Hubicka --- > @Honza: Can we close this? Array simplification is still disabled - we need to figure how how to represent them...
[Bug lto/87500] ICE in discriminator_for_local_entity, at cp/mangle.c:1967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87500 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed on trunk with r265714. I'm going to close it.
[Bug target/88082] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082 Ilya Leoshkevich changed: What|Removed |Added CC||iii at linux dot ibm.com --- Comment #1 from Ilya Leoshkevich --- Hello Martin, do you per chance remember the failing revision? With r274945 and stable gcc 9.1.1 it seems to work fine: $ ./build/gcc/cc1 gcc/testsuite/c-c++-common/pr59037.c -Os -march=z14 ; echo $? 0 $ gcc-9 gcc/testsuite/c-c++-common/pr59037.c -Os -march=z14 ; echo $? 0
[Bug d/91561] New: [Regression] Internal Compiler Error: type ‘ubyte[]’ can not be mapped to C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91561
Bug ID: 91561
Summary: [Regression] Internal Compiler Error: type ‘ubyte[]’
can not be mapped to C++
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: bugzilla at allegrodvt dot com
Target Milestone: ---
The following code compiles on gdc-8.2 but failed on gdc-9.2:
--
extern(C++) :
alias ubyte[] Array;
class Interface
{
abstract void getArray(ref Array a);
}
void main()
{
}
---
The error is:
error: Internal Compiler Error: type ‘ubyte[]’ can not be mapped to C++
6 | abstract void getArray(ref Array a);
| ^
[Bug target/88082] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082 Martin Liška changed: What|Removed |Added Keywords||needs-bisection Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-27 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- You're right, let me bisect that first.
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #11 from Jason Merrill --- Created attachment 46765 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46765&action=edit clear TYPE_NAME in free_lang_data for anonymous types Perhaps like this?
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #12 from Jan Hubicka --- > Created attachment 46765 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46765&action=edit > clear TYPE_NAME in free_lang_data for anonymous types > > Perhaps like this? It seems that this will disable ODR handling of all anonymous types, not only those declared as "extern C". We make use of the info (by mangling them to ) to handle them during devirtualization and also TBAA. So perhaps we want to be more specific here? Honza
[Bug testsuite/91562] New: [10 regression] gcc.dg/strlenopt-8.c fails starting with r274933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562
Bug ID: 91562
Summary: [10 regression] gcc.dg/strlenopt-8.c fails starting
with r274933
Product: gcc
Version: 10.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: ---
Did this test case get missed when the others were updated?
Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/strlenopt-8.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -fdump-tree-strlen -lm -o ./strlenopt-8.exe
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/strlenopt-8.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -fdump-tree-strlen -lm -o ./strlenopt-8.exe
PASS: gcc.dg/strlenopt-8.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/strlenopt-8.c execution test
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strlen \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strcpy \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strcat \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strchr \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "stpcpy \\(" 0
testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/dg.exp completed in 0
seconds
=== gcc Summary ===
# of expected passes2
# of unresolved testcases 5
[Bug libstdc++/91558] [C++11] should not be constexpr until C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558
--- Comment #4 from Jonathan Wakely ---
(In reply to Yichen Yan from comment #3)
> (In reply to Jonathan Wakely from comment #1)
> > (In reply to Yichen Yan from comment #0)
> > > Detail:
> > > Constexpr for is in C++14 if I don't misunderstand. But a lot of
> > > testcases under libstdc++-v3/testsuite/26_numerics/complex/ (e.g.
> > > dr844.cc)
> >
> > Are you sure? That test doesn't seem to care about constexpr.
>
> Yes, check_ret_type require its template argument and argument to be
> constexpr.
No it doesn't:
template
typename __gnu_cxx::__enable_if::__value,
bool>::__type
check_ret_type(T)
{ return true; }
[Bug c++/91506] Incorrectly issued error: parameter may not have variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-27 Ever confirmed|0 |1
[Bug c++/91563] New: [9 regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563
Bug ID: 91563
Summary: [9 regression] wrong code
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: guillaume at morinfr dot org
Target Milestone: ---
Created attachment 46766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46766&action=edit
test program
Hi,
The attached program aborts with gcc 9.x -O{1,2,3} (including recent version of
the Debian package which has picked recent fixes to the gcc 9 branch). Adding
-fno-strict-aliasing does not make any difference. Full example is uploaded at
https://godbolt.org/z/We99i_
It seems to work correctly with gcc 8.x and the gcc trunk on goldbot.org.
Thank you.
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-27 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #9 from Thomas Koenig --- After r274937, the new flag -fallow-argument-mismatch can also be used. Now, I agree that the error message can be improved - the _formal_... argument names can be improved, it would probably a better idea to refer to the place that the declaration came from in that case. I'll do this, but it will probably be a couple of weeks until I can come up with something - too many things happening in Real Life (TM) at the moment.
[Bug testsuite/91562] [10 regression] gcc.dg/strlenopt-8.c fails starting with r274933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562 --- Comment #1 from Martin Sebor --- Author: msebor Date: Tue Aug 27 16:18:27 2019 New Revision: 274961 URL: https://gcc.gnu.org/viewcvs?rev=274961&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: PR c++/83431 PR testsuite/91562 * gcc.dg/strlenopt-8.c: Adjust pass/dump name. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/strlenopt-8.c
[Bug c++/83431] -Wformat-truncation may incorrectly report truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83431 --- Comment #8 from Martin Sebor --- Author: msebor Date: Tue Aug 27 16:18:27 2019 New Revision: 274961 URL: https://gcc.gnu.org/viewcvs?rev=274961&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: PR c++/83431 PR testsuite/91562 * gcc.dg/strlenopt-8.c: Adjust pass/dump name. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/strlenopt-8.c
[Bug testsuite/91562] [10 regression] gcc.dg/strlenopt-8.c fails starting with r274933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Yes, I must have missed updating the name of the dump. It should be strlen1.
[Bug c++/91563] [9 regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563 --- Comment #1 from Jonathan Wakely --- The program's behaviour is undefined, because memset can't be used for writing to non-trivially copyable types.
[Bug c++/91563] [9 regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563 --- Comment #2 from Jakub Jelinek --- Just a note from bisection, stopped aborting on trunk with r273135, and started to abort in r260318.
[Bug c++/91563] [9 regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563 --- Comment #3 from Guillaume Morin --- Jonathan, Are you sure? I modified the code to print std::is_trivially_copyable::value and it does print "1". Am I missing something obvious?
[Bug fortran/91564] New: [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:14147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91564 Bug ID: 91564 Summary: [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:14147 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects gfortran-8 an higher, has changed before 20180525 : (one argument more than the library-kill) $ cat z1.f90 program p call kill (1, 2, 3) end $ gfortran-7 -c z1.f90 $ $ gfortran-10-20190825 -c z1.f90 z1.f90:2:0: 2 |call kill (1, 2, 3) | internal compiler error: in gimplify_expr, at gimplify.c:14147 0x90827a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14147 0x9110e9 gimplify_modify_expr ../../gcc/gimplify.c:5747 0x906efd gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:13135 0x909c88 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6779 0x907b5b gimplify_statement_list ../../gcc/gimplify.c:1849 0x907b5b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:13579 0x909c88 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6779 0x90a621 gimplify_bind_expr ../../gcc/gimplify.c:1417 0x907c1b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:13336 0x909c88 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6779 0x90a621 gimplify_bind_expr ../../gcc/gimplify.c:1417 0x907c1b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:13336 0x909c88 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6779 0x90b0ca gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:14381 0x90b3b5 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:14525 0x7b9e37 cgraph_node::analyze() ../../gcc/cgraphunit.c:667 0x7bc7f7 analyze_functions ../../gcc/cgraphunit.c:1126 0x7bd152 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2840 $ gfortran-10-20190825-debug -c z1.f90 gimplification failed: 3 constant 3> z1.f90:2:0: 2 |call kill (1, 2, 3) | internal compiler error: gimplification failed 0x9f2a81 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14144 0xa05658 gimplify_modify_expr ../../gcc/gimplify.c:5747 #...
[Bug target/91528] [10 Regression] ICE in ix86_expand_prologue at i386.c:7844 since r274481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528 --- Comment #12 from uros at gcc dot gnu.org --- Author: uros Date: Tue Aug 27 17:23:59 2019 New Revision: 274962 URL: https://gcc.gnu.org/viewcvs?rev=274962&root=gcc&view=rev Log: PR target/91528 * config/i386/i386-features.c (convert_scalars_to_vector): Update crtl->stack_realign_needed, crtl->stack_realign_tried and crtl->stack_realign_processed. Update crtl->drap_reg by calling targetm.calls.get_drap_rtx. If drap_rtx is non-null then Update crtl->args.internal_arg_pointer and call fixup_tail_calls. testsuite/ChangeLog: PR target/91528 * gcc.target/i386/pr91528.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr91528.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-features.c trunk/gcc/testsuite/ChangeLog
[Bug target/91528] [10 Regression] ICE in ix86_expand_prologue at i386.c:7844 since r274481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #13 from Uroš Bizjak --- Fixed.
[Bug fortran/91565] New: [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565 Bug ID: 91565 Summary: [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc. Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- ICE hits gfortran-8 and higher - this changed just before 20180525. Starting with correct code z0.f90, then providing wrong orders (accepted up to gfortran-7) : $ cat z0.f90 program p integer, parameter :: a(2) = [2,1] print *, reshape([1,2,3,4,5,6], [2,3], order=a) end $ gfortran-10 z0.f90 && ./a.out 1 4 2 5 3 6 $ cat z1.f90 # not a permutation program p integer, parameter :: a(2) = [2,2] print *, reshape([1,2,3,4,5,6], [2,3], order=a) end $ cat z2.f90 # size of order and shape differs program p integer, parameter :: a(1) = 1 print *, reshape([1,2,3,4,5,6], [2,3], order=a) end $ cat z3.f90 # shape of order and shape differs program p integer, parameter :: a(1,2) = 1 print *, reshape([1,2,3,4,5,6], [2,3], order=a) end $ gfortran-7 z3.f90 && ./a.out 1 3 4 -1 0 0 $ $ gfortran-10-20190825 -c z1.f90 f951: internal compiler error: in gfc_simplify_reshape, at fortran/simplify.c:6707 0x6a6a99 gfc_simplify_reshape(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.c:6707 0x62ef5b do_simplify ../../gcc/fortran/intrinsic.c:4556 0x6395ee gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:4931 0x6907a1 resolve_unknown_f ../../gcc/fortran/resolve.c:2896 0x6907a1 resolve_function ../../gcc/fortran/resolve.c:3233 0x68ce2d gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6951 0x684e5b gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11416 0x694fbf gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10460 0x684fe9 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11406 0x687ca7 resolve_codes ../../gcc/fortran/resolve.c:16921 0x687d6e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16956 0x67581c resolve_all_program_units ../../gcc/fortran/parse.c:6073 0x67581c gfc_parse_file() ../../gcc/fortran/parse.c:6320 0x6bf60f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/91566] New: [9/10 Regression] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91566 Bug ID: 91566 Summary: [9/10 Regression] ICE in gfc_constructor_copy, at fortran/constructor.c:103 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20180624 and 20180708 : $ cat z1.f90 program p print *, -merge([3,4], 0, [.false.,.true.]) end $ cat z2.f90 program p print *, 2 + merge([3,4], 0, [.false.,.true.]) end $ gfortran-9-20180624 z1.f90 && ./a.out 0 -4 $ gfortran-10-20190825 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb3acef crash_signal ../../gcc/toplev.c:326 0x13f7bac splay_tree_foreach ../../libiberty/splay-tree.c:577 0x5fe5f4 gfc_constructor_copy(splay_tree_s*) ../../gcc/fortran/constructor.c:103 0x5e5cab reduce_unary ../../gcc/fortran/arith.c:1267 0x5e5ccf reduce_unary ../../gcc/fortran/arith.c:1270 0x5e651f eval_intrinsic ../../gcc/fortran/arith.c:1609 0x620307 simplify_intrinsic_op ../../gcc/fortran/expr.c:1180 0x620307 gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2198 0x68d4e6 resolve_operator ../../gcc/fortran/resolve.c:4310 0x68d4e6 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6944 0x684e5b gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11416 0x694fbf gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10460 0x684fe9 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11406 0x687ca7 resolve_codes ../../gcc/fortran/resolve.c:16921 0x687d6e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16956 0x67581c resolve_all_program_units ../../gcc/fortran/parse.c:6073 0x67581c gfc_parse_file() ../../gcc/fortran/parse.c:6320 0x6bf60f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug tree-optimization/91567] New: [10 Regression] Spurious -Wformat-overflow warnings building glibc (32-bit only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567
Bug ID: 91567
Summary: [10 Regression] Spurious -Wformat-overflow warnings
building glibc (32-bit only)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
r274933 ("PR tree-optimization/83431 - -Wformat-truncation may incorrectly
report truncation") introduced spurious -Wformat-truncation warnings on the
following code, built with -O2 -Wall, for 32-bit systems only (e.g. x86_64 -m32
or -mx32 but not -m64). This is reduced from a build failure building glibc
for such systems with GCC trunk.
void f (char *);
void
g (char *s1, char *s2)
{
char b[1025];
__SIZE_TYPE__ n = __builtin_strlen (s1), d = __builtin_strlen (s2);
if (n + d + 1 >= 1025)
return;
__builtin_sprintf (b, "%s.%s", s1, s2);
f (b);
}
t.c: In function 'g':
t.c:9:26: warning: '%s' directive writing up to 2147483645 bytes into a region
of size 1025 [-Wformat-overflow=]
9 | __builtin_sprintf (b, "%s.%s", s1, s2);
| ^~
t.c:9:3: note: '__builtin_sprintf' output between 2 and 4294967292 bytes into a
destination of size 1025
9 | __builtin_sprintf (b, "%s.%s", s1, s2);
| ^~
[Bug tree-optimization/91568] New: internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91568 Bug ID: 91568 Summary: internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922 Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wala1 at illinois dot edu Target Milestone: --- Created attachment 46767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46767&action=edit helmrouts3d.f file causing internal compile error Hi, The attached file leads to an internal compile error when compiled as follows: $ gfortran -Wall -g -ffixed-form -fno-second-underscore -fPIC -std=legacy -Ofast -fopenmp helmrouts3d.f ... during GIMPLE pass: vect helmrouts3d.f:717:0: 717 | subroutine h3dall(nterms,z,scale,hvec,ifder,hder) | internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922 0x7f249db9c09a __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. Version: $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-4' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 9.2.1 20190821 (Debian 9.2.1-4)
[Bug tree-optimization/91568] internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91568 --- Comment #1 from Matt Wala --- Created attachment 46768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46768&action=edit Full compiler output
[Bug c++/91506] Incorrectly issued error: parameter may not have variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r166167.
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #13 from Jason Merrill --- Ah, I was reading the passage a bit wrong: where the extern "C" matters is not on the type, but on the variable (ml_bssnrest_). Because it's extern "C", declarations in different translation units correspond even though we can't use the same type in both. But that still doesn't make the types the same, and the use of the variable in 2.ii has undefined behavior because it is accessing the value of the object through the wrong type, so the warning is correct. We may want to allow it anyway for C compatibility. Thoughts?
