[Bug middle-end/84034] [6/7/8 Regression] incomplete warning message with dos line endings

[edlinger at gcc dot gnu.org]

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=gcc=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

[jakub at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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=gcc=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

[kargl at gcc dot gnu.org]

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

[dave.anglin at bell dot net]

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

[dominiq at lps dot ens.fr]

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

[aaron at aarongraham dot com]

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=edit
Patch to check for overflow

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[dave.anglin at bell dot net]

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

[msebor at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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

[dominiq at lps dot ens.fr]

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;

[redi at gcc dot gnu.org]

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;

[redi at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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)

[msebor at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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

[dominiq at lps dot ens.fr]

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

[hjl.tools at gmail dot com]

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

[danglin at gcc dot gnu.org]

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)

[danglin at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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

[dominiq at lps dot ens.fr]

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

[segher at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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

[dominiq at lps dot ens.fr]

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

[msebor at gcc dot gnu.org]

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

[kargl at gcc dot gnu.org]

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

[vladimir.fuka at gmail dot com]

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

[msebor at gcc dot gnu.org]

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]

[kip at thevertigo dot com]

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.

[dominiq at lps dot ens.fr]

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

[pinskia at gcc dot gnu.org]

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.

[dominiq at lps dot ens.fr]

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

[pinskia at gcc dot gnu.org]

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

[vmakarov at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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

[acsawdey at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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]

[msebor at gcc dot gnu.org]

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

[segher at gcc dot gnu.org]

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=gcc=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

[dmalcolm at gcc dot gnu.org]

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++

[hjl.tools at gmail dot com]

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

[hjl.tools at gmail dot com]

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

[hjl.tools at gmail dot com]

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

[jason at gcc dot gnu.org]

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()’

[jason at gcc dot gnu.org]

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()’

[jason at gcc dot gnu.org]

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=gcc=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 _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

[hjl.tools at gmail dot com]

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

[aldyh at gcc dot gnu.org]

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.

[emsr at gcc dot gnu.org]

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=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]

[kip at thevertigo dot com]

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+

[ubizjak at gmail dot com]

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

[hjl.tools at gmail dot com]

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]

[msebor at gcc dot gnu.org]

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

[kargl at gcc dot gnu.org]

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

[kargl at gcc dot gnu.org]

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=gcc=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

[jakub at gcc dot gnu.org]

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)

[hjl.tools at gmail dot com]

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

[uecker at eecs dot berkeley.edu]

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

[aldyh at gcc dot gnu.org]

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

[aldyh at gcc dot gnu.org]

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

[aldyh at gcc dot gnu.org]

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

[wilco at gcc dot gnu.org]

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

[aldyh at gcc dot gnu.org]

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)

[hjl.tools at gmail dot com]

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

[msebor at gcc dot gnu.org]

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

[aldyh at gcc dot gnu.org]

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+

[mike at fireburn dot co.uk]

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 

[Bug target/84064] ICE in ix86_expand_prologue related to -fstack-clash-protection and memcpy on i686

[law at redhat dot com]

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

[aldyh at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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

[aldyh at gcc dot gnu.org]

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=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

[dmalcolm at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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

[dmalcolm at gcc dot gnu.org]

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

[walt.brainerd at gmail dot com]

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

[msebor at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[aldyh at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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}) + 1B] = MEM[(char * {ref-all})];
  _1 = __builtin_strlen ();
  _6 = (int) _1;
  s ={v} {CLOBBER};
  d ={v} {CLOBBER};
  return _6;

}

[Bug target/83845] [8 regression] new failures after r256620

[rsandifo at gcc dot gnu.org]

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

[zsojka at seznam dot cz]

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=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

[rsandifo at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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=gcc=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

[jason at gcc dot gnu.org]

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=gcc=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

[jakub at gcc dot gnu.org]

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

[aldyh at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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=gcc=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

[jakub at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[aldyh at gcc dot gnu.org]

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

[dobonachea at lbl dot gov]

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

[jakub at gcc dot gnu.org]

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()’

[jason at gcc dot gnu.org]

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

[hubicka at ucw dot cz]

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.