[Bug go/84765] "cmd/go/internal/work/buildid.go" breaks for various non-English locales

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84765

--- Comment #2 from David Malcolm  ---
Thanks!

For reference, the fix was r258565.

[Bug c/84888] C/C++: Improve wording of unclosed paren/brace

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84888

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to David Malcolm from comment #0)
> As noted by oridb on reddit:
> 
> > I also find the large, visually complex error messages confusing to
> > read. For example, this makes me skim and see 3 separate errors:
> > 
> > t.c: In function ‘log_when_out_of_range’:
> > t.c:12:50: error: expected ‘)’ before ‘{’ token
> > && (temperature < MIN || temperature > MAX) {
> >   ^~
> >   )
> > unclosed.c:11:6: note: to match this ‘(’
> >if (logging_enabled && check_range ()
> >   ^
> > I'd rather see something like this (although, I admit the phrasing could 
> > use work):
> > 
> > t.c:12:50: error: expected ')' for unclosed '(' on t.c:11:6
> > && (temperature < MIN || temperature > MAX) {
> >   ^~
> >   )
> 
> I much prefer oridb's proposed wording to what we have now (in gcc 8),
> though I'd prefer to keep the note; I'll open another bug with some ideas I
> have about making multiple diagnostics easier on the eye.
> 
> Maybe (brainstorming here):
> 
> If it's on the same line:
> 
>   t.c:12:50: error: expected ')' for unclosed '(' on column 6
> 
> If it's in the same file:
> 
>   t.c:12:50: error: expected ')' for unclosed '(' at line 11 column 6
> 
> If it's in a different file:
> 
> t.c:12:50: error: expected ')' for unclosed '(' at other.c:11:6
> 
> (Or maybe it's better to always give the same format, to make it easier for
> IDEs to parse?)

As in bug 84887, I'd like a link to the reddit thread mentioned here, too

[Bug c/84887] missing semicolon: further improvements

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to David Malcolm from comment #0)
> 
> However, as suggested e.g. by oridb on Reddit, it would be more readable to
> talk about the previous logical unit, and emit:
> 
> t.c: In function ‘test’:
> t.c:3:12: error: expected ‘;’ after ‘42’ token
>return 42
> ^
> ;
> 
> or somesuch: e.g. should we highlight the preceding token as a secondary
> range, which would give:
> 
> t.c: In function ‘test’:
> t.c:3:12: error: expected ‘;’ after ‘42’ token
>return 42
>   ~~^
> ;
> 
> (I'm not sure either way)

link to thread on reddit?


(In reply to David Malcolm from comment #1)
> User "jancsika" on Hacker News points out:
> > [...] the output is visually confusing-- you have an arrow pointing one's
> > eye to the missing semicolon, but the underlined referent token is
> > two line  breaks away from it. Underlining the preceding "i" would put
> > the emphasized token and missing semi right next to each other.
> 
> and I agree, presumably we should print either just:
> 
> q.c:1:6: error: expected ‘;’ after ‘i’
>  int i
>   ^
> 
> or:
> 
> q.c:1:6: error: expected ‘;’ after ‘i’
>  int i
>  ~^

link to thread on Hacker News?

[Bug c++/84789] [6/7/8 Regression] ICE with broken variable declaration in template class

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84789

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #4 from Alexandre Oliva  ---
Created attachment 43672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43672=edit
candidate patch

Here's the patch I'm testing

[Bug fortran/78499] [OOP] ICE in gfc_typename, at fortran/misc.c:158

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78499

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #3 from kargl at gcc dot gnu.org ---
This appears to be fixed on trunk.
Closing.  Thanks for the bug report


 gfcx -c a.f90
a.f90:4:16:

class(t) :: x = 0
1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer
a.f90:4:18:

class(t) :: x = 0
  1
Error: Can't convert INTEGER(4) to CLASS(t) at (1)

[Bug fortran/69395] ICE on declaring array with more than 7 dimensions+codimensions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69395

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug fortran/78741] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1534

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78741

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.4

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on 7-branch and trunk.
Closing.  Thanks for the bug report.

[Bug fortran/69395] ICE on declaring array with more than 7 dimensions+codimensions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69395

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from kargl at gcc dot gnu.org ---
Closed on trunk.  Thanks for bug report.

[Bug fortran/78741] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1534

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78741

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Mar 16 03:30:06 2018
New Revision: 258583

URL: https://gcc.gnu.org/viewcvs?rev=258583=gcc=rev
Log:
Commit ChangeLog entries for revision 258582.

2018-03-15  Steven G. Kargl  

PR fortran/78741
* decl.c (get_proc_name):  Check for clash of entry name with
subroutine name.

2018-03-15  Steven G. Kargl  

PR fortran/78741
* gfortran.dg/pr78741.f90: New test.

Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/78741] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1534

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78741

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Mar 16 03:28:08 2018
New Revision: 258582

URL: https://gcc.gnu.org/viewcvs?rev=258582=gcc=rev
Log:
2018-03-15  Steven G. Kargl  

PR fortran/78741
* decl.c (get_proc_name):  Check for clash of entry name with
subroutine name.

2018-03-15  Steven G. Kargl  

PR fortran/78741
* gfortran.dg/pr78741.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr78741.f90
Modified:
branches/gcc-7-branch/gcc/fortran/decl.c

[Bug fortran/69395] ICE on declaring array with more than 7 dimensions+codimensions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69395

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

[Bug fortran/78741] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1534

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78741

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

[Bug fortran/78741] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1534

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78741

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Mar 16 02:56:34 2018
New Revision: 258581

URL: https://gcc.gnu.org/viewcvs?rev=258581=gcc=rev
Log:
2018-03-15  Steven G. Kargl  

PR fortran/78741
* decl.c (get_proc_name):  Check for clash of entry name with
subroutine name.

2018-03-15  Steven G. Kargl  

PR fortran/78741
* gfortran.dg/pr78741.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr78741.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889

--- Comment #2 from David Malcolm  ---
Hacker News user "earenndil" suggested:

> What about a line of ─ in between different unassociated errors?
> So if there is a group of related errors that are about the same actual
> problem, or a note associated with an error, they're together, but then
> there's a line of coloured ─ separating them from the next set.

It feels worth prototyping, at least, for gcc 9.

[Bug fortran/69395] ICE on declaring array with more than 7 dimensions+codimensions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69395

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Mar 16 02:43:02 2018
New Revision: 258580

URL: https://gcc.gnu.org/viewcvs?rev=258580=gcc=rev
Log:
2018-03-15  Steven G. Kargl  

PR fortran/69395
* decl.c (merge_array_spec): Limit the merging to maximum allowed
dimensions, and issue error message if limit is exceeded.

2018-03-15  Steven G. Kargl  

PR fortran/69395
* gfortran.dg/pr69395.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr69395.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84898] New: Fix-it hints for '.' vs '->'

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84898

Bug ID: 84898
   Summary: Fix-it hints for '.' vs '->'
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Reddit user "Boojum" suggested:

> [...] Clang offers fix-its for both errors and gets the symmetry correct:

% cat deref.cpp
struct foo { float x; };
float bar(foo f) {
return f->x;
}
float baz(foo* f) {
return f.x;
}
% g++72 deref.cpp
deref.cpp: In function ‘float bar(foo)’:
deref.cpp:3:13: error: base operand of ‘->’ has non-pointer type ‘foo’
 return f->x;
 ^~
deref.cpp: In function ‘float baz(foo*)’:
deref.cpp:6:14: error: request for member ‘x’ in ‘f’, which is of pointer type
‘foo*’ (maybe you meant to use ‘->’ ?)
 return f.x;
  ^
% clang-6.0 deref.cpp
deref.cpp:3:13: error: member reference type 'foo' is not a pointer; did you
mean to use '.'?
return f->x;
   ~^~
.
deref.cpp:6:13: error: member reference type 'foo *' is a pointer; did you mean
to use '->'?
return f.x;
   ~^
->
2 errors generated.

[Bug c++/84898] Fix-it hints for '.' vs '->'

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84898

--- Comment #1 from David Malcolm  ---
Note how clang offers fix-it hints (we don't); I also prefer the clang wording.

[Bug c++/84897] Better handling of unqualified "string"

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84897

--- Comment #1 from Andrew Pinski  ---
Rather we should not report the inline namespace __cx11 .I suspect you can come
up with a shorter t estcase which does not use any includes.

[Bug c++/84897] New: Better handling of unqualified "string"

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84897

Bug ID: 84897
   Summary: Better handling of unqualified "string"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Reddit user "Boojum" suggested:

> As far as other paper cuts, here's one that catches me
> surprisingly frequently:

#include 
int main() {
string x("foo");
}

> Obviously, I "forgot" to either qualify string as std::string,
> add using namespace std;, or add using std::string;.
>
> Here's what GCC 7.2 tells me (header paths elided):

namespace.cpp: In function ‘int main()’:
namespace.cpp:3:5: error: ‘string’ was not declared in this scope
 string x("foo");
 ^~
namespace.cpp:3:5: note: suggested alternatives:
In file included from .../string:39:0,
 from namespace.cpp:1:
.../stringfwd.h:74:33: note:   ‘std::__cxx11::string’
   typedef basic_stringstring;
 ^~
.../stringfwd.h:74:33: note:   ‘std::__cxx11::string’

> On the other hand, here's what Clang 6 tells me:

namespace.cpp:3:5: error: unknown type name 'string'; did you mean
'std::string'?
string x("foo");
^~
std::string
.../stringfwd.h:74:33: note: 'std::string' declared here
  typedef basic_stringstring;
^
1 error generated.

> Much nicer. It tells me exactly which namespace I probably
> meant to use and proposes a fix-it qualifying the identifier.

I hope to fix this for gcc 9.

I'm not yet sure if we want to:
(a) look in "std" when handling such errors (which requires the user to have
included the pertinent header), or
(b) to special-case important "std::" names like "string", or
(c) both
(d) rework the priority of the "look in namespaces" search relative to our
other heuristics
...etc

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[kevinb at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #16 from Kevin Buettner  ---
Created attachment 43671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43671=edit
GDB patch - dwarf2read.c

I've attached the GDB patch that I'm currently testing.  When I try it against
either Jakub's test case or in the one that I only slightly simplified, I find
that I can step into foo() as expected.

I see no regressions when testing against the GDB testsuite using either

1) /bin/gcc on my Fedora 23 machine

or

2) A build of GCC using recent development sources

However, if I use #2 along with -O2, I see some apparent regressions.  I say
"apparent" because the ones that I've investigated so far aren't really
regressions.  It turns out that -O2 causes much of the initial part of the
function (upon which a breakpoint is being set) to be optimized away and having
an extra breakpoint on the .cold location will sometimes cause GDB to consider
a test with a "continue" to be a success due to being able to hit some other
breakpoint, even if it's not at the correct line/location. (Yes, these tests
should probably be revised so that doesn't happen. That said, the gdb testsuite
doesn't really work very well with everything compiled with -O2 anyway.)

[Bug c++/84896] New: Better handling of missing for std::pair

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84896

Bug ID: 84896
   Summary: Better handling of missing  for std::pair
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

gcc 8 currently emits the following for:

  std::pair foo;

error: 'pair' in namespace 'std' does not name a template type
 std::pair foo;
  ^~~~

We ought to suggest including  for this, and probably various other
stdlib templates.

[Bug c++/84895] Smarter suggestions for "private" accessor hints

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84895

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c/84887] missing semicolon: further improvements

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887

--- Comment #1 from David Malcolm  ---
Similarly, in :

  int i
  int j;

as of gcc 8 we now print:

q.c:1:6: error: expected ‘;’ before ‘int’
 int i
  ^
  ;
 int j;
 ~~~

User "jancsika" on Hacker News points out:
> [...] the output is visually confusing-- you have an arrow pointing one's
> eye to the missing semicolon, but the underlined referent token is
> two line  breaks away from it. Underlining the preceding "i" would put
> the emphasized token and missing semi right next to each other.

and I agree, presumably we should print either just:

q.c:1:6: error: expected ‘;’ after ‘i’
 int i
  ^

or:

q.c:1:6: error: expected ‘;’ after ‘i’
 int i
 ~^

[Bug c++/84895] New: Smarter suggestions for "private" accessor hints

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84895

Bug ID: 84895
   Summary: Smarter suggestions for "private" accessor hints
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In a discussion about g++ 8's ability to suggest accessor fix-it hints for
erroneous uses of private fields, Hacker News user "vmarsy" commented:

> I wonder how smart it is.
> For instance in the following example:

class foo
{
public:
  std::pair get_coordinates() const
  {
return std::make_pair(m_x, m_y);
  }

private:
  int m_x;
  int m_y;
};


void test(foo *ptr)
{
  if (ptr->m_x >= 3)
;// etc
}

> I wonder if the compiler would be able to figure out that m_x is
> accessible via `ptr->get_coordinates().first` ?

It isn't yet, but that's probably implementable (hence this bug), though I
wonder how much we want to do so, and if it would all be special-cases for
idiomatic C++ constructions?  Are there other examples?

[Bug c++/80886] __builtin_constant_p magic has broken at some point

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80886

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||6.4.0
Version|unknown |7.3.1
  Known to fail||7.3.0, 8.0.1

--- Comment #1 from Jonathan Wakely  ---
I can't reproduce this with GCC 6, but can with GCC 7:


un.cc:3:55: error: value '4096' of type 'void*' is not a constant expression
 constexpr void *phardware {CONST ((void *) 0x1000)};
   ^

and with trunk:


un.cc:3:39: error: reinterpret_cast from integer to pointer
 constexpr void *phardware {CONST ((void *) 0x1000)};
   ^~~
un.cc:1:45: note: in definition of macro 'CONST'
 #define CONST(x) (__builtin_constant_p(x) ? x : x)
 ^

[Bug rtl-optimization/78778] non-atomic load moved to before atomic load with std::memory_order_acquire

[erik at rigtorp dot se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78778

--- Comment #4 from Erik Rigtorp  ---
Looks like this was fixed in trunk: https://godbolt.org/g/nxGRdm

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889

--- Comment #1 from David Malcolm  ---
Example of Rust error (showing colorization):
  https://i.redd.it/qm4oceuuckyy.png

[Bug fortran/84894] New: [F2018] provide iso_fortran_binding.h

[damian at sourceryinstitute dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894

Bug ID: 84894
   Summary: [F2018] provide iso_fortran_binding.h
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

Fortran 2018 requires that compilers provide an iso_fortran_binding.h C header
file for further interoperability with C.   Such a file was on the fortran-dev
branch in 2013:

https://gcc.gnu.org/viewcvs/gcc/branches/fortran-dev/libgfortran/ISO_Fortran_binding.h.tmpl?=markup#l1

This bug is being submitted to track progress and interest in this feature and
to preserve a link to the above file as a potential starting point.  The lack
of iso_fortran_bindin.h currently blocks MPICH 3.2 from providing gfortran
users the mpi_f08 module that the MPI 3.1 standard requires.

Damian

[Bug fortran/41897] Support TS 29113: "Further Interoperability of Fortran with C"

[damian at sourceryinstitute dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41897

--- Comment #3 from Damian Rouson  ---
With Fortran 2018 now in Committee Draft (CD) and likely to be published this
year, it probably makes sense to close this bug report.  Any features from TS
29113 that will be in Fortran 2018 have already been incorporated into the CD
and it's possible that the integration process could have led to changes so the
CD would be the more appropriate reference now rather than the TS.

[Bug fortran/84885] c_char bind length

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885

--- Comment #4 from Steve Kargl  ---
On Thu, Mar 15, 2018 at 09:57:08PM +, mdblack98 at yahoo dot com wrote:
> 
> --- Comment #3 from mdblack98 at yahoo dot com ---
> I'll correct my reply in that using len > 1 outside of an interoperability
> block is OK.
> 
> So it is apparently now impossible to declare c_char len > 1 inside such a
> block?
> 

Steve Lionel is correct.  If you have a BIND(C) entity
and it involves the character type, then the length
parameter must be 1.  I quoted from a draft of the
upcoming F2018, because that is what I had at hand.  The
Fortran 2003 standard has essentially the same language:

F2003, page 398

   A Fortran derived type is interoperable with a C
   struct type if the derived-type definition of the Fortran
   type specifies BIND(C) (4.5.1), the Fortran derived type
   and the C struct type have the same number of components,
   and the components of the Fortran derived type have types
   and type parameters that are interoperable with the types
   of the corresponding components of the struct type.

Fortran 2003, page 396

   ...; if the type is character, interoperability also requires
   that the length type parameter be omitted or be specified
   by an initialization expression whose value is one.

You can specify an array of characters, e.g.,

type, bind(c) :: foo
   character(kind=c_char, len=1) :: c(10)
end type foo

PS: The name of the language is Fortran.  It hasn't been
written in all capital letters since 1990.

[Bug c++/84893] New: Rejects a valid code with variadic function template taking a function pointer

[v.reshetnikov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84893

Bug ID: 84893
   Summary: Rejects a valid code with variadic function template
taking a function pointer
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.reshetnikov at gmail dot com
  Target Milestone: ---

The following C++ code is rejected by GCC 8.0.1 20180313 (tested with
https://godbolt.org/):

/* SOURCE */
template
void f(void(*)(T..., int)) { }

void g(bool, int) { }

int main() {
f(g);
}
/*** END SOURCE ***/


/* OUTPUT */
: In function 'int main()':
:7:14: error: no matching function for call to 'f(void (&)(bool,
int))'
 f(g);
  ^
:2:6: note: candidate: 'template void f(void (*)(T ...,
int))'
 void f(void(*)(T..., int)) { }
  ^
:2:6: note:   template argument deduction/substitution failed:
:7:14: note:   mismatched types 'int' and 'bool'
 f(g);
  ^
Compiler returned: 1
/*** END OUTPUT ***/

I believe the code is valid and should be compiled successfully.

[Bug fortran/82992] ICE in create_int_parameter_array, at fortran/module.c:6586

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82992

--- Comment #3 from Harald Anlauf  ---
The ICE on invalid is solved.  The invalid code still needs to be detected.

NAG complains:

NAG Fortran Compiler Release 6.1(Tozai) Build 6106
Error: pr82992.f90, line 2: Name clash between dummy argument X and symbol from
USE ISO_FORTRAN_ENV
   detected at CHARACTER_KINDS@

[Bug c++/84892] New: Missing accessor hint for private field

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84892

Bug ID: 84892
   Summary: Missing accessor hint for private field
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Reddit user "evaned" reports that we fail to offer a fix-it hint code
suggesting the "get_field" accessor on this code:
https://godbolt.org/g/y2cbuv


class S {
private:
bool field;

public:
bool get_field() const {
return field;
}
};

bool thingy(const S & s) {
  return s.field;
}


Removing the "const" from "thingy" seems to fix it.

[Bug fortran/84885] c_char bind length

[mdblack98 at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885

--- Comment #3 from mdblack98 at yahoo dot com ---
I'll correct my reply in that using len > 1 outside of an interoperability
block is OK.

So it is apparently now impossible to declare c_char len > 1 inside such a
block?


Mike

[Bug fortran/84885] c_char bind length

[mdblack98 at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885

--- Comment #2 from mdblack98 at yahoo dot com ---
I got what's below from Steve Lionel of the FORTRAN working groupWith what
he said you flat should NOT be able to say anything other than LEN=1 for
c_char.  Whether it's in a type block or not.So the question becomes how to do
this...since this is likely to break a bit of FORTRAN code out in the
wild...like oursIt would appear you can't put a char array of any kind of
type block which we use for shared memory.

From Steve:
However, I don't see that Fortran 2018 has anything to do with this. The code
you show does not conform to Fortran 2003, which was the first revision to have
C interoperability. The issue is that in an interoperable type (a type declared
with BIND(C)), any entity of type CHARACTER must have length 1, because C
doesn't have the concept of character lengths. Instead you would make c here a
10-element array of single characters. It's ok outside of the type because
you're not declaring something interoperable then.

 Similarly, a dummy argument to an interoperable procedure can't have a
character length other than 1 up through Fortran 2008. In Fortran 2018, you're
allowed to use CHARACTER(*), but that requires that the corresponding C code
pass or accept a "C descriptor".

 That earlier versions of gcc allowed this to compile would be a bug in those
older versions.

--- 
Michael D. Black 

On Thursday, March 15, 2018, 11:42:40 AM CDT, kargl at gcc dot gnu.org
 wrote:  

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885

kargl at gcc dot gnu.org changed:

          What    |Removed                    |Added

            Status|UNCONFIRMED                |RESOLVED
                CC|                            |kargl at gcc dot gnu.org
        Resolution|---                        |INVALID

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to mdblack98 from comment #0)
> subroutine foo(i,c)
>  use, intrinsic :: iso_c_binding, only: c_char
>        integer i
> 
>  type, bind(C) :: params_block
>        character(kind=c_char,len=10) :: c

I see length of 10 here.

>  end type params_block
>        write(*,*) 'X',c,'Z'
> end
> 
> This program fails to compile with gcc 8.0.1 20180304 -- but only if the
> character declaration is inside a type block
> Compiles fine with pre 8.0 compilers
> 
> gfortran -fPIC -g -c foo.f90
> foo.f90:6:42:
> 
>          character(kind=c_char,len=10) :: c
>                                          1
> Error: Component 'c' of BIND(C) type at (1) must have length one

From the F2018 standard,

18.3.2 Interoperability of intrinsic types

Table 18.2 shows the interoperability between Fortran intrinsic
types and C types.  A Fortran intrinsic type with particular type
parameter values is interoperable with a C type if the type and
kind type parameter value are listed in the table on the same row
as that C type.  If the type is character, the length type parameter
is interoperable if and only if its value is one.


C1806 (R726) Each component of a derived type with the BIND
attribute shall be a nonpointer, nonallocatable data component
with interoperable type and type parameters.

Your code is invalid, and the number constraint means
that gfortran must tell you about it.

[Bug c++/84891] New: -fno-signed-zeros leads to optimization which should be possible only if also -ffinite-math-only is on

[no...@turm-lahnstein.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891

Bug ID: 84891
   Summary: -fno-signed-zeros leads to optimization which should
be possible only if also -ffinite-math-only is on
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: no...@turm-lahnstein.de
  Target Milestone: ---

Please consider the following example

   #include 
   #include 
   #include 

   std::complex mult(std::complex c, double im){
   std::complex jomega(0.0, im);
   return c*jomega;
   }


   int main(){
 //(-nan,-nan) expected:
 std::cout<<"case INF:
"<

[Bug c++/79085] [6/7 Regression] ICE with placement new to unaligned location

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |placement new to unaligned  |placement new to unaligned
   |location|location

--- Comment #10 from Jakub Jelinek  ---
Fixed for 8.1+ so far.

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 15 21:09:24 2018
New Revision: 258574

URL: https://gcc.gnu.org/viewcvs?rev=258574=gcc=rev
Log:
PR c++/79085
* calls.c (expand_call): For TREE_ADDRESSABLE rettype ignore alignment
check and use address of target always.

* g++.dg/opt/pr79085.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr79085.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog

[Bug c/84890] New: Overly verbose notes for missing headers

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890

Bug ID: 84890
   Summary: Overly verbose notes for missing headers
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As of gcc 8:

incomplete.c:4:17: error: ‘INT_MAX’ undeclared (first use in this function)
 int limit = INT_MAX;
 ^~~
incomplete.c:4:17: note: ‘INT_MAX’ is defined in header ‘’; did you
forget to ‘#include ’?

Reddit user "ramennoodle" comments:

> This seems redundantly verbose. Why not just:
> 
> incomplete.c:4:17: note: ‘INT_MAX’ is defined in header ‘
> 
> ?

I agree it's verbose, but maybe we should instead just lose the first part of
the note, and print:

incomplete.c:4:17: error: ‘INT_MAX’ undeclared (first use in this function)
 int limit = INT_MAX;
 ^~~
incomplete.c:4:17: note: did you forget to ‘#include ’?

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug other/84889] New: Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889

Bug ID: 84889
   Summary: Ideas on revamping how we format diagnostics
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: other
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Rust's compiler has some interesting ideas for printing diagnostics, which I
want to look at for gcc 9

Quoting an example from:
 
https://stackoverflow.com/questions/44003622/implementing-trait-for-fnsomething-in-rust

(hopefully not too badly mangled by bugzilla)

BEGIN QUOTE:

error[E0271]: type mismatch resolving `for<'r> <[closure@:30:27: 32:10]
as std::ops::FnOnce<(&'r i32,)>>::Output == ()`
  --> :30:26
   |
30 |   run_the_runnable(&|x| {
   |  __^ starting here...
31 | | println!("Hello from run() closure {}", x);
32 | | }, );
   | |_^ ...ending here: expected bound lifetime parameter , found
concrete lifetime
   |
   = note: concrete lifetime that was found is lifetime '_#63r
   = note: required because of the requirements on the impl of `Runnable` for
`[closure@:30:27: 32:10]`
   = note: required for the cast to the object type `Runnable`

error[E0281]: type mismatch: the type `[closure@:30:27: 32:10]`
implements the trait `std::ops::Fn<(_,)>`, but the trait `for<'r>
std::ops::Fn<(&'r i32,)>` is required (expected concrete lifetime, found bound
lifetime parameter )
  --> :30:26
   |
30 |   run_the_runnable(&|x| {
   |  __^ starting here...
31 | | println!("Hello from run() closure {}", x);
32 | | }, );
   | |_^ ...ending here
   |
   = note: required because of the requirements on the impl of `Runnable` for
`[closure@:30:27: 32:10]`
   = note: required for the cast to the object type `Runnable`

END QUOTE

Things I like about this:

* line numbers within the quoted source code, which:
  (a) make it easier to determine what is the quoted code,
  and what is a message from the compiler
  (b) make it easier to find the code in question

* the diagnostic and the followup notes are grouped, so it's easier to pick out
what messages relate to what

* there's a trailing blank line, after each diagnostic+notes group, helping the
above, and breaking up the "wall of text" effect

* ASCII art showing the interactions between two pieces of code

IIRC, clang does something where the left-hand column is only non-empty for the
start of a diagnostic; followup lines (e.g. due to line wrapping) are indented
by 1 char, so that the "wall of text" is broken up somewhat

We might want to revisit our current colorization choices.

Naturally if we make any major changes to how we output diagnostics we'd want a
compatibility option for people using IDEs that expect the existing format

How the above might interact e.g. with printing header file inclusion chains
etc etc would need to be thought through.

[Bug c++/66672] std::is_same wrong result for captured reference value inside a lambda

[anders at knatten dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66672

--- Comment #4 from Anders Schau Knatten  ---
Update: There's a related issue with Clang, in which Richard Smith makes a good
argument: https://bugs.llvm.org/show_bug.cgi?id=35423#c2

He refers to http://eel.is/c++draft/expr.prim.id.unqual#2.sentence-2, of which
I was previously unaware, which seems to cover what was previously covered by
§5.1.2¶18 in C++11. It says:

"If the entity is a local entity and naming it from outside of an unevaluated
operand within the declarative region where the unqualified-id appears would
result in some intervening lambda-expression capturing it by copy
([expr.prim.lambda.capture]), the type of the expression is the type of a class
member access expression ([expr.ref]) naming the non-static data member that
would be declared for such a capture in the closure object of the innermost
such intervening lambda-expression."

If I read that passage correctly, it says that "even if decltype doesn't
odr-use the identifier, and thus it isn't actually captured, the type of the
expression is still as if it had been captured."

So I now believe my previous comment was wrong, and that gcc is wrong both
according to C++11 and the current draft.

[Bug c/84888] C/C++: Improve wording of unclosed paren/brace

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84888

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c/84888] New: C/C++: Improve wording of unclosed paren/brace

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84888

Bug ID: 84888
   Summary: C/C++: Improve wording of unclosed paren/brace
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As noted by oridb on reddit:

> I also find the large, visually complex error messages confusing to
> read. For example, this makes me skim and see 3 separate errors:
> 
> t.c: In function ‘log_when_out_of_range’:
> t.c:12:50: error: expected ‘)’ before ‘{’ token
> && (temperature < MIN || temperature > MAX) {
>   ^~
>   )
> unclosed.c:11:6: note: to match this ‘(’
>if (logging_enabled && check_range ()
>   ^
> I'd rather see something like this (although, I admit the phrasing could use 
> work):
> 
> t.c:12:50: error: expected ')' for unclosed '(' on t.c:11:6
> && (temperature < MIN || temperature > MAX) {
>   ^~
>   )

I much prefer oridb's proposed wording to what we have now (in gcc 8), though
I'd prefer to keep the note; I'll open another bug with some ideas I have about
making multiple diagnostics easier on the eye.

Maybe (brainstorming here):

If it's on the same line:

  t.c:12:50: error: expected ')' for unclosed '(' on column 6

If it's in the same file:

  t.c:12:50: error: expected ')' for unclosed '(' at line 11 column 6

If it's in a different file:

t.c:12:50: error: expected ')' for unclosed '(' at other.c:11:6

(Or maybe it's better to always give the same format, to make it easier for
IDEs to parse?)

[Bug c++/81392] Improve diagnostics for [[fallthrough]] attribute that is missing a semicolon

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81392

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c/84887] New: missing semicolon: further improvements

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887

Bug ID: 84887
   Summary: missing semicolon: further improvements
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic, error-recovery
  Severity: normal
  Priority: P3
 Component: c
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Consider:

int test(void)
{
  return 42
}

Prior to gcc 8 we emitted:

t.c: In function ‘test’:
t.c:4:1: error: expected ‘;’ before ‘}’ token
 }
 ^

As of gcc 8 we now emit the error at the correct location:

t.c: In function ‘test’:
t.c:3:12: error: expected ‘;’ before ‘}’ token
   return 42
^
;
 }
 ~

(this was PR 65137 and others)

However, as suggested e.g. by oridb on Reddit, it would be more readable to
talk about the previous logical unit, and emit:

t.c: In function ‘test’:
t.c:3:12: error: expected ‘;’ after ‘42’ token
   return 42
^
;

or somesuch: e.g. should we highlight the preceding token as a secondary range,
which would give:

t.c: In function ‘test’:
t.c:3:12: error: expected ‘;’ after ‘42’ token
   return 42
  ~~^
;

(I'm not sure either way)

[Bug c++/65137] wrong line for missing semicolon after expression

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65137

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||dmalcolm at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #1 from David Malcolm  ---
As of gcc 8, we now emit the diagnostic at the correct location:

C:

/tmp/test.c: In function ‘foo’:
/tmp/test.c:3:6: error: expected ‘;’ before ‘return’
   a++
  ^
  ;
   return 0;
   ~~

C++:

/tmp/test.c: In function ‘int foo(int)’:
/tmp/test.c:3:6: error: expected ‘;’ before ‘return’
   a++
  ^
  ;
   return 0;
   ~~
/tmp/test.c:5:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^

[Bug c/82013] better error message for missing semicolon in prototype

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82013

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Survey Invite] Take 8-min research survey and win a lottery ticket to compete for an Amazon $100 credit

[amcgitirana]

I've invited you to fill out the following form:
Professional Profile

To fill it out, visit:
https://docs.google.com/forms/d/e/1FAIpQLSfQTZkrylE1t49gjzewPQSPWHFnPtGCZfRujg_G8VTwqGrbHg/viewform?c=0w=1usp=mail_form_link

Dear friend,

I am a masters student in Computer Science at the Federal University  
of Bahia, Salvador, Brazil, under the advising of Dr. Eduardo Almeida.


We chose you because you participated in one of the open source projects  
included in this study. All the information provided will be kept  
confidential. We have no intention to judge your work since we are merely  
interested in learning about some aspects of your work.


We are investigating the bug report duplication problem, so based on your  
experience using bug-trackers, we would like to invite you to participate  
in a short 8-10 minute survey that our research group is conducting to get  
opinion about this subject.



Please, return it until March 31st, 2018. We will offer a lottery ticket to  
compete for an Amazon $100 credit and the results of the study when we  
finished the analysis.



We appreciate your time!

Best Regards,

Alexandre Gitirana

Google Forms: Create and analyze surveys.

[Bug other/44032] internals documentation is not legally safe to use

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
Is this fixed in the same way that bug 44035 was fixed?

[Bug libfortran/84880] [8 Regression] libgfortran fail to build on aarch64/arm 32bit cross toolchain

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84880

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Jakub Jelinek  ---
Fixed.

[Bug other/44033] The target hook documentation is chronically out-of-sync with the facts

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44033
Bug 44033 depends on bug 44035, which changed state.

Bug 44035 Summary: internals documentation cannot be fixed without new GFDL 
license grants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44035

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c++/84222] [6/7 Regression] [[deprecated]] class complains about internal class usage

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84222

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression]  |[6/7 Regression]
   |[[deprecated]] class|[[deprecated]] class
   |complains about internal|complains about internal
   |class usage |class usage

--- Comment #9 from Jakub Jelinek  ---
Fixed for 8.1+.

[Bug other/44035] internals documentation cannot be fixed without new GFDL license grants

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44035

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Eric Gallager  ---
(In reply to Jorn Wolfgang Rennecke from comment #7)
> (In reply to jos...@codesourcery.com from comment #6)
> > Since we have docstring relicensing maintainers, I don't think this is an 
> > issue now.
> 
> Oops, that slipped my mind.  Indeed, we can consider this arrangement
> to have fixed this issue.

k, FIXED.

[Bug libfortran/84880] [8 Regression] libgfortran fail to build on aarch64/arm 32bit cross toolchain

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84880

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 15 18:04:59 2018
New Revision: 258571

URL: https://gcc.gnu.org/viewcvs?rev=258571=gcc=rev
Log:
PR libgfortran/84880
* intrinsics/kill.c (kill): Rename to...
(PREFIX (kill)): ... this.  Use export_proto_np instead of
export_proto.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/kill.c

[Bug target/84574] Function return thunks shouldn't be aliased to indirect branch thunks

[hjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84574

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Mar 15 17:54:40 2018
New Revision: 258569

URL: https://gcc.gnu.org/viewcvs?rev=258569=gcc=rev
Log:
i386: Don't generate alias for function return thunk

Function return thunks shouldn't be aliased to indirect branch thunks
since indirect branch thunks are placed in COMDAT section and a COMDAT
section with indirect branch may not have function return thunk.  This
patch generates function return thunks directly.

gcc/

PR target/84574
* config/i386/i386.c (indirect_thunk_needed): Update comments.
(indirect_thunk_bnd_needed): Likewise.
(indirect_thunks_used): Likewise.
(indirect_thunks_bnd_used): Likewise.
(indirect_return_needed): New.
(indirect_return_bnd_needed): Likewise.
(output_indirect_thunk_function): Add a bool argument for
function return.
(output_indirect_thunk_function): Don't generate alias for
function return thunk.
(ix86_code_end): Call output_indirect_thunk_function to generate
function return thunks.
(ix86_output_function_return): Set indirect_return_bnd_needed
and indirect_return_needed instead of indirect_thunk_bnd_needed
and indirect_thunk_needed.

gcc/testsuite/

PR target/84574
* gcc.target/i386/ret-thunk-9.c: Expect __x86_return_thunk
label instead of __x86_indirect_thunk label.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/ret-thunk-9.c

[Bug libstdc++/84886] New: Add static checking to library components

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84886

Bug ID: 84886
   Summary: Add static checking to library components
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

There are several places where we could diagnose undefined behaviour:

#include 
const std::array a0{};
int i0 = a0[0];  // undefined
const std::array a1{};
int i1 = a1[1];  // undefined


#include 
const std::string_view s;
char c0 = s[0];  // undefined
char c1 = s.front(); // undefined
// not even in constant expressions:
constexpr std::string_view s1("a");
constexpr char c2 = s1[1];   // undefined

#include 
int main() {
  std::atomic a{};
  a.load(std::memory_order_release);  // undefined
}

These can be turned into compile-time errors:
https://gcc.gnu.org/ml/libstdc++/2018-03/msg00031.html
https://gcc.gnu.org/ml/libstdc++/2018-03/msg00032.html

For std::array we need to ensure explicit instantiation works, without
operator[] causing errors.

[Bug c++/84222] [6/7/8 Regression] [[deprecated]] class complains about internal class usage

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84222

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 15 17:45:01 2018
New Revision: 258568

URL: https://gcc.gnu.org/viewcvs?rev=258568=gcc=rev
Log:
PR c++/84222
* cp-tree.h (cp_warn_deprecated_use): Declare.
* tree.c (cp_warn_deprecated_use): New function.
* typeck2.c (build_functional_cast): Use it.
* decl.c (grokparms): Likewise.
(grokdeclarator): Likewise.  Temporarily push nested class scope
around grokparms call for out of class member definitions.

* g++.dg/warn/deprecated.C (T::member3): Change dg-warning to dg-bogus.
* g++.dg/warn/deprecated-6.C (T::member3): Likewise.
* g++.dg/warn/deprecated-13.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/deprecated-13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/deprecated-6.C
trunk/gcc/testsuite/g++.dg/warn/deprecated.C

[Bug c/55976] -Werror=return-type should error on returning a value from a void function

[lopezibanez at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976

--- Comment #7 from Manuel López-Ibáñez  ---
My advice would be to create a new option Wreturn-pedantic. Make this
option control the pedwarns that don't have any option. Then, enable it by
default, but also make it be enabled by Wpedantic and Wreturn-type.

An alternative would be to have the default setting of Wreturn-type depend
on flag_isoc99. Then, add OPT_Wreturn_type to all those pedwarns.

On Thu, 15 Mar 2018, 16:12 dave.pagan at oracle dot com, <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976
>
> --- Comment #6 from Dave Pagan  ---
> Helpful update, Jonathan - did you want to follow up on this bug then? Or
> should I go ahead based on your new information?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug tree-optimization/84841] [7/8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84841

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Created attachment 43670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43670=edit
gcc8-pr84841.patch

Untested fix.  The problem actually aren't the multiple REAL_CSTs, but the
artificial -1.0 added by try_special_add_to_ops which isn't reflected in the
original IL.  We rely on that one to be merged with other constants.
And, const_binop generally fails only for inexact computations, multiplication
by -1.0 or 1.0 should never be inexact.  So this patch just makes sure we sort
-1.0 (and 1.0 which has similar properties) last.

Another possibility would be to try harder if some const_binop fails, up to
O(n^2) attempts where n is the number of REAL_CSTs at the end of the ops list.
Even with -frounding-math or the IBM long double, we can be successful with
some foldings and not others.  Is that worth it though?

And, seems the sorting wasn't matching the comment:
/* We want integer ones to end up last no matter what, since they are
   the ones we can do the most with.  */
I must say I fail to see when we'd have constants of different types in the
same ops list, but the documentation says sort integers (i.e. the highest
constant_type values) last, but sorting function did the opposite.

[Bug go/84765] "cmd/go/internal/work/buildid.go" breaks for various non-English locales

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84765

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Ian Lance Taylor  ---
Thanks for the report.  I just committed a patch to fix this.

[Bug fortran/84885] c_char bind length

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to mdblack98 from comment #0)
> subroutine foo(i,c)
>   use, intrinsic :: iso_c_binding, only: c_char
> integer i
> 
>   type, bind(C) :: params_block
> character(kind=c_char,len=10) :: c

I see length of 10 here.

>   end type params_block
> write(*,*) 'X',c,'Z'
> end
> 
> This program fails to compile with gcc 8.0.1 20180304 -- but only if the
> character declaration is inside a type block
> Compiles fine with pre 8.0 compilers
> 
> gfortran -fPIC -g -c foo.f90
> foo.f90:6:42:
> 
>  character(kind=c_char,len=10) :: c
>   1
> Error: Component 'c' of BIND(C) type at (1) must have length one

From the F2018 standard,

18.3.2 Interoperability of intrinsic types

Table 18.2 shows the interoperability between Fortran intrinsic
types and C types.  A Fortran intrinsic type with particular type
parameter values is interoperable with a C type if the type and
kind type parameter value are listed in the table on the same row
as that C type.  If the type is character, the length type parameter
is interoperable if and only if its value is one.


C1806 (R726) Each component of a derived type with the BIND
attribute shall be a nonpointer, nonallocatable data component
with interoperable type and type parameters.

Your code is invalid, and the number constraint means
that gfortran must tell you about it.

[Bug target/84882] -mstrict-align on aarch64 should not be RejectNegative

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84882

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-15
 CC||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Wilco  ---
(In reply to Jakub Jelinek from comment #0)
> -mno-strict-align works on all targets that support -mstrict-align option,
> except aarch64.  Any reason for the RejectNegative in there?  From what I
> can see, it isn't the default on aarch64, and there is no way to undo an
> earlier flag on command line.

Confirmed, it doesn't make any sense. There are more options that should have
the no- variant enabled, eg. -mno-general-regs-only.

[Bug other/44035] internals documentation cannot be fixed without new GFDL license grants

[amylaar at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44035

--- Comment #7 from Jorn Wolfgang Rennecke  ---
(In reply to jos...@codesourcery.com from comment #6)
> Since we have docstring relicensing maintainers, I don't think this is an 
> issue now.

Oops, that slipped my mind.  Indeed, we can consider this arrangement
to have fixed this issue.

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84876

--- Comment #3 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #2)
> Sorry, my bad.  It is easy to fix.  I think the patch will be ready today.

Unfortunately, this test also triggers more serious problem of my last patch
(r258504) which results in LRA cycling.  I think it will some time to fix the
problem but I hope it will be done on this week.

[Bug tree-optimization/84841] [7/8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84841

--- Comment #5 from Jakub Jelinek  ---
On the other side, the assumption that +/* of two REAL_CSTs can be always
folded isn't false just for -frounding-math, but also e.g. with IBM long double
(aka composite mode) and no -funsafe-math-optimizations.  So e.g.
long double
foo (long double x, long double y)
{
  long double a = 10e50;
  long double b = 10e-50;
  a = a + b;
  a = a + x;
  a = a + y;
  return a;
}
with -mlong-double-128 -O2 -fassociative-math -fno-trapping-math
-fno-signed-zeros --param tree-reassoc-width=2
also has 2 REAL_CSTs in there that can't be folded together.

[Bug c/55976] -Werror=return-type should error on returning a value from a void function

[dave.pagan at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976

--- Comment #6 from Dave Pagan  ---
Helpful update, Jonathan - did you want to follow up on this bug then? Or
should I go ahead based on your new information?

[Bug c/39808] warn_unused_result fails to produce warning in a statement expression

[dave.pagan at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39808

Dave Pagan  changed:

   What|Removed |Added

 CC||dave.pagan at oracle dot com

--- Comment #5 from Dave Pagan  ---
Anyone looking at this? If not, I'd like to.

[Bug fortran/84885] New: c_char bind length

[mdblack98 at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885

Bug ID: 84885
   Summary: c_char bind length
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mdblack98 at yahoo dot com
  Target Milestone: ---

subroutine foo(i,c)
  use, intrinsic :: iso_c_binding, only: c_char
integer i

  type, bind(C) :: params_block
character(kind=c_char,len=10) :: c
  end type params_block
write(*,*) 'X',c,'Z'
end

This program fails to compile with gcc 8.0.1 20180304 -- but only if the
character declaration is inside a type block
Compiles fine with pre 8.0 compilers

gfortran -fPIC -g -c foo.f90
foo.f90:6:42:

 character(kind=c_char,len=10) :: c
  1
Error: Component 'c' of BIND(C) type at (1) must have length one

Mike

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085

--- Comment #8 from Thomas Preud'homme  ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 43668 [details]
> gcc8-pr79085.patch
> 
> Untested fix.

That fixes the original testcase for me. Thanks!

[Bug tree-optimization/84841] [7/8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84841

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
It is indeed a non-sensical combination, but I think last time we've determined
it isn't that easy to diagnose and/or silently fix up, the toplev.c diagnostics
can be bypassed through optimize attribute.

A quick hack out of this would be to add !flag_rounding_math to
can_reassociate_p next to flag_associative_math.

[Bug c/84852] [8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1105

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84852

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Thu Mar 15 15:39:46 2018
New Revision: 258559

URL: https://gcc.gnu.org/viewcvs?rev=258559=gcc=rev
Log:
Fix testcase for PR c/84852

gcc/testsuite/ChangeLog:
PR c/84852
* gcc.dg/fixits-pr84852-1.c: Fix filename in dg-regexp.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/gcc.dg/fixits-pr84852-1.c

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84811

--- Comment #8 from Zhendong Su  ---
> Can you please attach content of --save-temps?

$ gcctk -O3 -c --save-temps small.c
during RTL pass: dse1
small.c: In function ‘fn1’:
small.c:12:1: internal compiler error: in smallest_mode_for_size, at
stor-layout.c:355
 }
 ^
0xc9006b smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class)
../../gcc-source-trunk/gcc/stor-layout.c:355
0x1437b9c smallest_int_mode_for_size(poly_int<1u, unsigned long>)
../../gcc-source-trunk/gcc/machmode.h:842
0x1437b9c find_shift_sequence
../../gcc-source-trunk/gcc/dse.c:1701
0x1437b9c get_stored_val
../../gcc-source-trunk/gcc/dse.c:1847
0x143a4fc record_store
../../gcc-source-trunk/gcc/dse.c:1557
0x143b3a2 scan_insn
../../gcc-source-trunk/gcc/dse.c:2545
0x143c592 dse_step1
../../gcc-source-trunk/gcc/dse.c:2657
0x143c592 rest_of_handle_dse
../../gcc-source-trunk/gcc/dse.c:3574
0x143c592 execute
../../gcc-source-trunk/gcc/dse.c:3672
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 
$ cat small.i
# 1 "small.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "small.c"
int a;
long b[1][9];

void fn1 ()
{
  while (a)
{
  for (a = 0; a < 9; a++)
b[218][a] = 1;
  break;
}
}
$ cat small.s
.file   "small.c"
.text
$

[Bug c++/84884] New: [DR 2244] [C++17] protected constructor and aggregate initialization of base

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84884

Bug ID: 84884
   Summary: [DR 2244] [C++17] protected constructor and aggregate
initialization of base
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

Here we should accept f and g because we're using the protected constructor on
a base of a B object, so friendship makes it OK:

struct A {
protected:
  A();
};
struct B : A {
  friend B f();
  friend B g();
  friend B h();
};
B f() { return {}; } // ok
B g() { return {{}}; } // ok
B h() { return {A{}}; } // error

This will need significant changes to build_aggr_conv.

[Bug c/84883] New: No warning when dereferencing an array as a pointer

[tim.ruehsen at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84883

Bug ID: 84883
   Summary: No warning when dereferencing an array as a pointer
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.ruehsen at gmx dot de
  Target Milestone: ---

Created attachment 43669
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43669=edit
Small test code

It would be nice to a warning (option) if accidentally dereferencing an array
instead of a pointer.

struct BCHAN bchan[5], *bchanp = bchan + 3;
bchanp->x = 1; // that's how it's supposed to be
bchan->x = 1; // arg, typo. but now bchan[0].x has been written

I experienced this in a pretty large codebase. This was causing *very* rare
weird behavior and it's detection was more of a lucky punch.

It is certainly valid C, but what a about an -Warray-deref ?

[Bug c++/81575] [7/8 Regression] ICE on C++ code: in cp_build_addr_expr_1, at cp/typeck.c:5793

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81575

--- Comment #6 from Marek Polacek  ---
Eh, never mind the first hunk then.

[Bug c++/81575] [7/8 Regression] ICE on C++ code: in cp_build_addr_expr_1, at cp/typeck.c:5793

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81575

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Since r246954 we treat array prvalues like class prvalues.  So this
2054   if (!obvalue_p (exp)
2055   && ! (TREE_CODE (exp) == CONSTRUCTOR && TREE_STATIC (exp)))
2056 {
2057   if (complain & tf_error)
2058 error_at (loc, "invalid use of non-lvalue array");
2059   return error_mark_node;
2060 }
in decay_conversion no longer triggers because obvalue_p is now 1.
cp_build_addr_expr_1 says
If STRICT_LVALUE is true, require an lvalue; otherwise, allow xvalues
and class rvalues as well.
so I'm not sure if we should allow array rvalues too.  If not then perhaps

--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5760,7 +5760,7 @@ build_nop (tree type, tree expr)

 /* Take the address of ARG, whatever that means under C++ semantics.
If STRICT_LVALUE is true, require an lvalue; otherwise, allow xvalues
-   and class rvalues as well.
+   and class and array rvalues as well.

Nothing should call this function directly; instead, callers should use
cp_build_addr_expr or cp_build_addr_expr_strict.  */
@@ -5842,7 +5842,9 @@ cp_build_addr_expr_1 (tree arg, bool strict_lvalue,
tsubst_flags_t complain)
   && TREE_CODE (argtype) != METHOD_TYPE)
 {
   cp_lvalue_kind kind = lvalue_kind (arg);
-  if (kind == clk_none)
+  if (kind == clk_none
+ || (kind == clk_class
+ && TREE_CODE (argtype) == ARRAY_TYPE))
{
  if (complain & tf_error)
lvalue_error (input_location, lv_addressof);

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859

--- Comment #9 from Richard Biener  ---
Like moving over a const call after the stores might cause us to spill across
the call.  Moving over any stmt could enlarge lifetimes enough to do that. 
Register
lifetime could be so that we cannot coalesce the copies in the PHI (but that
probably is offset by removing one of the stores -- but maybe the fast path
is slowed down then).

value_replacement has /* Allow up to 2 cheap preparation statements that
prepare argument ... */ for example.  But I guess preparation stmts are never
of a concern?

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #8 from Richard Biener  ---
Mine.  We can handle the case of a single store in the BBs more generally and
bypass the limit.  The limit was added in r171381 where it was imposed on
all transforms when the function was changed to handle the case of more
than one stmt (store) in each BB.  Previously the transform for the single
stores case was always performed.

Thus, for example like the following.  Could be simplified somewhat iff
the stores need to be the last stmt in the BBs (like it was before said
re-org).  last_and_only_stmt isn't enough here as we have a feeding
scalar stmt around in one BB.

Opinions?

Index: gcc/tree-ssa-phiopt.c
===
--- gcc/tree-ssa-phiopt.c   (revision 258552)
+++ gcc/tree-ssa-phiopt.c   (working copy)
@@ -2061,8 +2061,6 @@ static bool
 cond_if_else_store_replacement (basic_block then_bb, basic_block else_bb,
 basic_block join_bb)
 {
-  gimple *then_assign = last_and_only_stmt (then_bb);
-  gimple *else_assign = last_and_only_stmt (else_bb);
   vec then_datarefs, else_datarefs;
   vec then_ddrs, else_ddrs;
   gimple *then_store, *else_store;
@@ -2073,14 +2071,49 @@ cond_if_else_store_replacement (basic_bl
   tree then_lhs, else_lhs;
   basic_block blocks[3];

-  if (MAX_STORES_TO_SINK == 0)
+  /* Handle the case with single store in THEN_BB and ELSE_BB.  That is
+ cheap enough to always handle.  */
+  gphi *vphi = NULL;
+  for (gphi_iterator si = gsi_start_phis (join_bb); !gsi_end_p (si);
+   gsi_next ())
+if (virtual_operand_p (gimple_phi_result (si.phi (
+  {
+   vphi = si.phi ();
+   break;
+  }
+  if (!vphi)
 return false;
+  gimple *then_assign = SSA_NAME_DEF_STMT (PHI_ARG_DEF_FROM_EDGE
+   (vphi, single_succ_edge
(then_bb)));
+  gimple *else_assign = SSA_NAME_DEF_STMT (PHI_ARG_DEF_FROM_EDGE
+   (vphi, single_succ_edge
(else_bb)));
+
+  /* Verify there are no other stores or loads in the BBs.  That allows us
+ to elide dependence checking.  */
+  use_operand_p use_p;
+  imm_use_iterator imm_iter;
+  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, gimple_vuse (then_assign))
+if (USE_STMT (use_p) != then_assign
+   && gimple_bb (USE_STMT (use_p)) == then_bb)
+  {
+   then_assign = NULL;
+   break;
+  }
+  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, gimple_vuse (else_assign))
+if (USE_STMT (use_p) != else_assign
+   && gimple_bb (USE_STMT (use_p)) == else_bb)
+  {
+   else_assign = NULL;
+   break;
+  }

-  /* Handle the case with single statement in THEN_BB and ELSE_BB.  */
   if (then_assign && else_assign)
 return cond_if_else_store_replacement_1 (then_bb, else_bb, join_bb,
  then_assign, else_assign);

+  if (MAX_STORES_TO_SINK == 0)
+return false;
+
   /* Find data references.  */
   then_datarefs.create (1);
   else_datarefs.create (1);

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84876

--- Comment #2 from Vladimir Makarov  ---
Sorry, my bad.  It is easy to fix.  I think the patch will be ready today.

[Bug bootstrap/81033] [8 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033

Eric Gallager  changed:

   What|Removed |Added

Summary|[8 Regression] Revision |[8 Regression] there are
   |r249019 breaks bootstrap on |cases where ld64 is not
   |darwin  |able to determine correct
   ||atom boundaries from the
   ||output GCC currently
   ||produces

--- Comment #34 from Eric Gallager  ---
(In reply to Richard Biener from comment #33)
> The summary is now misleading as well.  IMHO the bug shouldn't have been
> overloaded with the fallout of the original fix.

Updated summary based on:

(In reply to Iain Sandoe from comment #29)
> (In reply to Dominique d'Humieres from comment #28)
> > Bootstrap is fixed, but the fix did not please to Iain Sandoe.
> 
> The fix allows bootstrap to proceed, but doesn't solve the underlying
> problem (which is that there are cases where the linker [ld64] is not able
> to determine correct atom boundaries from the output we currently produce
> from GCC).
> 
> I will hopefully have some cycles for Darwin over the next month to address
> this and other issues.

[Bug tree-optimization/82491] UBSAN in gcc/gimple-fold.c:6187:6: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82491

--- Comment #7 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #5)
> Thanks Richard!
> 
> Now I still see the other issue in dwarf2out:
> 
> Breakpoint 1, based_loc_descr (reg=0x751183a8, offset=...,
> initialized=VAR_INIT_STATUS_INITIALIZED) at ../../gcc/dwarf2out.c:14170
> warning: Source file is more recent than executable.
> 14170   elim = strip_offset_and_add (elim, );
> (gdb) c
> Continuing.
> ../../gcc/poly-int.h:414:21: runtime error: signed integer overflow:
> 9223372036854775789 + 48 cannot be represented in type 'long int'
> #0 0xaa9c75 in poly_int_pod<1u, long>& poly_int_pod<1u,
> long>::operator+=(poly_int_pod<1u, long> const&)
> ../../gcc/poly-int.h:414
> #1 0xaa9266 in strip_offset_and_add(rtx_def*, poly_int_pod<1u, long>*)
> ../../gcc/rtl.h:4340
> #2 0xd4f022 in based_loc_descr ../../gcc/dwarf2out.c:14170
> #3 0xd5da4c in mem_loc_descriptor(rtx_def*, machine_mode, machine_mode,
> var_init_status) ../../gcc/dwarf2out.c:15643
> #4 0xd65a2a in loc_descriptor ../../gcc/dwarf2out.c:16616
> ...
> 
> (gdb) p debug_rtx(elim)
> (plus:DI (reg/f:DI 7 sp)
> (const_int 48 [0x30]))
> $2 = void
> (gdb) p offset
> $3 = {> = {coeffs = {9223372036854775789}},  fields>}
> 
> Is it Jakub something we should handle? Do you have a suggestion how to do
> that?

Dunno, either perform the calculation in poly_uint64 instead and then cast to
poly_int64, or don't do it at all if there is overflow.

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Created attachment 43668
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43668=edit
gcc8-pr79085.patch

Untested fix.

[Bug target/84882] New: -mstrict-align on aarch64 should not be RejectNegative

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84882

Bug ID: 84882
   Summary: -mstrict-align on aarch64 should not be RejectNegative
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

-mno-strict-align works on all targets that support -mstrict-align option,
except aarch64.  Any reason for the RejectNegative in there?  From what I can
see, it isn't the default on aarch64, and there is no way to undo an earlier
flag on command line.

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.5

--- Comment #6 from Jakub Jelinek  ---
Started to ICE with r232167, before that it has been just silent wrong-code,
calling the function/method with a temporary and then copying it over (and not
destructing) despite perhaps having non-trivial copy ctor and/or dtor.

Untested fix:
--- gcc/calls.c.jj  2018-02-22 12:37:02.641387687 +0100
+++ gcc/calls.c 2018-03-15 15:17:42.596835316 +0100
@@ -3422,9 +3422,14 @@ expand_call (tree exp, rtx target, int i
if (CALL_EXPR_RETURN_SLOT_OPT (exp)
&& target
&& MEM_P (target)
-   && !(MEM_ALIGN (target) < TYPE_ALIGN (rettype)
-&& targetm.slow_unaligned_access (TYPE_MODE (rettype),
-  MEM_ALIGN (target
+   /* If rettype is addressable, we may not create a temporary.
+  If target is properly aligned at runtime and the compiler
+  just doesn't know about it, it will work fine, otherwise it
+  will be UB.  */
+   && (TREE_ADDRESSABLE (rettype)
+   || !(MEM_ALIGN (target) < TYPE_ALIGN (rettype)
+&& targetm.slow_unaligned_access (TYPE_MODE (rettype),
+  MEM_ALIGN (target)
  structure_value_addr = XEXP (target, 0);
else
  {

[Bug tree-optimization/70291] muldc3 code generation could be smarter

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70291

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #2 from Wilco  ---
(In reply to Ramana Radhakrishnan from comment #0)
> __complex double x;
> __complex double y;
> __complex double z;
> double a, b, c, d;
> 
> int main (void)
> {
>   x = y * z;
>   return 0; 
> }
> 
> Could well be implemented as:
> 
> 
> int main (void)
> {
>   x = y * z;
>   if (isnan (__real x) && isnan (__imag__ x))
> x = __muldc3 (y, z);
> 
>   return 0;
> }
> 
> essentially opencoding this as the standard suggests in G.5.1 => 6for C99.
> 
> spotted while looking at profiles that were reported on aarch64 with code
> compiled at O2 / O3.
> 
> I note that lowering this in this form in tree-complex.c will need a bit of
> book-keeping given that it's sort of bounded on the phi nodes and ssa_names
> before lowering begins but this could well be another math-optimization done
> later rather than munging it with the existing lowering.

Note that isnan (x) || isnan (y) is optimized to isunordered (x, y), so that
would be a faster check.

Also it may be beneficial to vectorize this despite the fallback.

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859

Richard Biener  changed:

   What|Removed |Added

 Depends on||33315

--- Comment #7 from Richard Biener  ---
The patch for PR33315 manages to transform

  if (n_21 > 255)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:
  a[0] = 255;
  goto ; [100.00%]

   [local count: 477815112]:
  _1 = (unsigned char) n_21;
  a[0] = _1;

   [local count: 955630225]:
  _2 = a[0];

to

  if (n_21 > 255)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:
  _1 = (unsigned char) n_21;

   [local count: 955630225]:
  # _23 = PHI <255(5), _1(6)>
  a[0] = _23;
  _2 = a[0];

but as proposed that would happen too late (we've already threaded the jump
and PRE already would have done sth similar via the load from a[0]).  As
given it looks like sinking should be performed before the first phiopt pass
(which also runs quite late - there was talk of an early phiopt pass).
Possibly cselim could be enhanced to catch the above as well.  In fact its
comments say it would handle the above.  Ah, we do

  /* Set PARAM_MAX_STORES_TO_SINK to 0 if either vectorization or if-conversion
 is disabled.  */
  if ((!opts->x_flag_tree_loop_vectorize && !opts->x_flag_tree_slp_vectorize)
   || !opts->x_flag_tree_loop_if_convert)
maybe_set_param_value (PARAM_MAX_STORES_TO_SINK, 0,
   opts->x_param_values, opts_set->x_param_values);

for whatever reason :/  --param max-stores-to-sink=2 fixes the testcase.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
[Bug 33315] stores not commoned by sinking

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[hp at tmm dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085

--- Comment #5 from Hein-Pieter van Braam  ---
I can build the file I reported #84881 on with the following extra options: -O3
-fno-tree-fre -fno-tree-dominator-opts -fno-tree-copy-prop -fno-tree-ccp
-fno-code-hoisting -fno-tree-pre -fno-tree-vrp

Perhaps that can help nailing down this issue?

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033

--- Comment #33 from Richard Biener  ---
The summary is now misleading as well.  IMHO the bug shouldn't have been
overloaded with the fallout of the original fix.

[Bug c/84873] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84873

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[6/7/8 Regression] ICE: |[6/7 Regression] ICE:
   |verify_ssa failed (error:   |verify_ssa failed (error:
   |definition in block 3 does  |definition in block 3 does
   |not dominate use in block   |not dominate use in block
   |4)  |4)
  Known to fail||7.3.0

--- Comment #9 from Richard Biener  ---
Fixed on trunk sofar.

[Bug debug/84875] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84875

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 43667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43667=edit
gcc8-pr84875.patch

This seems to work (though isn't pretty).

[Bug debug/84875] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84875

--- Comment #3 from Jakub Jelinek  ---
So, we have a function which conditionally bypasses the prologue and epilogue
and just performs a tailcall, otherwise saves two registers (%r10 and %r11)
into %f2 and %f0 registers, clobbers one of them (%r11) and conditionally
branches to epilogue sequence that restores the two:
(insn/f 105 107 106 5 (set (reg:DI 10 %r10)
(reg:DI 17 %f2)) "pr84875.c":18 -1
 (expr_list:REG_DEAD (reg:DI 17 %f2)
(expr_list:REG_CFA_RESTORE (reg:DI 10 %r10)
(nil
(insn/f 106 105 94 5 (set (reg:DI 11 %r11)
(reg:DI 16 %f0)) "pr84875.c":18 -1
 (expr_list:REG_DEAD (reg:DI 16 %f0)
(expr_list:REG_CFA_RESTORE (reg:DI 11 %r11)
(nil
and falls through into the tailcall (otherwise performs some other stuff,
clobbers also the %r10 register, restores the two registers and returns).
That is fine.  Now, cprop_hardreg figures out the %r10 register isn't really
clobbered in the particular path and changes it to:
(insn/f 105 107 106 5 (set (reg:DI 10 %r10)
(reg:DI 10 %r10 [17])) "pr84875.c":18 1270 {*movdi_64}
 (expr_list:REG_DEAD (reg:DI 17 %f2)
(expr_list:REG_CFA_RESTORE (reg:DI 10 %r10)
(nil
(insn/f 106 105 94 5 (set (reg:DI 11 %r11)
(reg:DI 16 %f0)) "pr84875.c":18 1270 {*movdi_64}
 (expr_list:REG_DEAD (reg:DI 16 %f0)
(expr_list:REG_CFA_RESTORE (reg:DI 11 %r11)
(nil
From the POV of unwind info that is still ok, there is really no need to
actually restore the register physically, we just need to emit the .cfi_restore
because we are entering code where the register might not be really safed in
the original register anymore.

And finally rtl_dce just removes the insn 105 as a noop move and removes with
it also the REG_CFA_RESTORE note.

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
  Known to work||5.4.0
Summary|ICE with placement new to   |[6/7/8 Regression] ICE with
   |unaligned location  |placement new to unaligned
   ||location
  Known to fail||8.0

--- Comment #4 from Martin Liška  ---
Still failing, as GCC 5 worked, it's a regression. Can please somebody take a
look?

[Bug c/84873] [6/7/8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84873

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 15 13:10:24 2018
New Revision: 258556

URL: https://gcc.gnu.org/viewcvs?rev=258556=gcc=rev
Log:
2018-03-15  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Do not fold expressions.

* c-c++-common/pr84873.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/pr84873.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359

--- Comment #41 from Aldy Hernandez  ---
(In reply to rguent...@suse.de from comment #40)

> Well, your patch only replaces increments it can modify possibly
> leaving uses unaltered.  That's IMHO not good.
> 
> Which is why I suggested to have it like your original patch for
> those uses you can modify but for other uses simply substitute
> the LHS of the compensation stmt.
> 
> If the compensation stmt ends up being not used it won't be
> expanded I think (you could of course insert/build it just on-demand).

Ah.  I had misunderstood.

I will do as you suggest and then take the patch upstream so we can finish the
rest of the discussion there.

Thanks so much for the feedback.

[Bug c++/79085] ICE with placement new to unaligned location

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085

Martin Liška  changed:

   What|Removed |Added

 CC||hp at tmm dot cx

--- Comment #3 from Martin Liška  ---
*** Bug 84881 has been marked as a duplicate of this bug. ***

[Bug c++/84881] internal compiler error: in assign_temp, at function.c:968 when building for gnueabihf

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84881

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Liška  ---
According to reduced test-case it's dup:

typedef struct {
  char a[6];
} b;
void *operator new(unsigned, void *c, int, char *) { return c; }
class d {
public:
  d(int);
};
class e {
public:
  enum {} f;
  e call(d, const e **, int, int);
  ~e();
};
b g() {
  int h, error;
  e *i;
  int *j;
  const e **args;
  b k;
  e *dest = (e *)
  new (dest, sizeof(e), "") e(i->call(*j, args, h, error));
  return k;
}

*** This bug has been marked as a duplicate of bug 79085 ***

[Bug middle-end/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359

--- Comment #40 from rguenther at suse dot de  ---
On Thu, 15 Mar 2018, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
> 
> --- Comment #39 from Aldy Hernandez  ---
> (In reply to rguent...@suse.de from comment #38)
> > On Thu, 15 Mar 2018, aldyh at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
> > > 
> > > --- Comment #37 from Aldy Hernandez  ---
> > > Hi Richi.
> > > 
> > > (In reply to rguent...@suse.de from comment #31)
> > > 
> > > > I'd have not restricted the out-of-loop IV use to IV +- CST but
> > > > instead did the transform
> > > > 
> > > > +   LOOP:
> > > > + # p_8 = PHI 
> > > > + ...
> > > > + p_INC = p_8 - 1;
> > > > + goto LOOP;
> > > > + ... p_8 uses ...
> > > > 
> > > > to
> > > > 
> > > > +   LOOP:
> > > > + # p_8 = PHI 
> > > > + ...
> > > > + p_INC = p_8 - 1;
> > > > + goto LOOP;
> > > >   newtem_12 = p_INC + 1; // undo IV increment
> > > >   ... p_8 out-of-loop p_8 uses replaced with newtem_12 ...
> > > > 
> > > > so it would always work if we can undo the IV increment.
> > > > 
> > > > The disadvantage might be that we then rely on RTL optimizations
> > > > to combine the original out-of-loop constant add with the
> > > > newtem computation but I guess that's not too much to ask ;)
> > > > k
> > > 
> > > It looks like RTL optimizations have a harder time optimizing things when 
> > > I
> > > take the above approach.
> > > 
> > > Doing what you suggest, we end up optimizing this (simplified for 
> > > brevity):
> > > 
> > >   
> > >   # p_8 = PHI 
> > >   p_19 = p_8 + 4294967295;
> > >   if (ui_7 > 9)
> > > goto ; [89.00%]
> > >   ...
> > > 
> > >   
> > >   p_22 = p_8 + 4294967294;
> > >   MEM[(char *)p_19 + 4294967295B] = 45;
> > > 
> > > into this:
> > > 
> > >   :
> > >   # p_8 = PHI 
> > >   p_19 = p_8 + 4294967295;
> > >   if (ui_7 > 9)
> > >   ...
> > > 
> > >   :
> > >   _25 = p_19 + 1;  ;; undo the increment
> > >   ...
> > > 
> > >   :
> > >   p_22 = _25 + 4294967294;
> > >   MEM[(char *)_25 + 4294967294B] = 45;
> > 
> > shouldn't the p_19 in the MEM remain?  Why a new BB for the adjustment?
> > (just asking...)
> 
> Oh, I was adjusting/propagating that one as a special case to see if the [_25 
> +
> 4294967294] could be CSE'd somehow by the RTL optimizers.  But even with the
> p_19 remaining, the result is the same in the assembly.  For the record, with
> the p_19 in place, we would get (see below for a more complete dump):
> 
>   p_22 = _25 + 4294967294;
>   MEM[(char *)p_19 + 4294967295B] = 45;
> 
> There is no new BB.  That was the result of adding the TMP on the non-back
> edge.  My simplification of the gimple IL for illustration purposes made that
> bit unclear.
> 
> The unadulterated original was:
> 
> [local count: 1073741825]:
>   # ui_7 = PHI 
>   # p_8 = PHI 
>   _4 = ui_7 % 10;
>   _5 = (char) _4;
>   p_19 = p_8 + 4294967295;
>   _6 = _5 + 48;
>   MEM[base: p_19, offset: 0B] = _6;
>   ui_21 = ui_7 / 10;
>   if (ui_7 > 9)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> 
>[local count: 118111601]:
>   if (i_12(D) < 0)
> goto ; [41.00%]
>   else
> goto ; [59.00%]
> 
>[local count: 48425756]:
>   p_22 = p_8 + 4294967294;
>   MEM[(char *)p_19 + 4294967295B] = 45;
> 
> with a corresponding transformation (keeping the p_19 as you inquired) of:
> 
>[local count: 1073741825]:
>   # ui_7 = PHI 
>   # p_8 = PHI 
>   _4 = ui_7 % 10;
>   _5 = (char) _4;
>   p_19 = p_8 + 4294967295;
>   _6 = _5 + 48;
>   MEM[base: p_19, offset: 0B] = _6;
>   ui_21 = ui_7 / 10;
>   ui_24 = ui_21;
>   if (ui_7 > 9)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> 
>[local count: 118111601]:
>   _25 = p_19 + 1;  ;; undo the increment on the non-back edge
>   if (i_12(D) < 0)
> goto ; [41.00%]
>   else
> goto ; [59.00%]
> 
>[local count: 48425756]:
>   p_22 = _25 + 4294967294;
>   MEM[(char *)p_19 + 4294967295B] = 45;
> 
> > 
> > > I haven't dug into the RTL optimizations, but the end result is that we 
> > > only
> > > get one auto-dec inside the loop, and some -2 indexing outside of it:
> > > 
> > > strbr1, [r4, #-1]!
> > > lsr r3, r3, #3
> > > bhi .L4
> > > cmp r6, #0
> > > movlt   r2, #45
> > > add r3, r4, #1
> > > strblt  r2, [r3, #-2]
> > > sublt   r4, r4, #1
> > > 
> > > as opposed to mine:
> > > 
> > >   :
> > >   # p_8 = PHI 
> > >   p_19 = p_8 + 4294967295;
> > >   if (ui_7 > 9)
> > >   ...
> > > 
> > >   :
> > >   p_22 = p_19 + 4294967295;
> > >   *p_22 = 45;
> > > 
> > > which gives us two auto-dec, and much tighter code:
> > > 
> > > strbr1, [r4, #-1]!
> > > lsr 

[Bug c++/84881] internal compiler error: in assign_temp, at function.c:968 when building for gnueabihf

[hp at tmm dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84881

--- Comment #2 from Hein-Pieter van Braam  ---
Created attachment 43666
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43666=edit
Result of the compilation with -fbugreport enabled

[Bug c++/84881] internal compiler error: in assign_temp, at function.c:968 when building for gnueabihf

[hp at tmm dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84881

--- Comment #1 from Hein-Pieter van Braam  ---
I forgot to mention: The ICE doesn't happen when building for i686 or x86_64.