[Bug c++/91590] ICE in : canonical types differ for identical types std::enable_if::ViewConcept< >()> and std::enable_if::ViewConcept< >()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91590 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-02 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/53075] -Werror=pedantic should be equivalent to -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53075 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53072 --- Comment #3 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #0) > Some background discussion in PR 44774 and > http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01324.html bug 53072 came up under that discussion; adding it under "See Also" here > > A currently visible effect is that > > $ cc1 ~/trunk/src/gcc/testsuite/gcc.dg/c90-init-1.c -pedantic-errors > > prints -Wpedantic while > > $ cc1 ~/trunk/src/gcc/testsuite/gcc.dg/c90-init-1.c -Werror=pedantic > > prints -Werror=pedantic (as it should).
[Bug tree-optimization/91625] FAIL: gcc.dg/strlenopt-68.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91625
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
What does the optimized dump look like for function equal_4_gs0_gs3_ga5_0?
I see the same code with an hppa64-hp-hpux11.11 cross as with a native
x86_64-linux compiler so I can't imagine what about it might cause the
assertion to fail except the result returned from the library call:
[local count: 1073741824]:
# iftmp.2_2 = PHI <(2), (3), (4)>
_1 = snprintf (0B, 0, "%s", iftmp.2_2);
if (_1 != 4)
goto ; [0.04%]
else
goto ; [99.96%]
[local count: 429497]:
__builtin_printf ("assertion failed on line %i: %s\n", 41, "snprintf (0, 0,
\"%s\", p) == 4");
__builtin_abort ();
What value does the function return at runtime?
[Bug c++/91129] [9 Regression] Implicit casts fail for modulo operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91129 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug c++/91129] [9 Regression] Implicit casts fail for modulo operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91129 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Sun Sep 1 22:59:10 2019 New Revision: 275286 URL: https://gcc.gnu.org/viewcvs?rev=275286=gcc=rev Log: PR c++/91129 - wrong error with binary op in template argument. * typeck.c (warn_for_null_address): Use fold_for_warn instead of fold_non_dependent_expr. (cp_build_binary_op): Likewise. * g++.dg/cpp1y/nontype1.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/nontype1.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/typeck.c
[Bug c++/91129] [9 Regression] Implicit casts fail for modulo operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91129 Marek Polacek changed: What|Removed |Added Summary|[9/10 Regression] Implicit |[9 Regression] Implicit |casts fail for modulo |casts fail for modulo |operator|operator --- Comment #4 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/91129] [9/10 Regression] Implicit casts fail for modulo operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91129 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Sun Sep 1 22:54:15 2019 New Revision: 275285 URL: https://gcc.gnu.org/viewcvs?rev=275285=gcc=rev Log: PR c++/91129 - wrong error with binary op in template argument. * typeck.c (warn_for_null_address): Use fold_for_warn instead of fold_non_dependent_expr. (cp_build_binary_op): Likewise. * g++.dg/cpp1y/nontype1.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/nontype1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/91631] buffer overflow into an array member of a declared object not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91631 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-01 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0, 7.3.0, 8.3.0, 9.2.0 --- Comment #1 from Martin Sebor --- Testing a patch.
[Bug middle-end/91631] New: buffer overflow into an array member of a declared object not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91631
Bug ID: 91631
Summary: buffer overflow into an array member of a declared
object not detected
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Even with -D_FORTIFY_SOURCE=2 GCC diagnoses only two out of the six instances
of buffer overflow in the strcpy calls below.
$ cat a.c && gcc -D_FORTIFY_SOURCE=2 -O2 -S -Wall -Wextra -Wpedantic a.c
#include
struct S { char a[3], b[5], c[]; };
extern struct S es[];
static struct S is[2];
void efa (void)
{
char a[] = "123";
strcpy (es[0].a, a); // missing warning
}
void efb (void)
{
char a[] = "12345";
strcpy (es[0].b, a); // missing warning
}
void efc (void)
{
char a[] = "123";
strcpy (es[0].c, a); // missing warning
}
void ifa (void)
{
char a[] = "123";
strcpy (is[0].a, a); // warning (good)
}
void ifb (void)
{
char a[] = "12345";
strcpy (is[0].b, a); // warning (good)
}
void ifc (void)
{
char a[] = "123";
strcpy (is[0].c, a); // missing warning
}
a.c:5:17: warning: invalid use of structure with flexible array member
[-Wpedantic]
5 | extern struct S es[];
| ^~
a.c:6:17: warning: invalid use of structure with flexible array member
[-Wpedantic]
6 | static struct S is[2];
| ^~
In file included from /usr/include/string.h:494,
from a.c:1:
In function ‘strcpy’,
inlined from ‘ifa’ at a.c:29:3:
/usr/include/bits/string_fortified.h:90:10: warning: ‘__builtin___memcpy_chk’
writing 4 bytes into a region of size 3 overflows the destination
[-Wstringop-overflow=]
90 | return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
| ^~
In function ‘strcpy’,
inlined from ‘ifb’ at a.c:35:3:
/usr/include/bits/string_fortified.h:90:10: warning: ‘__builtin___memcpy_chk’
writing 6 bytes into a region of size 5 overflows the destination
[-Wstringop-overflow=]
90 | return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
| ^~
[Bug tree-optimization/82645] missing -Wstringop-overflow on strncpy overflowing a member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82645 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||8.1.0 Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |8.4 Known to fail|8.0 | --- Comment #1 from Martin Sebor --- This was fixed via r254630 in GCC 8: PR c/81117 - Improve buffer overflow checking in strncpy.
[Bug libstdc++/88204] New test case 26_numerics/complex/operators/more_constexpr.cc from r266416 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88204 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Sandoe --- also fixed on Darwin.
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 --- Comment #22 from Thomas Koenig --- A problem with such code is that type violations like that are likely to cause actual wrong code issues because much of the aliasing analysis is type based... What I could do is to a) restrict the number of warnings for each routine to one (put a flag Into the gsym) b) try to figure something out to make this harmless to the middle end... like passing a void* instead of a reference. If we just continue to ignore this error, is is going to bite people sooner or later. And wehn somevody finds that a complex MPI code no longer works, I want to have that warning in the build log. Also, this sort of code is a major obstacle for LTO, If we do not fix this, then I might as well give up on making gfortran LTO clean.
[Bug objc/90709] [meta-bug] GNU Objective C (C++) cannot consume current headers on Darwin platforms.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90709 --- Comment #8 from Iain Sandoe --- Author: iains Date: Sun Sep 1 19:30:35 2019 New Revision: 275281 URL: https://gcc.gnu.org/viewcvs?rev=275281=gcc=rev Log: [objective-c/c++, testsuite] Workaround for PR90709. Since we cannot parse the current NeXT headers, because of PR90709 and its dependents, we have a large amount of testsuite noise for Darwin platforms. In order to restore the usefulness of the testsuite, we are going add headers without the modern syntax elements that trigger the bug, and use these for test runs on newer Darwin. The headers are imported from GNUStep, with some local modifications to make sure that __BLOCKS__ is honoured as a gate for Apple-style blocks closures. CF-CFString.h, F-NS*.h are proxy headers that use the installed CoreFoundation or Foundation headers on systems <= Darwin12 and the GNUStep headers for newer. Use the CF-CFString.h, F-NS*.h proxy headers where needed in the objective-c testsuite. Make minor adjustments to tests as required, providing that those do not alter the test intent. 2019-09-01 Iain Sandoe Backport from mainline. 2019-06-15 Iain Sandoe PR objc/90709 * obj-c++.dg/proto-lossage-7.mm: Use proxy headers. * obj-c++.dg/strings/const-cfstring-2.mm: Likewise. * obj-c++.dg/strings/const-cfstring-5.mm: Likewise * obj-c++.dg/strings/const-str-12.mm: Likewise. * obj-c++.dg/syntax-error-1.mm: Likewise. * obj-c++.dg/torture/strings/const-cfstring-1.mm: Likewise. * obj-c++.dg/torture/strings/const-str-10.mm: Likewise. * obj-c++.dg/torture/strings/const-str-11.mm: Likewise. * obj-c++.dg/torture/strings/const-str-9.mm: Likewise. * obj-c++.dg/cxx-ivars-3.mm: Skip on later Darwin, where the 10.4 API in no longer supported, also on m64 where there's no meaning to it. * obj-c++.dg/isa-field-1.mm: Suppress unwanted warning, add comment why. * obj-c++.dg/objc-gc-3.mm: Skip for Darwin > 16, the API use is an error there. * obj-c++.dg/qual-types-1.mm: Prune a spurious l64 warning. * obj-c++.dg/stubify-1.mm: Tidy up after better compiler warnings. * obj-c++.dg/stubify-2.mm: Likewise. * obj-c++.dg/try-catch-1.mm: Likewise. * obj-c++.dg/try-catch-3.mm: Likewise. Backport from mainline. 2019-06-15 Iain Sandoe PR objc/90709 * objc.dg/encode-7-next-64bit.m: Use proxy headers. * objc.dg/image-info.m: Likewise. * objc.dg/method-6.m: Likewise. * objc.dg/no-extra-load.m: Likewise. * objc.dg/objc-foreach-4.m: Likewise. * objc.dg/objc-foreach-5.m: Likewise. * objc.dg/proto-lossage-7.m: Likewise. * objc.dg/strings/const-cfstring-2.m: Likewise. * objc.dg/strings/const-cfstring-5.m: Likewise. * objc.dg/strings/const-str-12b.m: Likewise. * objc.dg/symtab-1.m: Likewise. * objc.dg/torture/strings/const-cfstring-1.m: Likewise. * objc.dg/torture/strings/const-str-10.m: Likewise. * objc.dg/torture/strings/const-str-11.m: Likewise. * objc.dg/torture/strings/const-str-9.m: Likewise. * objc.dg/zero-link-1.m: Likewise. * objc.dg/zero-link-2.m: Likewise. * objc.dg/zero-link-3.m: Likewise. * objc.dg/isa-field-1.m: Suppress unwanted warning, add comment why. * objc.dg/headers.m: XFAIL for Darwin14-19. * objc.dg/objc-gc-4.m: Skip for Darwin > 16, the API use is an error there. Backport from mainline. 2019-06-15 Iain Sandoe PR objc/90709 * objc-obj-c++-shared/CF-CFString.h: New. * objc-obj-c++-shared/F-NSArray.h: New. * objc-obj-c++-shared/F-NSAutoreleasePool.h: New. * objc-obj-c++-shared/F-NSObject.h: New. * objc-obj-c++-shared/F-NSString.h: New. * objc-obj-c++-shared/F-NSValue.h: New. * objc-obj-c++-shared/GNUStep/CoreFoundation/CFArray.h: New. * objc-obj-c++-shared/GNUStep/CoreFoundation/CFAvailability.h: New. * objc-obj-c++-shared/GNUStep/CoreFoundation/CFBase.h: New. * objc-obj-c++-shared/GNUStep/CoreFoundation/CFCharacterSet.h: New. * objc-obj-c++-shared/GNUStep/CoreFoundation/CFData.h: New. * objc-obj-c++-shared/GNUStep/CoreFoundation/CFDictionary.h: New. * objc-obj-c++-shared/GNUStep/CoreFoundation/CFLocale.h: New. * objc-obj-c++-shared/GNUStep/CoreFoundation/CFString.h: New. * objc-obj-c++-shared/GNUStep/Foundation/NSArray.h: New. * objc-obj-c++-shared/GNUStep/Foundation/NSAutoreleasePool.h: New. * objc-obj-c++-shared/GNUStep/Foundation/NSDate.h: New. * objc-obj-c++-shared/GNUStep/Foundation/NSEnumerator.h: New. * objc-obj-c++-shared/GNUStep/Foundation/NSGeometry.h: New. * objc-obj-c++-shared/GNUStep/Foundation/NSObjCRuntime.h: New. *
[Bug gcov-profile/91087] g++.dg/gcov/pr16855.C fails everywhere on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91087
--- Comment #5 from Iain Sandoe ---
Author: iains
Date: Sun Sep 1 19:17:16 2019
New Revision: 275279
URL: https://gcc.gnu.org/viewcvs?rev=275279=gcc=rev
Log:
[Darwin, testsuite] Address PR91087 - XFAIL parts of pr16855.C.
The testcase is failing to instrument part of the source because of a bug
in the ordering of static DTORs. It seems unlikely that this is generically
fixable in the toolchain (and given that it's likely to be a dynamic loader
change would not be expected to be applied retrospectively to OS versions
that are out of support). To avoid the testsuite noise, xfail the count lines
that don't match (we can adjust the xfails as/when the upstream bug is fixed).
dejagnu xfails do not seem to work when embedded in a line like:
~Test (void) { /* count(1) { xfail ... } */ }
the closing brace seems to confuse the parser. The solution is to exapnd the
text onto three lines.
2019-09-01 Iain Sandoe
Backport from mainline.
2019-07-25 Iain Sandoe
PR gcov-profile/91087
* g++.dg/gcov/pr16855.C: Xfail the count lines for the DTORs and the
"final" line for the failure summaries. Adjust source layout so that
dejagnu xfail expressions work.
Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/g++.dg/gcov/pr16855.C
[Bug tree-optimization/90020] [7 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020 --- Comment #22 from Iain Sandoe --- Author: iains Date: Sun Sep 1 18:57:42 2019 New Revision: 275276 URL: https://gcc.gnu.org/viewcvs?rev=275276=gcc=rev Log: [Darwin, testsuite] Backport fix for fails of pr90020.c. To allow weak references to be undefined at link-time, Darwin needs -Wl,-undefined,dynamic_lookup. For them to work at runtime on older, Darwin versions, the lookup needs to use 'flat' namespace (i.e. ignore the two-level library naming). 2019-09-01 Iain Sandoe Backport from mainline. 2019-04-15 Dominique d'Humieres PR tree-optimization/90020 * gcc.dg/torture/pr90020.c: Add linker options for Darwin. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr90020.c
[Bug c++/85125] constant expression with const_cast UB does not emit error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85125 --- Comment #7 from John McFarlane --- Confirmed. Thank you! On Mon, 19 Aug 2019 at 15:02, mpolacek at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85125 > > Marek Polacek changed: > >What|Removed |Added > > > Status|ASSIGNED|RESOLVED > Resolution|--- |FIXED > > --- Comment #6 from Marek Polacek --- > Done for 10.1 via: > > Author: mpolacek > Date: Mon Aug 19 13:59:13 2019 > New Revision: 274671 > > URL: https://gcc.gnu.org/viewcvs?rev=274671=gcc=rev > Log: > PR c++/91264 - detect modifying const objects in constexpr. > * constexpr.c (modifying_const_object_error): New function. > (cxx_eval_call_expression): Set TREE_READONLY on a CONSTRUCTOR of > a const-qualified object after it's been fully constructed. > (modifying_const_object_p): New function. > (cxx_eval_store_expression): Detect modifying a const object > during constant expression evaluation. > (cxx_eval_increment_expression): Use a better location when > building > up the store. > (cxx_eval_constant_expression) : Mark a constant > object's constructor TREE_READONLY. > > * g++.dg/cpp1y/constexpr-tracking-const1.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const2.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const3.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const4.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const5.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const6.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const7.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const8.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const9.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const10.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const11.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const12.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const13.C: New test. > * g++.dg/cpp1y/constexpr-tracking-const14.C: New test. > > Added: > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const1.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const10.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const11.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const12.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const13.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const14.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const2.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const3.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const4.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const5.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const6.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const7.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const8.C > trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const9.C > Modified: > trunk/gcc/cp/ChangeLog > trunk/gcc/cp/constexpr.c > trunk/gcc/testsuite/ChangeLog > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug.
[Bug fortran/91589] [9/10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91589 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-01 CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paul Thomas --- This was my match for inquiry references r265729. I'll take it Paul
[Bug other/55930] [7/8/9/10 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #15 from Eric Gallager ---
(In reply to Stephen Kitt from comment #14)
> (In reply to Andrew Pinski from comment #5)
> > But the bigger question is why are you passing
> > --disable-dependency-tracking
> > ?
>
> I ran into this issue because Debian's debhelper's dh_auto_configure passes
> --disable-dependency-tracking automatically. ("Know your build tools" is the
> lesson here, I guess.)
There's other projects that automatically turn on
--disable-dependency-tracking, too. MacPorts automatically passes
--disable-dependency-tracking for all ports using the +universal variant, for
example.
[Bug lto/91626] [9/10 Regression] FAIL: gcc.dg/lto/pr48622 c_lto_pr48622_0.o-c_lto_pr48622_0.o link, -O -flto -finline-small-functions -fno-early-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91626 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Status|WAITING |ASSIGNED Known to work||8.3.0 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Summary|FAIL: gcc.dg/lto/pr48622|[9/10 Regression] FAIL: |c_lto_pr48622_0.o-c_lto_pr4 |gcc.dg/lto/pr48622 |8622_0.o link, -O -flto |c_lto_pr48622_0.o-c_lto_pr4 |-finline-small-functions|8622_0.o link, -O -flto |-fno-early-inlining |-finline-small-functions ||-fno-early-inlining Known to fail||10.0, 9.2.0
[Bug middle-end/91623] [7/8/9 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 --- Comment #6 from Marc Glisse --- For the missed constant folding, it seems that we end up in fold_vec_perm, with type a vector of "long long", while arg0 and arg1 are vectors of "long", and we give up because of the early check "TREE_TYPE (TREE_TYPE (arg0)) != TREE_TYPE (type)". I don't know if the check should be relaxed, or if the bug is earlier and we shouldn't have reached this place with such different types...
[Bug lto/91626] FAIL: gcc.dg/lto/pr48622 c_lto_pr48622_0.o-c_lto_pr48622_0.o link, -O -flto -finline-small-functions -fno-early-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91626 --- Comment #4 from John David Anglin --- Test fails first in r263988.
[Bug lto/91626] FAIL: gcc.dg/lto/pr48622 c_lto_pr48622_0.o-c_lto_pr48622_0.o link, -O -flto -finline-small-functions -fno-early-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91626 --- Comment #3 from John David Anglin --- Created attachment 46796 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46796=edit Difference in gcc-dg-lto-pr48622-01.exe.ltrans0.s between r263987 and r263988 The hppa64-hp-hpux11.11 target is always PIC.
[Bug lto/91572] [9 Regression] lto1: error: type variant has different ‘TREE_TYPE’ since r269862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91572 Jakub Jelinek changed: What|Removed |Added Known to work||10.0 Summary|[9/10 Regression] lto1: |[9 Regression] lto1: error: |error: type variant has |type variant has different |different ‘TREE_TYPE’ since |‘TREE_TYPE’ since r269862 |r269862 | Known to fail|10.0| --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/91623] [7/8/9 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9/10 Regression] |[7/8/9 Regression] -msse4.1 |-msse4.1 -O3 segfault in|-O3 segfault in |/usr/lib/gcc/x86_64-pc-linu |/usr/lib/gcc/x86_64-pc-linu |x-gnu/8.3.0/include/smmintr |x-gnu/8.3.0/include/smmintr |in.h:270:10 |in.h:270:10 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/91472] [8/9/10 Regression] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Eric Botcazou --- This should be fixed now.
[Bug target/91472] [8/9/10 Regression] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 --- Comment #9 from Eric Botcazou --- Author: ebotcazou Date: Sun Sep 1 12:59:09 2019 New Revision: 275273 URL: https://gcc.gnu.org/viewcvs?rev=275273=gcc=rev Log: PR target/91472 * config/sparc/sparc.c (sparc_cannot_force_const_mem): Return true during LRA/reload in PIC mode if the PIC register hasn't been used yet. (sparc_pic_register_p): Test reload_in_progress for consistency's sake. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/20190901-1.c - copied unchanged from r275271, trunk/gcc/testsuite/gcc.c-torture/execute/20190901-1.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/sparc/sparc.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug target/91472] [8/9/10 Regression] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 --- Comment #8 from Eric Botcazou --- Author: ebotcazou Date: Sun Sep 1 12:57:56 2019 New Revision: 275272 URL: https://gcc.gnu.org/viewcvs?rev=275272=gcc=rev Log: PR target/91472 * config/sparc/sparc.c (sparc_cannot_force_const_mem): Return true during LRA/reload in PIC mode if the PIC register hasn't been used yet. (sparc_pic_register_p): Test reload_in_progress for consistency's sake. Added: branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/20190901-1.c - copied unchanged from r275271, trunk/gcc/testsuite/gcc.c-torture/execute/20190901-1.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/sparc/sparc.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug target/91472] [8/9/10 Regression] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Sun Sep 1 12:55:22 2019 New Revision: 275270 URL: https://gcc.gnu.org/viewcvs?rev=275270=gcc=rev Log: PR target/91472 * config/sparc/sparc.c (sparc_cannot_force_const_mem): Return true during LRA/reload in PIC mode if the PIC register hasn't been used yet. (sparc_pic_register_p): Test reload_in_progress for consistency's sake. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20190901-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/91623] [7/8/9/10 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Sun Sep 1 11:57:10 2019 New Revision: 275267 URL: https://gcc.gnu.org/viewcvs?rev=275267=gcc=rev Log: PR middle-end/91623 * optabs.c (expand_vec_cond_expr): If op0 is a VECTOR_CST and only EQ_EXPR/NE_EXPR is supported, verify that op0 only contains zeros or negative elements and use NE_EXPR instead of LT_EXPR against zero vector. * gcc.target/i386/pr91623.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr91623.c Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog
[Bug lto/91572] [9/10 Regression] lto1: error: type variant has different ‘TREE_TYPE’ since r269862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91572 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Sun Sep 1 11:56:13 2019 New Revision: 275266 URL: https://gcc.gnu.org/viewcvs?rev=275266=gcc=rev Log: PR lto/91572 * tree.c (find_decls_types_in_node): Also walk TREE_PURPOSE of GIMPLE_ASM TREE_LIST operands. * g++.dg/lto/pr91572_0.C: New test. Added: trunk/gcc/testsuite/g++.dg/lto/pr91572_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154 --- Comment #37 from rguenther at suse dot de --- On September 1, 2019 12:05:52 PM GMT+02:00, ubizjak at gmail dot com wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154 > >--- Comment #36 from Uroš Bizjak --- >(In reply to Richard Biener from comment #30) > >> Hmm, it regresses the gcc.target/i386/minmax-6.c though and thus >cactusADM >> (IIRC). > >I was looking a bit into minmax6.c failure. Apparently, despite >spill/fill >cactusADM doesn't regress [1]. By avoiding subregs, spill and fill are >both in >V4SImode, so store forwarding mitigates the effects of memory access. >Thus, the >current testsuite failure is benign, and scan-asm-not should be >adjusted to >only check for SImode spill. > >OTOH, spill in SImode (32bit) and fill in V4SImode (128 bit), which is >the >consequence of using V4SImode paradoxical subreg of SImode value >disables store >forwarding and a big runtime regression in a hot loop is observed. Yeah, that might very well be the original issue. Still reg, xmm moves should be better so not sure if we should adjust the testcase. Maybe we can make two of them and assert we don't see the SImode spill with any tuning? >Based on this observation, your approach of using special patterns to >convert >SImode to V4SImode is the correct approach, and I retract my patch that >reintroduces subregs instead. > >[1] >https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/436_cactusADM_recent_big.png
[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154 --- Comment #36 from Uroš Bizjak --- (In reply to Richard Biener from comment #30) > Hmm, it regresses the gcc.target/i386/minmax-6.c though and thus cactusADM > (IIRC). I was looking a bit into minmax6.c failure. Apparently, despite spill/fill cactusADM doesn't regress [1]. By avoiding subregs, spill and fill are both in V4SImode, so store forwarding mitigates the effects of memory access. Thus, the current testsuite failure is benign, and scan-asm-not should be adjusted to only check for SImode spill. OTOH, spill in SImode (32bit) and fill in V4SImode (128 bit), which is the consequence of using V4SImode paradoxical subreg of SImode value disables store forwarding and a big runtime regression in a hot loop is observed. Based on this observation, your approach of using special patterns to convert SImode to V4SImode is the correct approach, and I retract my patch that reintroduces subregs instead. [1] https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/436_cactusADM_recent_big.png
[Bug target/91615] [10 regression][armeb] ICEs since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615 --- Comment #3 from Bernd Edlinger --- yes that looks very likely. I was not able to reproduce this particular failure, but you can try out the patch I attached to pr91612 and see if it fixes you problem. I am currently short of test capability and cannot post the patch before I have done another bootstrap/regtest cycle.
[Bug libstdc++/91630] New: std::any SFINAE breaks valid code since 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91630
Bug ID: 91630
Summary: std::any SFINAE breaks valid code since 9.1
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alabuzhev at hotmail dot com
Target Milestone: ---
The following code compiles fine with 8.3, but not with 9.1 or later:
#include
template
class wrapper
{
public:
wrapper() = default;
// Change to 0 to make it work
#if 1
wrapper(const T& t)
{
// To make sure it's not instantiated
static_assert(!sizeof(t));
value = t;
}
#endif
wrapper(const wrapper& w)
{
// To make sure it's not instantiated
static_assert(!sizeof(w));
value = w.value;
}
auto& operator=(const T& t)
{
// To make sure it's not instantiated
static_assert(!sizeof(t));
value = t;
return *this;
}
auto& operator=(const wrapper& w)
{
value = w.value;
return *this;
}
private:
T value;
};
int main()
{
wrapper a, b;
a = b;
}
See compiler explorer demo:
https://godbolt.org/z/q3o0TX
[Bug target/91615] [10 regression][armeb] ICEs since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #2 from David Binderman --- I am not sure if this is related or not, but for a raspberry pi cross compiler (arm-linux-gnueabihf) and gcc/testsuite file gcc.dg/vect/pr57558-2.c, it seems to compile ok at -O2, but not at -O3: ./gcc.dg/vect/pr57558-2.c during RTL pass: expand ./gcc.dg/vect/pr57558-2.c: In function ‘foo’: ./gcc.dg/vect/pr57558-2.c:9:13: internal compiler error: in gen_movdi, at config/arm/arm.md:5257 9 | a[i] = a[i+1]; |~^ 0x768aef gen_movdi(rtx_def*, rtx_def*) /home/dcb/gcc/trunk/gcc/config/arm/arm.md:5257 0xa3a5b7 insn_gen_fn::operator()(rtx_def*, rtx_def*) const /home/dcb/gcc/trunk/gcc/recog.h:318 0xa3a5b7 emit_move_insn_1(rtx_def*, rtx_def*) /home/dcb/gcc/trunk/gcc/expr.c:3694 0xa3a98c emit_move_insn(rtx_def*, rtx_def*) /home/dcb/gcc/trunk/gcc/expr.c:3790
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #18 from Florian Weimer --- I'm going to request a CVE ID for this.
