[Bug middle-end/84034] [6/7/8 Regression] incomplete warning message with dos line endings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84034 --- Comment #3 from Bernd Edlinger --- Author: edlinger Date: Sat Jan 27 06:44:25 2018 New Revision: 257120 URL: https://gcc.gnu.org/viewcvs?rev=257120&root=gcc&view=rev Log: 2018-01-27 Bernd Edlinger PR diagnostic/84034 * diagnostic-show-locus.c (get_line_width_without_trailing_whitespace): Handle CR like TAB. (layout::print_source_line): Likewise. (test_get_line_width_without_trailing_whitespace): Add test cases. Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-show-locus.c
[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84040 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84040 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Sat Jan 27 06:28:15 2018 New Revision: 257119 URL: https://gcc.gnu.org/viewcvs?rev=257119&root=gcc&view=rev Log: PR middle-end/84040 * sched-deps.c (sched_macro_fuse_insns): Return immediately for debug insns. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c
[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82994 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- I have a patch.
[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746 --- Comment #9 from dave.anglin at bell dot net --- On 2018-01-26 8:29 PM, dominiq at lps dot ens.fr wrote: > By the xfail? Can the PR be closed? I'll have to investigate...
[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746 --- Comment #8 from Dominique d'Humieres --- > I don't have a recent gcc-6 set of test results but the bug is fixed in > gcc-7 and gcc-8. By the xfail? Can the PR be closed?
[Bug libstdc++/58931] condition_variable::wait_until overflowed by large time_point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58931 --- Comment #5 from Aaron Graham --- Created attachment 43261 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43261&action=edit Patch to check for overflow
[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746 --- Comment #7 from dave.anglin at bell dot net --- I don't have a recent gcc-6 set of test results but the bug is fixed in gcc-7 and gcc-8.
[Bug c++/83342] extern marked variable template with later definition emits error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83342 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-27 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.2.0, 8.0 --- Comment #1 from Martin Sebor --- Confirmed with the following simplified test case. As noted, other compilers including Clang, EDG eccp 4.13, ICC 18, and MSVC accept the code. $ cat t.C && gcc -O2 -S -Wall t.C template extern const int N; template const int N = sizeof(T); template const int N; t.C: In instantiation of ‘const int N’: t.C:7:20: required from here t.C:7:20: error: explicit instantiation of ‘N’ but no definition available [-fpermissive] template const int N; ^~
[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Dominique d'Humieres --- What is the status of this PR?
[Bug fortran/66833] ICE on assumed-rank character actual argument to intrinsic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66833 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Summary|[4.9/5.1/6.0]: ICE on |ICE on assumed-rank |assumed-rank character |character actual argument |actual argument to |to intrinsic functions |intrinsic functions | --- Comment #2 from Dominique d'Humieres --- ICE seen with 4.8 up to trunk (8.0).
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #11) > (In reply to Ben Woodard from comment #10) > > Also note: > > https://connect.microsoft.com/VisualStudio/feedback/details/742775 > > > > My reading of: > > https://wg21.link/lwg2381 > > > > is that if the first part of the number includes a '.' then the portion > > after the 'p' or 'P' is not part of the number and is left in the string. > > The example is > > 0x1a.bp+07p > > > > So I believe that your assertion that 2381 applies in this situation is not > > accurate. This example refers to the number: 26.6875 (16+10+11/16) and > > because there is already a hexadecimal point '.' separating the integral > > portion from the fractional portion the 'p' is not part of the number. > > That just means it's a bad example in the proposed resolution, but the > example is not normative anyway. No, there's nothing wrong with the example. I don't know how you're interpreting the spec but it seems wrong.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #11 from Jonathan Wakely --- (In reply to Ben Woodard from comment #10) > Also note: https://connect.microsoft.com/VisualStudio/feedback/details/742775 > > My reading of: > https://wg21.link/lwg2381 > > is that if the first part of the number includes a '.' then the portion > after the 'p' or 'P' is not part of the number and is left in the string. > The example is > 0x1a.bp+07p > > So I believe that your assertion that 2381 applies in this situation is not > accurate. This example refers to the number: 26.6875 (16+10+11/16) and > because there is already a hexadecimal point '.' separating the integral > portion from the fractional portion the 'p' is not part of the number. That just means it's a bad example in the proposed resolution, but the example is not normative anyway. > However, if the number was: "0x1abp+07p" (note the absence of the '.') then > the number would be: in the normal hexfloat format and refer to 1752839.0 > leaving the trailing 'p' in the stream. But in all versions of the C++ standard the first 'p' is not accumulated in Stage 2 of the num_get::do_get call, and so the string passed to strtod is "0x1ab" and nothing more. That's what LWG 2381 is about: the list of atoms needs to be extended to include 'p' and 'P' so that the fractional portion can be accumulated and passed to strtod.
[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691 --- Comment #10 from Dominique d'Humieres --- The test in comment 3 has likely been fixed by revision r222361 (pr60322).
[Bug c++/83835] [7/8 Regression] constexpr constructor rejected in c++17 mode (regression WRT c++14)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83835
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-27
CC||jason at gcc dot gnu.org,
||msebor at gcc dot gnu.org
Known to work||6.4.0
Summary|constexpr constructor |[7/8 Regression] constexpr
|rejected in c++17 mode |constructor rejected in
|(regression WRT c++14) |c++17 mode (regression WRT
||c++14)
Ever confirmed|0 |1
Known to fail||7.2.0, 8.0
--- Comment #1 from Martin Sebor ---
Confirmed with the slightly simplified test case below. Other compilers accept
the code, as does GCC 6.4.0.
The regression was introduced in GCC 7.0 by r240889.
$ cat pr83835.C && gcc -S -Wall -std=c++17 pr83835.C
struct Y {
struct Z {
virtual ~Z ();
constexpr explicit Z (const Y*) { }
};
Z z;
constexpr Y (): z (this) { }
};
pr83835.C: In constructor ‘constexpr Y::Y()’:
pr83835.C:9:32: error: temporary of non-literal type ‘Y::Z’ in a constant
expression
constexpr Y (): z (this) { }
^
pr83835.C:2:12: note: ‘Y::Z’ is not literal because:
struct Z {
^
pr83835.C:2:12: note: ‘Y::Z’ has a non-trivial destructor
[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691 Dominique d'Humieres changed: What|Removed |Added CC||vladimir.fuka at gmail dot com --- Comment #9 from Dominique d'Humieres --- *** Bug 84074 has been marked as a duplicate of this bug. ***
[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- > I am pretty sure there is at least one duplicate, but I cannot find it right > now. I found it: pr56691. *** This bug has been marked as a duplicate of bug 56691 ***
[Bug target/84039] x86 retpolines and CFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84039 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-27 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- (In reply to Florian Weimer from comment #0) Can you try hjl/pr84039/master branch at https://github.com/hjl-tools/gcc
[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84048 John David Anglin changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #4 from John David Anglin --- ii binutils 2.29.90.2018 hppa GNU assembler, linker and binary
[Bug testsuite/83881] FAIL: c-c++-common/Wrestrict.c -std=gnu++98 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83881 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from John David Anglin --- Fixed.
[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 Dominique d'Humieres changed: What|Removed |Added CC||frank.otto at pci dot uni-heidelbe ||rg.de --- Comment #12 from Dominique d'Humieres --- *** Bug 58043 has been marked as a duplicate of this bug. ***
[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Dominique d'Humieres --- Likely fixed by revision r222361, i.e., a duplicate of pr60322. *** This bug has been marked as a duplicate of bug 60322 ***
[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010 --- Comment #10 from Segher Boessenkool --- (In reply to Peter Bergner from comment #9) > (In reply to Segher Boessenkool from comment #8) > >> This kernel AT_PLATFORM name should strip the '+' off: > >> .platform = "power7+", -> "power7" > > > > We probably should have a -mcpu=power7+, we have power5+ as well etc. > > Well, we have a -mcpu=power5+ because power5+ added a few new instructions > over and above what power5 has. That is not the case with power7+. It > implements the exact same instructions that power7 does, so power7+ doesn't > really buy us anything. It makes life simpler for users who do not know that -- like the compiler itself with -mcpu=native :-) (Compare with 740 vs. 750, although you could call that historical accident). power7 and power7+ have different cache sizes, if we ever bother to get that right, too. > >> These kernel AT_PLATFORM names should strip their prefix and suffix off: > >> .platform = "ppc440gp", -> "440" > >> .platform = "ppc-cell-be", -> "cell" > >> > >> These kernel AT_PLATFORM names should strip the 'ppc' prefix off, as > >> well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU: > >> .platform = "ppc405", -> "405" | "405fp" > >> .platform = "ppc440", -> "440" | "440fp" > >> > >> This kernel AT_PLATFORM name should strip the 'ppc' prefix off, change > >> 470 to 476 as well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU: > >> .platform = "ppc470", -> "476" | "476fp" > > > > We could also decide not to support those for "native" (except cell?), > > they all have problems and no one will try to build on those anyway. > > I hope. > > Well, it was easy enough to add support for them in case some did try in the > future. Up to you though if you want to leave them out. The "fp" ones are not so easy. I don't know if 440gp is the same core. > > Could use 970 for pa6t, if we care. > > Its up to you if you want me to map that to 970. Let me know what you want > me to do. I don't think we care.
[Bug c++/83870] template parameter pack followed by another template parameter does not error when following parameter can not be deduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83870 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-27 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.2.0, 8.0 --- Comment #1 from Martin Sebor --- Confirmed. The example is still in [temp.param], p15 of N4700. Clang silently accepts it but others warn.
[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-27 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 6.4.0, 7.2.0 and trunk (8.0). For 4.8, 4.9, and 5 the values for a%n and a(1:size(a))%n are also wrong. using do i=0,size(a)-1 print *,a(i)%n enddo displays the expected values. I am pretty sure there is at least one duplicate, but I cannot find it right now.
[Bug fortran/56765] [OOP] compilation errors/ICE with polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56765 --- Comment #7 from Dominique d'Humieres --- > On my environment, all tests compile now without an ICE. Confirmed.
[Bug c++/83873] adjacent digit separators are accepted in the exponent-part of floating-point literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83873 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.2.0, 8.0 --- Comment #1 from Martin Sebor --- Confirmed.
[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83633 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- Patched to mailing list.
[Bug fortran/84074] New: Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074 Bug ID: 84074 Summary: Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com Target Milestone: --- Base on https://stackoverflow.com/questions/48468922/creating-a-subset-of-an-array-of-derived-type-in-fortran-doesnt-work-what-am-i/48470594#48470594 Problem appears not just for vector subscript expressions, but I also confirmed for array(2:1:-1). type :: t integer :: n end type type(t) :: array(2) = [t(1),t(2)] call sub(array((/1,2/))) contains subroutine sub(a) class(t) :: a(:) integer :: i print *, "loop a(i) :" do i=1,size(a) print *,a(i)%n enddo print *, "a%n :",a%n print *, "a(1:size(a))%n :",a(1:size(a))%n end subroutine end program Expected output is 1 and 2 for all three. Actual output: > gfortran-7 vecsubs2.f90 > ./a.out loop a(i) : 2 0 a%n : 1 2 a(1:size(a))%n : 1 2
[Bug c++/83936] [feature request] Allow constexpr char* as target argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83936
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-26
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Martin Sebor ---
Confirmed based on comment #4.
As a side note, the limitation isn't specific to back-ends. The C++ front-end
itself doesn't accept a constexpr string as an argument to an attribute that
expects a string. (For the one attribute the C++ standard specifies that takes
a string argument it requires it to be a string literal. But G++ could accept
constexpr strings in other attributes, target-specific or otherwise, and even
in the standard [[deprecated(msg)]] attribute G++ could accept it as an
extension.)
$ cat t.C && gcc -S -Wall -Wextra -Wpedantic -Wswitch-enum t.C
struct A
{
static constexpr const char msg[] = "string doesn't work";
static constexpr unsigned align = 4;
};
template
struct B
{
static void foo [[gnu::deprecated (T::msg)]] () { }
typedef int I4 [[gnu::aligned (T::align)]];
};
static_assert (alignof (B::I4) == A::align, "number works");
void h()
{
B::foo ();
}
t.C: In instantiation of ‘struct B’:
t.C:14:29: required from here
t.C:10:15: error: deprecated message is not a string
static void foo [[gnu::deprecated (T::msg)]] () { }
^~~
t.C: In function ‘void h()’:
t.C:18:9: warning: ‘static void B::foo() [with T = A]’ is deprecated
[-Wdeprecated-declarations]
B::foo ();
^~~
t.C:10:15: note: declared here
static void foo [[gnu::deprecated (T::msg)]] () { }
^~~
t.C:18:14: warning: ‘static void B::foo() [with T = A]’ is deprecated
[-Wdeprecated-declarations]
B::foo ();
^
t.C:10:15: note: declared here
static void foo [[gnu::deprecated (T::msg)]] () { }
^~~
[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055 --- Comment #6 from Kip Warner --- Hey Martin. Yes, you are right. I see it now in cl_platform.h.
[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073 --- Comment #2 from Dominique d'Humieres --- See also https://gcc.gnu.org/onlinedocs/gfortran/Further-Interoperability-of-Fortran-with-C.html#Further-Interoperability-of-Fortran-with-C > Using assumed-shape, assumed-rank and deferred-shape arrays in BIND(C) > procedures is not fully supported. In particular, C interoperable strings > of other length than one are not supported as this requires the new array > descriptor.
[Bug middle-end/84071] [7/8 regression] nonzero_bits1 of subreg incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 --- Comment #1 from Andrew Pinski --- I think this is related to PR 81443. Can you see if the 7.3 release has it fixed?
[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-26 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Withe the following change --- pr84073.f90 2018-01-26 22:48:32.0 +0100 +++ pr84073_db.f90 2018-01-27 00:03:06.0 +0100 @@ -13,10 +13,10 @@ module utderror integer(c_int):: nerrorloc real(c_double):: errorstartloc(3) real(c_double):: errorendloc(3) -character(kind=c_char, len=41) :: errorsubsystem -character(kind=c_char, len=9) :: errorseverity +character(kind=c_char) :: errorsubsystem(41) +character(kind=c_char) :: errorseverity(9) integer(c_int):: errorid -character(kind=c_char, len=1001) :: errormessage +character(kind=c_char) :: errormessage(1001) end type type(utderror_t), bind(c), save :: utderror_v I get ... char errorsubsystem[41]; char errorseverity[9]; int errorid; char errormessage[1001]; } utderror_t; void add_utd_error (int *ierror); extern utderror_t utderror_v; Possibly related to PR38506.
[Bug middle-end/84071] [7/8 regression] nonzero_bits1 of subreg incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target||arm Target Milestone|--- |7.4
[Bug target/83712] [6/7/8 Regression] "Unable to find a register to spill" when compiling for thumb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #5 from Vladimir Makarov --- (In reply to sudi from comment #4) > What I have observed so far is that the failure occurs based on how the > scheduler (sched1) chooses to schedule the movmem12b instructions (insn 16 > in all the cases below). If that > instruction is scheduled a bit later (even by one instruction), its all good! > > Even though the movmem12b instruction has a very heavy demand on the > registers, shouldn't the allocator and/or the scheduler be able to detect > that? Is this a scheduler problem or an allocator problem or neither? > It is hard to say which pass (scheduler or RA) is responsible for the bug. Such bug was frequent for older reload pass. Therefore for i386 the 1st insn scheduling was switched off long ago. The newer LRA has a new feature to spill hard reg live range in some cases. Unfortunately, it does not always work. In this case the scheduler extends live ranges of hard registers used for parameter passing. To improve communication of the scheduler and RA. a few years ago a register-pressure sensitive scheduling was introduced. It should prevent occurrence of 'unable to find a register to spill' situation and decrease number of spills in RA. We have two different algorithms for register-pressure sensitive scheduling. ARM by default uses the 2nd one (MODEL) probably because it results in a better generated code. The 1st algorithm (WEIGHTED) is less aggressive but more safe IMHO. So if you add --param sched-pressure-algorithm=1, the problem goes away. So I see 3 possible ways to solve the problem: 1. Fix it in RA which would be very hard. 2. Fix it in the 2nd pressure-sensitive insn scheduling. I think Richard Sandiford would do this as an author of the code or at least to say how hard to fix the problem there. 3. Use more conservative but safe 1st algorithm. This is the simplest solution. I'd like to see other people opinions on what approach to use because I have no particular preference except avoiding the 1st approach.
[Bug c/83955] false positive implicit-fallthrough warning on switch enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83955 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Without -Wswitch-default GCC doesn't warn for case statements that have labels for all values of the enumerated controlling expression. I.e., the assumption is that the controlling expression's value matches one of the enumerators. Having -Wimplicit-fallthrough warn for such a case statement would run counter to that philosophy. I think -Wimplicit-fallthrough should do what GCC does without -Wswitch-default and assume that a case statement that transfers control out of all labels for all of its controlling expression's enumerators does not fall through. With that I will confirm this report as a bug.
[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #26 from acsawdey at gcc dot gnu.org ---
A little bit more info:
It appears the parameter asmhdr in this function is at the center of this:
func (tools gccgoToolchain) gc(b *Builder, a *Action, archive string, importcfg
[]byte, asmhdr bool, gofiles []string) (ofile string, output []byte, err error)
{
vt_add_function_parameter first sees this as (reg/v:DI 194 [ asmhdrD_4038 ])
but then near the top of the function is uses replace_equiv_address_nv to
rewrite it as:
(mem/c:QI (plus:DI (plus:DI (reg/f:DI 187)
(const_int 32 [0x20]))
(const_int 72 [0x48])) [8 asmhdrD_4038+0 S1 A64])
Then this piece of code in the same function gets ahold of it:
lowpart = var_lowpart (mode, incoming);
if (!lowpart)
return;
val = cselib_lookup_from_insn (lowpart, mode, true,
VOIDmode, get_insns ());
/* ??? Float-typed values in memory are not handled by
cselib. */
if (val)
{
preserve_value (val);
set_variable_part (out, val->val_rtx, dv, const_offset,
VAR_INIT_STATUS_INITIALIZED, NULL, INSERT);
dv = dv_from_value (val->val_rtx);
}
if (MEM_P (incoming))
{
val = cselib_lookup_from_insn (XEXP (incoming, 0), mode, true,
VOIDmode, get_insns ());
if (val)
{
preserve_value (val);
incoming = replace_equiv_address_nv (incoming, val->val_rtx);
}
}
This preserves the whole thing at the first preserve call:
(mem/c:QI (plus:DI (plus:DI (reg/f:DI 187)
(const_int 32 [0x20]))
(const_int 72 [0x48])) [8 asmhdrD_4038+0 S1 A64])
and this piece at the second call inside the MEM_P condition:
(plus:DI (plus:DI (reg/f:DI 187)
(const_int 32 [0x20]))
(const_int 72 [0x48]))
The expression that later causes the problem is the (reg/f:DI 187) in the
center of that which is not preserved.
Later when cselib_expand_value expands asmhdr, vt_expand_var_loc_chain gets
called on all 3 pieces of this and throws the assert on the innermost one
(reg/f:DI 187) when it sees it is not marked preserve.
[Bug c++/84027] new-expression does not accept an attribute-specifier-seq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84027
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-26
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||7.1.0, 8.0
--- Comment #1 from Martin Sebor ---
Confirmed. AFAICS, both the form in comment #0 and the one below should be
accepted but neither is.
void f() { char* p = new char[sizeof(int)] [[gnu::aligned (alignof (int))]]; }
[Bug c++/84030] Name lookup in presence of namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84030 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. All versions of GCC all the way to 4.1 accept the code so it's not a recent regression. EDG eccp 4.13 prints the following warning: "pr84030.C", line 20: warning: ambiguous class member reference -- type "N_::A_::A_" (declared at line 5) used in preference to class "A_" (declared at line 3) int b = a.operator A_().g(); ^ I don't know if the standard requires an error for the ambiguity but if not, it would seem appropriate to at least issue a warning.
[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055 --- Comment #5 from Martin Sebor --- Here's what I see in attachment #43249: $ cat -n minimal.ii | grep -E -e 'typedef *[^ ]+ *cl_uint' -e uint32_t | grep typedef 66 typedef unsigned int __uint32_t; 186 typedef __uint32_t uint32_t; 239 typedef uint32_t cl_uint __attribute__((aligned(4))); 5667 typedef cl_uint4 cl_uint3;
[Bug target/83946] [7/8 Regression] Safe Indirect Jumps broken on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83946 --- Comment #11 from Segher Boessenkool --- Author: segher Date: Fri Jan 26 21:31:37 2018 New Revision: 257110 URL: https://gcc.gnu.org/viewcvs?rev=257110&root=gcc&view=rev Log: rs6000: Fix safe-indirect-jump-[18].c Thist patch merges the safe-indirect-jump-1.c and -8.c testcases, since they do the same thing. On the 64-bit and AIX ABIs the indirect call is not a sibcall, since there is code generated after the call (the restore of r2). On the 32-bit non-AIX ABIs it is a sibcall. Backport from trunk 2018-01-26 Segher Boessenkool * gcc.target/powerpc/safe-indirect-jump-1.c: Build on all targets. Make expected output depend on whether we expect sibcalls or not. * gcc.target/powerpc/safe-indirect-jump-8.c: Delete (merged into safe-indirect-jump-1.c). Backport from trunk 2018-01-21 Bill Schmidt PR target/83946 * gcc.target/powerpc/safe-indirect-jump-8.c: Skip for AIX. Removed: branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-8.c Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-1.c
[Bug middle-end/84034] [6/7/8 Regression] incomplete warning message with dos line endings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84034 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||dmalcolm at gcc dot gnu.org Summary|incomplete warning message |[6/7/8 Regression] |with dos line endings |incomplete warning message ||with dos line endings Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- Confirmed. gcc 6, 7 and 8 are affected; gcc 5 is not affected.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #52 from H.J. Lu --- *** Bug 69846 has been marked as a duplicate of this bug. ***
[Bug target/69846] empty struct value fails to pass properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69846 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |8.0 --- Comment #4 from H.J. Lu --- g++.dg/abi/pr60336-2.C is very similar to this one. *** This bug has been marked as a duplicate of bug 60336 ***
[Bug target/69846] empty struct value fails to pass properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69846 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 Ever confirmed|0 |1 --- Comment #3 from H.J. Lu --- This is a dup of PR 60336. I will submit a testcase and close it.
[Bug c++/84036] [8 Regression] ICE on valid code in C++14, variadic lambda capture in a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84036 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/83956] [8 regression] error: use of deleted function ‘{anonymous}::a::~a()’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83956 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/83956] [8 regression] error: use of deleted function ‘{anonymous}::a::~a()’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83956 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Jan 26 20:47:32 2018 New Revision: 257107 URL: https://gcc.gnu.org/viewcvs?rev=257107&root=gcc&view=rev Log: PR c++/83956 - wrong dtor error with anonymous union * method.c (walk_field_subobs): Variant members only affect deletedness. (maybe_explain_implicit_delete): Pass &deleted_p for diagnostic. Added: trunk/gcc/testsuite/g++.dg/cpp0x/anon-union2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c
[Bug target/55258] SSE register isn't used for 16byte copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55258 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #2 from H.J. Lu --- GCC 7 O2 generates: _dl_profile_fixup: .LFB0: .cfi_startproc subl$24, %esp .cfi_def_cfa_offset 32 movl92(%edi), %eax movl24(%edi), %edx movl%esp, %edi movl(%eax), %eax movl(%eax,%esi,4), %eax shrl$8, %eax sall$4, %eax addl(%edx), %eax movdqu (%eax), %xmm0 movaps %xmm0, (%rsp) callsymbind32 addl$24, %esp .cfi_def_cfa_offset 8 ret .cfi_endproc
[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-26 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Aldy Hernandez --- I cannot reproduce on mainline with a cross of: --target=powerpc-e300c3-linux-gnu or --target=powerpc-linux-gnu Is this still an issue on mainline? FWIW, I couldn't reproduce with a cross for r255766 as reported.
[Bug fortran/84073] New: In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073
Bug ID: 84073
Summary: In -fc-prototypes fixed (nonzero) length strings are
mapped to plain char in prototype.
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: emsr at gcc dot gnu.org
Target Milestone: ---
Created attachment 43260
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43260&action=edit
Module with fixed length strings.
Given this:
===
! ../../bin/bin/gfortran -c -fc-prototypes fixlen_character.f95
module utderror
use iso_c_binding
type, bind(c) :: utderror_t
integer(c_int):: projectid
integer(c_int):: txantennaid
integer(c_int):: rxantennaid
integer(c_int):: pathid
integer(c_int):: frequencysetid
integer(c_int):: frequencyid
integer(c_int):: errornumber
integer(c_int):: nerrorloc
real(c_double):: errorstartloc(3)
real(c_double):: errorendloc(3)
character(kind=c_char, len=41) :: errorsubsystem
character(kind=c_char, len=9) :: errorseverity
integer(c_int):: errorid
character(kind=c_char, len=1001) :: errormessage
end type
type(utderror_t), bind(c), save :: utderror_v
interface
subroutine add_utd_error(ierror) bind(c)
use iso_c_binding
implicit none
integer(c_int), intent(out) :: ierror
end subroutine
end interface
end module
===
I get:
===
typedef struct utderror_t {
int projectid;
int txantennaid;
int rxantennaid;
int pathid;
int frequencysetid;
int frequencyid;
int errornumber;
int nerrorloc;
double errorstartloc[3];
double errorendloc[3];
char errorsubsystem;
char errorseverity;
int errorid;
char errormessage;
} utderror_t;
void add_utd_error (int *ierror);
typedef struct utderror_t {
int projectid;
int txantennaid;
int rxantennaid;
int pathid;
int frequencysetid;
int frequencyid;
int errornumber;
int nerrorloc;
double errorstartloc[3];
double errorendloc[3];
char errorsubsystem;
char errorseverity;
int errorid;
char errormessage;
} utderror_t;
void add_utd_error (int *ierror);
extern utderror_t utderror_v;
extern utderror_t utderror_v;
===
I think the strings should be
char errorsubsystem[41];
char errorseverity[9];
int errorid;
char errormessage[1001];
If I do this by hand things work out.
Ed
[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055 --- Comment #4 from Kip Warner --- Thanks Martin. I'm curious where the __int32 type was even coming from. cl_platform.h has the following typedef, among others that use it... typedef unsigned __int32cl_uint; ...but no where can I find __int32 declared anywhere. As far as I know, this is an M$ V!C++ built in type and gcc doesn't have it built in. The reason why I'm curious is because I wanted to find where the alignment attribute was being specified which was causing this hiccup?
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #48 from Uroš Bizjak --- (In reply to Mike Lothian from comment #47) > With the patch you've committed to gcc master, applied on top of GCC 7.3 I'm > now seeing the following error building Clang: I don't think this is related to the original bugreport involving BMI instructions. Could be Clang's source incompatibility with 32bit target. In any case, please open a new PR.
[Bug target/84072] New: [meta-bug] -mindirect-branch=thunk issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84072 Bug ID: 84072 Summary: [meta-bug] -mindirect-branch=thunk issues Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Depends on: 83970, 84039 Target Milestone: --- Target: x86 This meta bug tracks all -mindirect-branch=thunk related issues Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83970 [Bug 83970] -mindirect-branch=thunk -fno-plt generates CET-incompatible thunk https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84039 [Bug 84039] x86 retpolines and CFI
[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-26
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||7.2.0, 8.0
--- Comment #3 from Martin Sebor ---
I think it's just a matter of G++ warning that a type attribute is being
dropped when instantiating a template on the type. This is not entirely
intuitive and there have been other bug reports in the past as a result.
Here's a small test case:
$ cat t.C && gcc -S -Wall t.C
typedef unsigned cl_uint __attribute__((aligned(4)));
template
struct vector { };
vector v;
t.C:6:15: warning: ignoring attributes on template argument ‘cl_uint’ {aka
‘unsigned int’} [-Wignored-attributes]
vector v;
^
I'll go ahead and confirm this report because the attribute here is superfluous
when an int is 4-byte aligned and so GCC might as well just silently drop it
when it's explicitly specified and avoid issuing a pointless warning.
I also confirm it because I'm bothered by the warning being issued
inconsistently. For example, in the test case below, instantiating the class
template A on I4 triggers the (pointless in this case) -Wignored-attributes
warning but instantiating the function template g on f does not even though the
-Wreturn-type warning implies that the noreturn attribute was dropped. I think
GCC should be consistent, if not in applying/dropping attributes then in
issuing the -Wignored-attributes warning.
$ cat t.C && gcc -S -Wall t.C
typedef int I4 __attribute__ ((aligned (4)));
template
struct A { };
template struct A;
int __attribute__ ((noreturn)) f ();
template
int g (T t) { t (); }
void h ()
{
g (f);
}
t.C:5:21: warning: ignoring attributes on template argument ‘I4’ {aka ‘int’}
[-Wignored-attributes]
template struct A;
^
t.C: In function ‘int g(T)’:
t.C:10:21: warning: no return statement in function returning non-void
[-Wreturn-type]
int g (T t) { t (); }
^
[Bug fortran/83998] [8 Regression] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83998 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from kargl at gcc dot gnu.org --- Fixed on trunk. Thanks for the byg report.
[Bug fortran/83998] [8 Regression] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83998 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jan 26 19:33:16 2018 New Revision: 257104 URL: https://gcc.gnu.org/viewcvs?rev=257104&root=gcc&view=rev Log: 2018-01-26 Steven G. Kargl PR fortran/83998 * simplify.c (compute_dot_product): Initialize result to INTEGER(1) 0 or .false. The summation does the correct type conversion. (gfc_simplify_dot_product): Special case zero-sized arrays. 2018-01-26 Steven G. Kargl PR fortran/83998 * gfortran.dg/dot_product_4.f90 Added: trunk/gcc/testsuite/gfortran.dg/dot_product_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046
--- Comment #4 from Jakub Jelinek ---
If you want aggregate with size 1 and isn't used to store information, use
typedef struct { char : 1; } zero;
instead.
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #13 from H.J. Lu --- (In reply to H.J. Lu from comment #12) > > Yes, I can reproduce it with binutils 2.29.1. But it was fixed in > 2.30. This is: https://sourceware.org/bugzilla/show_bug.cgi?id=22502
[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046
--- Comment #3 from Martin Uecker ---
(In reply to Richard Biener from comment #1)
> Confirmed. I think the C language doesn't specify this since zero-sized
> arrays are a GNU extension and thus in C no zero-sized types/decls exist?
>
> So not sure if there's anything to fix - Joseph?
>
> Note that for global unique addresses you can use global objects of size 1,
> like a char object. Not sure why you think using a GNU extension is
> superior?
It makes it clear in a nice way that these variables are not used to store
information.
(In reply to Jakub Jelinek from comment #2)
> Zero sized objects of course can have the same address and always had.
> Just in your testcase the comparison used to be optimized away before
> r218462.
> If you hide it from the optimizers, like with:
> int *p = a;
> int *q = b;
> asm ("" : "+r" (p), "+r" (q));
> if(p == q) __builtin_abort ();
> you'll get aborts all the way to r104500 (oldest revision I have around).
Oh well, so this was simply an incorrect optimization.
[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Aldy Hernandez --- Confirmed.
[Bug c++/83502] [6/7/8 Regression] bogus -Wattributes for always_inline and noinline on function template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83502 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Aldy Hernandez --- Confirmed.
[Bug tree-optimization/84053] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84053 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Aldy Hernandez --- Confirmed.
[Bug middle-end/84071] New: [7/8 regression] nonzero_bits1 of subreg incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071
Bug ID: 84071
Summary: [7/8 regression] nonzero_bits1 of subreg incorrect
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
PR59461 changed nonzero_bits1 incorrectly for subregs:
/* On many CISC machines, accessing an object in a wider mode
causes the high-order bits to become undefined. So they are
not known to be zero. */
rtx_code extend_op;
if ((!WORD_REGISTER_OPERATIONS
/* If this is a typical RISC machine, we only have to worry
about the way loads are extended. */
|| ((extend_op = load_extend_op (inner_mode)) == SIGN_EXTEND
? val_signbit_known_set_p (inner_mode, nonzero)
: extend_op != ZERO_EXTEND)
|| (!MEM_P (SUBREG_REG (x)) && !REG_P (SUBREG_REG (x
&& xmode_width > inner_width)
nonzero
|= (GET_MODE_MASK (GET_MODE (x)) & ~GET_MODE_MASK (inner_mode));
If WORD_REGISTER_OPERATIONS is set and load_extend_op is ZERO_EXTEND, rtl like
(subreg:SI (reg:HI 125) 0)
is assumed to be always zero-extended. This is incorrect since modes that are
smaller than WORD_MODE may contain random top bits. This is equally true for
RISC and CISC ISAs and independent of WORD_REGISTER_OPERATIONS, so it's unclear
why the !REG_P check was added.
On ARM this causes the following bug:
arm-none-eabi-gcc -march=armv7-a -marm -O2 -S -o- -mbig-endian
typedef union
{
signed short ss;
unsigned short us;
int x;
} U;
int f(int x, int y, int z, int a, U u)
{
return (u.ss <= 0) + u.us;
}
ldrsh r3, [sp]
sxthr0, r3
cmp r0, #0 // correctly uses sign-extended value
movgt r0, r3 // wrong - must be zero-extended!!!
addle r0, r3, #1
bx lr
[Bug tree-optimization/84051] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds access via an array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84051 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Aldy Hernandez --- Confirmed.
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 --- Comment #12 from H.J. Lu --- (In reply to Richard Biener from comment #8) > and then I get > > > gcc-7 t2.s t1.c -flto > /tmp/ccGhH7Cp.o:(.data+0x0): undefined reference to `Handler' > collect2: error: ld returned 1 exit status > > gcc-7 t1.c t2.s -flto > > in the working case: > > 1 > t1.o 4 > 190 16b2980a71930688 PREEMPTED_REG Handler > 198 16b2980a71930688 PREVAILING_DEF_IRONLY i > 194 16b2980a71930688 PREVAILING_DEF main > 202 16b2980a71930688 RESOLVED_EXEC Dispatch > > in the failing case (GNU ld): > > 1 > t1.o 4 > 190 801577c96f9ccef3 PREVAILING_DEF_IRONLY Handler > 198 801577c96f9ccef3 PREVAILING_DEF_IRONLY i > 194 801577c96f9ccef3 PREVAILING_DEF main > 202 801577c96f9ccef3 RESOLVED_EXEC Dispatch > > which works with gold: > > 1 > t1.o 4 > 190 680bbd652c7cfe04 PREVAILING_DEF Handler > 198 680bbd652c7cfe04 PREVAILING_DEF_IRONLY i > 194 680bbd652c7cfe04 PREVAILING_DEF main > 202 680bbd652c7cfe04 RESOLVED_EXEC Dispatch > > HJ? This is with binutils 2.29.1, thus confirmed but as a GNU ld issue. Yes, I can reproduce it with binutils 2.29.1. But it was fixed in 2.30.
[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83776 --- Comment #5 from Martin Sebor --- (In reply to Aldy Hernandez from comment #4) > Isn't this a duplicate of pr84047? My patch on that seems to fix this bug > as well. > > I think we should merge these PRs somehow. This bug was introduced by r164688 while pr84047 by r161655. It may be possible to fix both by a single patch. The patch I submitted for this bug also happens to fix the test case in bug 84047 comment #0 (I had missed that when I opened the bug) but not the one in bug 84047 comment #2. It might be just an oversight on my part. I think I would prefer to keep the bugs separate since they have different root causes, even if we end up fixing them in the same patch.
[Bug tree-optimization/84050] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-26
CC||aldyh at gcc dot gnu.org,
||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=84047
Ever confirmed|0 |1
--- Comment #2 from Aldy Hernandez ---
Confirmed.
FWIW, my patch for 84047 does not fix this PR, as VRP never sees the
problematic instruction and is not able to warn. This is because ccp2 has
removed the instruction.
Before ccp2 we had:
fstatic_array ()
{
static struct A a = {.a={1, 2, 3}};
int _2;
[local count: 1073741825]:
_2 = a.a[7];
return _2;
}
After ccp2 we have:
fstatic_array ()
{
static struct A a = {.a={1, 2, 3}};
[local count: 1073741825]:
return 0;
}
I'm not a language lawyer, so I don't know what the semantics of undefined
behavior is. Is returning 0 even the correct thing to do?
Though perhaps, as Jakub mentions in pr84047, maybe we should move this GCC 9?
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #47 from Mike Lothian --- With the patch you've committed to gcc master, applied on top of GCC 7.3 I'm now seeing the following error building Clang: [294/954] /usr/bin/x86_64-pc-linux-gnu-g++ -m32 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Serialization -I/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Serialization -I/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include -Iinclude -I/usr/lib/llvm/7/include -DNDEBUG -O2 -march=native -pipe -mindirect-branch=thunk -mfunction-return=thunk -mindirect-branch-register -fpermissive -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -pedantic -Wno-long-long -fPIC -MD -MT lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o -MF lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o.d -o lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o -c /var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Serialization/ASTReader.cpp FAILED: lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o /usr/bin/x86_64-pc-linux-gnu-g++ -m32 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Serialization -I/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Serialization -I/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include -Iinclude -I/usr/lib/llvm/7/include -DNDEBUG -O2 -march=native -pipe -mindirect-branch=thunk -mfunction-return=thunk -mindirect-branch-register -fpermissive -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -pedantic -Wno-long-long -fPIC -MD -MT lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o -MF lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o.d -o lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o -c /var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Serialization/ASTReader.cpp In file included from /var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/clang/AST/APValue.h:20:0, from /var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/clang/AST/Decl.h:17, from /var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/clang/AST/DeclObjC.h:17, from /var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/clang/Serialization/ASTReader.h:17, from /var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Serialization/ASTReader.cpp:14: /usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h: In instantiation of ‘struct llvm::PointerIntPairInfo*>, 2, llvm::PointerLikeTypeTraits*> > >’: /usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h:56:57: required from ‘PointerTy llvm::PointerIntPair::getPointer() const [with PointerTy = llvm::PointerUnion*>; unsigned int IntBits = 2; IntType = unsigned int; PtrTraits = llvm::PointerLikeTypeTraits*> >; Info = llvm::PointerIntPairInfo*>, 2, llvm::PointerLikeTypeTraits*> > >]’ /var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/clang/AST/Decl.h:2859:39: required from here /usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h:132:3: error: static assertion failed: PointerIntPair with integer size too large for pointer static_assert(IntBits <= PtrTraits::NumLowBitsAvailable, ^ /usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h:147:42: warning: left shift count >= width of type [-Wshift-count-overflow] ShiftedIntMask = (uintptr_t)(IntMask << IntShift) ~^~~~ /usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h:147:42: warning: right operand of shift expression ‘(3 << 4294967295)’ is >= than the precision of the left operand [-fpermissive] /usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h: In instantiation of ‘static intptr_t llvm::PointerIntPairInfo::getInt(intptr_t) [with PointerT = llvm::PointerUnion*>; unsigned int IntBits = 2; PtrTraits = llvm::PointerLikeTypeTraits*> >; intptr_t = int]’: /usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h:58:56: required from ‘IntType llvm::PointerIntPair::getInt() const [with PointerTy = llvm::PointerUnion*>; unsigned int IntBits = 2; IntType = unsigned int; PtrTraits = llvm::PointerLikeTypeTraits*> >; Info = llvm::PointerIntPairInfo*>, 2, llvm::PointerLikeTypeTraits*> > >]’ /var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/cla
[Bug target/84064] ICE in ix86_expand_prologue related to -fstack-clash-protection and memcpy on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84064 --- Comment #2 from Jeffrey A. Law --- I wasn't ever happy with the discrepancy between the computation of TO_ALLOCATE in the layout code and ALLOCATE within ix86_expand_prologue. It seemed ripe to fall into this kind of problem. sigh. If ALLOCATE was that small we don't need to do any probing unless the current function is marked as noreturn. I wonder if deferring the assertion to the point where we actually need the scratch or are going to call the msft probe function is possible.
[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83776 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #4 from Aldy Hernandez --- Isn't this a duplicate of pr84047? My patch on that seems to fix this bug as well. I think we should merge these PRs somehow.
[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds index into an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047 --- Comment #6 from Martin Sebor --- I posted a patch for a similar issue reported in bug 83776 (https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02144.html). It handles MEM_REFs and diagnoses the test case in comment #0 (I must have missed that when I opened this bug) but it doesn't handle the test case in comment #2.
[Bug c/84063] Misleading diagnostic for ignored attributes under -Wattributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84063 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. Most interesting instances of -Wattributes are in conflict with what the manual says and would better fit the description for -Wignored-attributes. -Wattributes is meant for invalid attributes (either syntactically or contextually) while -Wignored-attributes for syntactically valid ones that conflict in some way either with another declaration of the same entity or with another attribute or specifier on the same declaration. It would be a pervasive change to adjust all the warnings to fit the documented purpose but if there's support for it I'm willing to do it in GCC 9.
[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds index into an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047 --- Comment #5 from Aldy Hernandez --- Created attachment 43259 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43259&action=edit proposed UNTESTED patch (In reply to Jakub Jelinek from comment #4) > I don't think we want to be adding new cases where -Warray-bounds will warn > at this point, this warning has very high false positive rate and it is > simply too late in the release cycle for that IMNSHO. I'd retarget all > similar PRs for GCC9. Hmmm... this may be easy pickings though. It looks like before the regression we had an ARRAY_REF we could diagnose: D.2720_5 = "12345678"[1073741824]; But now this is represented as: _1 = MEM[(const char *)"12345678" + 1073741824B]; I think we can just allow check_array_bounds() to handle MEM_REF's and everything should just work. The attached untested patch fixes the PR. However, if you think this is not worth pursuing, I can drop this and retarget this bug to GCC 9. Your call Jakub.
[Bug c++/80567] [8 Regression] bogus fixit hint for undeclared memset: else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80567 David Malcolm changed: What|Removed |Added Status|NEW |UNCONFIRMED Version|7.0 |8.0 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Summary|bogus fixit hint for|[8 Regression] bogus fixit |undeclared memset: else |hint for undeclared memset: ||else Ever confirmed|1 |0 --- Comment #5 from David Malcolm --- gcc 7 and earlier are unaffected, so marking as a regression.
[Bug fortran/84070] Incorrect assignment to allocatable character variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84070 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-26 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- This has been fixed on trunk, likely revision r251125 and looks as a duplicate of pr81116.
[Bug c++/81610] [8 Regression] bogus fix-it hint for a call to an undeclared function: for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81610 David Malcolm changed: What|Removed |Added Summary|bogus fix-it hint for a |[8 Regression] bogus fix-it |call to an undeclared |hint for a call to an |function: for |undeclared function: for --- Comment #3 from David Malcolm --- gcc 7 and earlier are unaffected, so marking as a regression.
[Bug fortran/84070] New: Incorrect assignment to allocatable character variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84070
Bug ID: 84070
Summary: Incorrect assignment to allocatable character variable
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: walt.brainerd at gmail dot com
Target Milestone: ---
character(len=:), allocatable :: c
c = "abc"
print *, "A" // c // "Z"
c = c(1:0) // c(2:)
print *, "A" // c // "Z"
print *, iachar(" "), iachar(c(2:2))
end
PROFITOOL+WAB@DEN-000256L /cygdrive/c
$ !.
./a
AabcZ
Ab Z
32 32
Note missing character "c" after assignment.
It is instead a space.
[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969 Martin Sebor changed: What|Removed |Added Last reconfirmed|2017-05-23 00:00:00 |2018-1-26 Known to fail||8.0 --- Comment #10 from Martin Sebor --- No change in GCC 8.0.
[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds index into an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- I don't think we want to be adding new cases where -Warray-bounds will warn at this point, this warning has very high false positive rate and it is simply too late in the release cycle for that IMNSHO. I'd retarget all similar PRs for GCC9.
[Bug fortran/84065] [8 regression] string_1.f90 fails since r256944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84065
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
CC||jakub at gcc dot gnu.org
Target Milestone|--- |8.0
--- Comment #2 from Jakub Jelinek ---
I guess the testcase kind of assumes both 32-bit target and 32-bit host,
because on 64-bit host, 32-bit target we do:
1760 HOST_WIDE_INT len = gfc_mpz_get_hwi
(sym->ts.u.cl->length->value.integer);
1761
1762 if (init->expr_type == EXPR_CONSTANT)
1763gfc_set_constant_character_len (len, init, -1);
and len is 0x10004, i.e. larger than can fit into target's address space.
Which in the end means allocation of 0x10004 * 4 bytes of memory, setting
that all to ' ' etc., and doing it for a bunch of similar strings.
Conceptually, it would be nice if the FE could represent more efficiently these
cases where there is just small amount of real data followed by a huge
repetition of something (in this case ' ').
Or, for this testcase, we could perhaps repeat the comparison that
resolve_charlen will do, and either don't create the initializer in that case,
or error right away. The former is in:
--- decl.c.jj8 2018-01-23 21:35:04.0 +0100
+++ decl.c 2018-01-26 18:24:22.064763299 +0100
@@ -1757,22 +1757,32 @@ add_init_expr_to_sym (const char *name,
if (!gfc_specification_expr (sym->ts.u.cl->length))
return false;
- HOST_WIDE_INT len = gfc_mpz_get_hwi
(sym->ts.u.cl->length->value.integer);
-
- if (init->expr_type == EXPR_CONSTANT)
- gfc_set_constant_character_len (len, init, -1);
- else if (init->expr_type == EXPR_ARRAY)
+ int k = gfc_validate_kind (BT_INTEGER, gfc_charlen_int_kind,
+false);
+ /* resolve_charlen will complain later on if the length
+is too large. Just skeep the initialization in that case. */
+ if (mpz_cmp (sym->ts.u.cl->length->value.integer,
+ gfc_integer_kinds[k].huge) <= 0)
{
- gfc_constructor *c;
+ HOST_WIDE_INT len
+ = gfc_mpz_get_hwi (sym->ts.u.cl->length->value.integer);
+
+ if (init->expr_type == EXPR_CONSTANT)
+ gfc_set_constant_character_len (len, init, -1);
+ else if (init->expr_type == EXPR_ARRAY)
+ {
+ gfc_constructor *c;
- /* Build a new charlen to prevent simplification from
-deleting the length before it is resolved. */
- init->ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL);
- init->ts.u.cl->length = gfc_copy_expr (sym->ts.u.cl->length);
+ /* Build a new charlen to prevent simplification from
+deleting the length before it is resolved. */
+ init->ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL);
+ init->ts.u.cl->length
+ = gfc_copy_expr (sym->ts.u.cl->length);
- for (c = gfc_constructor_first (init->value.constructor);
- c; c = gfc_constructor_next (c))
- gfc_set_constant_character_len (len, c->expr, -1);
+ for (c = gfc_constructor_first (init->value.constructor);
+ c; c = gfc_constructor_next (c))
+ gfc_set_constant_character_len (len, c->expr, -1);
+ }
}
}
}
[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds index into an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||aldyh at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Aldy Hernandez --- Confirmed, and confirmed that the regression started with r161655.
[Bug tree-optimization/84069] New: missing strlen optimization after constant memcpy with offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84069
Bug ID: 84069
Summary: missing strlen optimization after constant memcpy with
offset
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
With pr83501 fixed by r256475, GCC 8 is able to fold the call to strlen() in
function f0() below into a constant, and replace the whole body of the function
with just a return statement. Unfortunately (as pointed out in
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01879.html), it is not able to
perform the same transformation in the equivalent function f1() in the test
case.
$ cat t.c && /ssd/build/gcc-svn/gcc/xgcc -B /ssd/build/gcc-svn/gcc -O2 -S -Wall
-fdump-tree-optimized=/dev/stdout t.c
int f0 (void) // folded into 'return 5'
{
const char s[] = "1234";
char d[sizeof s + 1];
*d = '0';
__builtin_strcpy (d + 1, s);
return __builtin_strlen (d); // folded into 5
}
int f1 (void) // not folded
{
const char s[] = "1234";
char d[sizeof s + 1];
*d = '0';
__builtin_memcpy (d + 1, s, sizeof s);
return __builtin_strlen (d); // not folded
}
;; Function f0 (f0, funcdef_no=0, decl_uid=1950, cgraph_uid=0, symbol_order=0)
f0 ()
{
[local count: 1073741825]:
return 5;
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1955, cgraph_uid=1, symbol_order=1)
f1 ()
{
char d[6];
const char s[5];
long unsigned int _1;
int _6;
[local count: 1073741825]:
s = "1234";
d[0] = 48;
MEM[(char * {ref-all})&d + 1B] = MEM[(char * {ref-all})&s];
_1 = __builtin_strlen (&d);
_6 = (int) _1;
s ={v} {CLOBBER};
d ={v} {CLOBBER};
return _6;
}
[Bug target/83845] [8 regression] new failures after r256620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83845 rsandifo at gcc dot gnu.org changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-01/msg02169.ht ||ml --- Comment #4 from rsandifo at gcc dot gnu.org --- Patched for big-endian failures posted here: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02169.html I've also posted patches for other big-endian failures. Together they give clean results for aarch64-sve.exp and also seem to give clean results overall when configured with --with-arch=armv8.2-a+sve. The ILP32 failures are being tracked in PR83846.
[Bug rtl-optimization/84068] New: ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1 with -fno-sched-critical-path-heuristic --param=max-sched-extend-regions-iters=5 @ aarch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84068 Bug ID: 84068 Summary: ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1 with -fno-sched-critical-path-heuristic --param=max-sched-extend-regions-iters=5 @ aarch64 Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 43258 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43258&action=edit reduced testcase Compiler output: $ aarch64-unknown-linux-gnu-gcc -O2 -fno-sched-critical-path-heuristic -fno-sched-rank-heuristic --param=max-sched-extend-regions-iters=5 testcase.c testcase.c: In function 'foo': testcase.c:7:1: error: qsort comparator non-negative on sorted output: 1 } ^ during RTL pass: sched1 testcase.c:7:1: internal compiler error: qsort checking failed 0x5ec995 qsort_chk_error /repo/gcc-trunk/gcc/vec.c:201 0x156d5ca qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) /repo/gcc-trunk/gcc/vec.c:253 0x146c640 ready_sort_real /repo/gcc-trunk/gcc/haifa-sched.c:3087 0x14756ca schedule_block(basic_block_def**, void*) /repo/gcc-trunk/gcc/haifa-sched.c:6675 0xc1b7da schedule_region /repo/gcc-trunk/gcc/sched-rgn.c:3174 0xc1b7da schedule_insns() /repo/gcc-trunk/gcc/sched-rgn.c:3513 0xc1bc03 schedule_insns() /repo/gcc-trunk/gcc/sched-rgn.c:3498 0xc1bc03 rest_of_handle_sched /repo/gcc-trunk/gcc/sched-rgn.c:3717 0xc1bc03 execute /repo/gcc-trunk/gcc/sched-rgn.c:3825 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-257087-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.1/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-257087-checking-yes-rtl-df-extra-aarch64 Thread model: posix gcc version 8.0.1 20180126 (experimental) (GCC)
[Bug target/83846] Some SVE tests fail with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83846 rsandifo at gcc dot gnu.org changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-01/msg02181.ht ||ml --- Comment #5 from rsandifo at gcc dot gnu.org --- Patch posted here: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02181.html
[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82249 --- Comment #8 from Jason Merrill --- Author: jason Date: Fri Jan 26 17:10:24 2018 New Revision: 257101 URL: https://gcc.gnu.org/viewcvs?rev=257101&root=gcc&view=rev Log: PR c++/84036 - ICE with variadic capture. PR c++/82249 * pt.c (tsubst_pack_expansion): When optimizing a simple substitution, pull a single pack expansion out of its pack. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/84036] [8 Regression] ICE on valid code in C++14, variadic lambda capture in a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84036 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Jan 26 17:10:24 2018 New Revision: 257101 URL: https://gcc.gnu.org/viewcvs?rev=257101&root=gcc&view=rev Log: PR c++/84036 - ICE with variadic capture. PR c++/82249 * pt.c (tsubst_pack_expansion): When optimizing a simple substitution, pull a single pack expansion out of its pack. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/84045] [7/8 Regression] ICE when is_nothrow_default_constructible is used before #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84045 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Bisected to r241944.
[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601 --- Comment #24 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #23) > What would create those BIT_FIELD_REFs so early though? They should stay as > COMPONENT_REFs. I thought you'd never ask... why our friend fold_truth_andor_1 :). /* Make a mask that corresponds to both fields being compared. Do this for both items being compared. If the operands are the same size and the bits being compared are in the same position then we can do this by masking both and comparing the masked results. */
[Bug tree-optimization/83896] [8 Regression] ice in get_string_len on a call to strlen with non-constant length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83896 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Sebor --- Fixed via r257100.
[Bug tree-optimization/83896] [8 Regression] ice in get_string_len on a call to strlen with non-constant length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83896 --- Comment #5 from Martin Sebor --- Author: msebor Date: Fri Jan 26 16:47:22 2018 New Revision: 257100 URL: https://gcc.gnu.org/viewcvs?rev=257100&root=gcc&view=rev Log: PR tree-optimization/83896 - ice in get_string_len on a call to strlen with non-constant length gcc/ChangeLog: PR tree-optimization/83896 * tree-ssa-strlen.c (get_string_len): Rename... (get_string_cst_length): ...to this. Return HOST_WIDE_INT. Avoid assuming length is constant. (handle_char_store): Use HOST_WIDE_INT for string length. gcc/testsuite/ChangeLog: PR tree-optimization/83896 * gcc.dg/strlenopt-43.c: New test. Added: trunk/gcc/testsuite/gcc.dg/strlenopt-43.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-strlen.c
[Bug c++/84045] [7/8 Regression] ICE when is_nothrow_default_constructible is used before #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84045
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Another reduction that is accepted by g++6 and clang++:
template struct C { static constexpr T d = N; };
template struct A;
template struct E;
template struct E : A::I {};
struct J : C {};
template struct K : E {};
template struct A { typedef T I; };
template struct B {
typedef K D;
void foo () noexcept (D::d);
};
template struct P { P () noexcept (K::d); };
struct { P o; } p;
There is some glitch in our bisect seed between r241875 and r241958, so
bisection will take some time.
[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601 --- Comment #23 from Jakub Jelinek --- What would create those BIT_FIELD_REFs so early though? They should stay as COMPONENT_REFs.
[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Aldy Hernandez changed:
What|Removed |Added
Assignee|aldyh at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #22 from Aldy Hernandez ---
FWIW, the C++ front-end would also need changes if we move
optimize_bit_field_compare to gimple, as the constexpr code
(cxx_eval_bit_field_ref()) can only handle optimized BIT_FIELD_REFs.
For instance, it cannot look into an array of bit-fields as it's expanding a
constructor, because it was expecting optimize_bit_field_compare() to have
flattened things out first. It would die on this:
(gdb) print debug_generic_stmt (whole)
{.u=0, .a={{.i=5, .k=0, .l=2}}, .b={{.j=6}}}
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #8 from Dan Bonachea --- (In reply to Jan Hubicka from comment #7) > This should silence the warning. > Index: lto-symtab.c > === > --- lto-symtab.c(revision 257048) > +++ lto-symtab.c(working copy) > @@ -285,7 +285,9 @@ warn_type_compatibility_p (tree prevaili >alias_set_type set2 = get_alias_set (prevailing_type); > >if (set1 && set2 && set1 != set2 > - && (!POINTER_TYPE_P (type) || !POINTER_TYPE_P (prevailing_type) > + && (((!POINTER_TYPE_P (type) || !POINTER_TYPE_P (prevailing_type)) > + && (TREE_CODE (type) != ARRAY_TYPE > + || TREE_CODE (prevailing_type) != ARRAY_TYPE)) > || (set1 != TYPE_ALIAS_SET (ptr_type_node) > && set2 != TYPE_ALIAS_SET (ptr_type_node > lev |= 5; Thanks Jan! I've confirmed this patch is sufficient to silence the warning when applied to gcc 7.3.0, for both this reduced test case and the original program. Can we get this merged into the gcc development branch(es)?
[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Jakub Jelinek ---
Zero sized objects of course can have the same address and always had.
Just in your testcase the comparison used to be optimized away before r218462.
If you hide it from the optimizers, like with:
int *p = a;
int *q = b;
asm ("" : "+r" (p), "+r" (q));
if(p == q) __builtin_abort ();
you'll get aborts all the way to r104500 (oldest revision I have around).
[Bug c++/83956] [8 regression] error: use of deleted function ‘{anonymous}::a::~a()’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83956 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-26 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug lto/84044] Spurious -Wodr warning with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044
--- Comment #8 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044
>
> --- Comment #7 from rguenther at suse dot de ---
> On Fri, 26 Jan 2018, marxin at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044
> >
> > --- Comment #5 from Martin Liška ---
> > (In reply to Richard Biener from comment #4)
> > > (In reply to Martin Liška from comment #3)
> > > > Fixed on trunk by Richi's r256685. Is it intentional Richi that the
> > > > revision
> > > > should fix such situations?
> > >
> > > Not really. It means that the following hunk removes too many TYPE_BINFOs
> > > I guess?
> > >
> > > @@ -5150,15 +5145,9 @@ free_lang_data_in_type (tree type)
> > > {
> > > free_lang_data_in_binfo (TYPE_BINFO (type));
> > > /* We need to preserve link to bases and virtual table for all
> > > -polymorphic types to make devirtualization machinery working.
> > > -Debug output cares only about bases, but output also
> > > -virtual table pointers so merging of -fdevirtualize and
> > > --fno-devirtualize units is easier. */
> > > - if ((!BINFO_VTABLE (TYPE_BINFO (type))
> > > - || !flag_devirtualize)
> > > - && ((!BINFO_N_BASE_BINFOS (TYPE_BINFO (type))
> > > - && !BINFO_VTABLE (TYPE_BINFO (type)))
> > > - || debug_info_level != DINFO_LEVEL_NONE))
> > > +polymorphic types to make devirtualization machinery
> > > working.
> > > */
> > > + if (!BINFO_VTABLE (TYPE_BINFO (type))
> > > + || !flag_devirtualize)
> > > TYPE_BINFO (type) = NULL;
> > > }
> > > }
> >
> > Reverting this hunk makes the warning visible again.
>
> Interesting. This means that with -g it didn't warn before either?
> Which means that maybe unconditionally
>
> && !BINFO_N_BASE_BINFOS (TYPE_BINFO (type))
>
> was intented? Honza?
Yep that was my tought exactly, but I want to take deeper look what we really
use and what not.
Honza
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
