[Bug c++/83137] New: Member function pointer template parameter not constant expression when set to nullptr

[erik2003 at u dot washington.edu]

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

Bug ID: 83137
   Summary: Member function pointer template parameter not
constant expression when set to nullptr
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erik2003 at u dot washington.edu
  Target Milestone: ---

Created attachment 42700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42700=edit
minimal bug example with additional context

When using if constexpr(), GCC claims a member function pointer template
parameter isn't a constant expression if set to nullptr. This does not happen
if the member function pointer points to a real function, or if a raw function
pointer is used instead. Replacing nullptr with (void (Fake::*)())0 or (void
(Fake::*)())NULL produces the same error.

This code compiles in clang but generates an error in GCC:

struct Fake { };

template
void MemberTest()
{
  if constexpr(SET == nullptr)
return;
}

int main()
{
  MemberTest();
}

gccbug.cpp: In instantiation of ‘void MemberTest() [with T = Fake; void (T::*
SET)() = void (Fake::*)(){0, 0}]’:
gccbug.cpp:20:29:   required from here
gccbug.cpp:6:20: error: ‘(void (Fake::*)(){0, 0}.void (Fake::*)()::__pfn == 0)’
is not a constant expression
   if constexpr(SET == nullptr)
^~

This was tested on GCC 7.1.1 and 7.2.0, and is similar to Bug 56428, but
applies to member function pointers only and is triggered by setting the member
function pointer to nullptr instead of comparing it to nullptr.

[Bug c++/83138] New: ICE: Segfault expanding function parameter pack in subsequent sibling pack declaration

[hstong at ca dot ibm.com]

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

Bug ID: 83138
   Summary: ICE: Segfault expanding function parameter pack in
subsequent sibling pack declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

Given the self-contained source below, GCC ICEs with a segmentation fault.
This used to work with GCC 4.7.4.

### SOURCE ():
template  void f(T ...args, char ...args2[][sizeof args]) { }
template  void g(T) { }
void h() { g(); }


### ACTUAL OUTPUT:
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


### EXPECTED OUTPUT:
Clean compile.


### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -x c++ -std=c++11 -


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20171122 (experimental) (GCC)

[Bug c/82050] [8 Regression] ICE on invalid code on x86_64-linux-gnu in column_range, at diagnostic-show-locus.c:1403

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

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

[Bug testsuite/81807] [8 Regression] many *.cc asan tests fail

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #4 from Jeffrey A. Law  ---
My recollection is the test harness doesn't pick up the .cc files so those
tests weren't being run.  We had a patch to pick up the .cc files in the test
harness which got installed and the tests mentioned in c#0 all failed across
the board for every target.  As a result the test harness patch got reverted.

So we've still got these .cc files in the testsuite which don't work in any way
shape or form.  Ideally we'd figure out why so that we could use those tests.

We could certainly drop the regression marker here and just track this as a
request to make those tests work across the targets that support asan.

[Bug fortran/82814] ICE from submodule character function

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Thu Nov 23 09:52:04 2017
New Revision: 255094

URL: https://gcc.gnu.org/viewcvs?rev=255094=gcc=rev
Log:
2017-11-23  Paul Thomas  

PR fortran/82814
* trans-types.c (gfc_sym_type): If a character function result
is missing the charlen backend_decl, use the one from the name-
space procedure symbol, if present.

2017-11-23  Paul Thomas  

PR fortran/82814
* gfortran.dg/submodule_31.f08: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/submodule_31.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/83124] wrong code on arm-linux-gnueabi-gcc with -O3 optimization

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
The code has undefined behaviour.
If you remove the -w, two of the warnings are:
bad.c:5:10: warning: initialization of ‘int *’ from incompatible pointer type
‘union  *’ [-Wincompatible-pointer-types]
 int *c = 
  ^
bad.c:7:11: warning: initialization of ‘long int *’ from incompatible pointer
type ‘union  *’ [-Wincompatible-pointer-types]
 long *d = 
   ^

These break strict-aliasing rule.
So if you use -fno-strict-aliasing you'll get  as the output at all
optimisation levels

[Bug c++/83121] [8 Regression] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.c:995

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 42693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42693=edit
reduced testcase

trippels@gcc67 ~ % g++ -g -flto -r -nostdlib -O2 test_environment.ii
node_buffer.ii
node_buffer.ii:98:10: warning: type ‘struct AsyncHooks’ violates the C++ One
Definition Rule [-Wodr]
   struct AsyncHooks {
  ^
test_environment.ii:117:10: note: a different type is defined in another
translation unit
   struct AsyncHooks {
  ^
node_buffer.ii:99:39: note: the first difference of corresponding definitions
is field ‘providers_’
 int providers_[B::PROVIDERS_LENGTH];
   ^
test_environment.ii:118:67: note: a field of same name but different type is
defined in another translation unit
 v8::Eternal providers_[AsyncWrap::PROVIDERS_LENGTH];
   ^

lto1: internal compiler error: in linemap_ordinary_map_lookup, at
libcpp/line-map.c:995
0x139f7a4 linemap_ordinary_map_lookup
../../gcc/libcpp/line-map.c:995
0x139f7a4 linemap_lookup(line_maps*, unsigned int)
../../gcc/libcpp/line-map.c:948
0x13a068b linemap_macro_loc_to_def_point
../../gcc/libcpp/line-map.c:1453
0x13a068b linemap_resolve_location(line_maps*, unsigned int,
location_resolution_kind, line_map_ordinary const**)
../../gcc/libcpp/line-map.c:1585
0x136bb45 diagnostic_report_current_module(diagnostic_context*, unsigned int)
../../gcc/gcc/diagnostic.c:581
0xb0a6b1 diagnostic_report_current_function(diagnostic_context*,
diagnostic_info*)
../../gcc/gcc/tree-diagnostic.c:39
0xb0a6f0 default_tree_diagnostic_starter
../../gcc/gcc/tree-diagnostic.c:48
0x136a48a diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/gcc/diagnostic.c:985
0x136a84e diagnostic_impl
../../gcc/gcc/diagnostic.c:1108
0x136aa98 inform(unsigned int, char const*, ...)
../../gcc/gcc/diagnostic.c:1160
0x895b21 odr_types_equivalent_p
../../gcc/gcc/ipa-devirt.c:1569
0x89664e add_type_duplicate
../../gcc/gcc/ipa-devirt.c:1848
0x89664e get_odr_type(tree_node*, bool)
../../gcc/gcc/ipa-devirt.c:2028
0x89b9e4 odr_subtypes_equivalent_p
../../gcc/gcc/ipa-devirt.c:689
0x895740 odr_types_equivalent_p
../../gcc/gcc/ipa-devirt.c:1556
0x89664e add_type_duplicate
../../gcc/gcc/ipa-devirt.c:1848
0x89664e get_odr_type(tree_node*, bool)
../../gcc/gcc/ipa-devirt.c:2028
0x89bbd9 register_odr_type(tree_node*)
../../gcc/gcc/ipa-devirt.c:2111
0x5efea7 lto_read_decls
../../gcc/gcc/lto/lto.c:1748
0x5f14d4 lto_file_finalize
../../gcc/gcc/lto/lto.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/home/trippels/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Also happens without -g -O2:
~ % g++ -flto -r -nostdlib test_environment.ii node_buffer.ii

[Bug libfortran/83097] Use __BYTE_ORDER__ instead of runtime test

[jb at gcc dot gnu.org]

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

--- Comment #4 from Janne Blomqvist  ---
Actually, I think it's for big endian we could optimize memcmp_char4. In the
example Thomas posted on the mailing list, one must also check the sign of
memcmp, not just whether it's != 0. Fixed example:

#include 
#include 

char a[4] = { 1, 2, 3, 4};
char b[4] = { 4, 3, 2, 1};

int main()
{
  int i, j;
  memcpy (, a, sizeof(i));
  memcpy (, b, sizeof(j));
  printf("memcmp   : ");
  if (memcmp (,,sizeof(i)) > 0)
printf("larger\n");
  else
printf("smaller or equal\n");

  printf("Direct comparison: ");
  if (i > j)
printf("larger\n");
  else
printf("smaller or equal\n");

  return 0;
}


On a little endian system this prints:

memcmp   : smaller or equal
Direct comparison: larger

Since most targets of interest for GFortran usage are little endian (x86, arm,
ppc64le) I'm not sure it's worth the bother to do the memcmp_char4
optimization.

[Bug libstdc++/83120] [8 Regression] ext/special_functions/hyperg failure on AIX

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #2 from Richard Biener  ---
Also fails for me on x86_64-linux with -m32:

=== libstdc++ Summary for unix/ ===

# of expected passes12775
# of expected failures  70
# of unsupported tests  256

Running target unix//-m32
FAIL: ext/special_functions/hyperg/check_value.cc execution test
FAIL: tr1/5_numerical_facilities/special_functions/17_hyperg/check_value.cc
exec
ution test

=== libstdc++ Summary for unix//-m32 ===

# of expected passes12781
# of unexpected failures2
# of expected failures  70
# of unsupported tests  252


sounds more like a testsuite issue to me not properly allowing for an epsilon
(excess precision, yadda yadda)

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #21 from Ramana Radhakrishnan  ---
Though I don't know what exactly "fixed" this mark it as fixed for GCC 8 as per
reporter.

[Bug c/83117] [8 Regression] FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c (test for excess errors)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|FAIL:   |[8 Regression] FAIL:
   |gcc.target/x86_64/abi/ms-sy |gcc.target/x86_64/abi/ms-sy
   |sv/ms-sysv.c (test for  |sv/ms-sysv.c (test for
   |excess errors)  |excess errors)

[Bug rtl-optimization/83123] Int compare - different asm code for different return type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||segher at gcc dot gnu.org
  Component|c   |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The first case is somehow optimized by combine while the latter is not.
The gimple is almost equal, so is the expanded RTL.

test1 (int a, int b)
{
  _Bool _1;
  _Bool _2;
  _Bool _3;
  int _6;

   [local count: 1073741825]:
  _1 = a_4(D) < 0;
  _2 = b_5(D) < 0;
  _3 = _1 & _2;
  _6 = (int) _3;
  return _6;

test2 (int a, int b)
{
  _Bool _1;
  _Bool _2;
  _Bool _3;

   [local count: 1073741825]:
  _1 = a_4(D) < 0;
  _2 = b_5(D) < 0;
  _3 = _1 & _2;
  return _3;

[Bug tree-optimization/83126] New: [8 Regression] ICE in transform_to_exit_first_loop_alt, at tree-parloops.c:1713

[asolokha at gmx dot com]

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

Bug ID: 83126
   Summary: [8 Regression] ICE in
transform_to_exit_first_loop_alt, at
tree-parloops.c:1713
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20171119 snapshot (r254939) ICEs when compiling the following
snippet w/ -O1 -ftree-parallelize-loops=2 -floop-parallelize-all:

void
ew (unsigned short int c9)
{
  int e1;

  for (;;)
{
  unsigned int *by = 
  int *fd;

  *fd = c9;
  fd = *fd;
  if (*fd != 0)
for (*by = 0; *by < 2; ++*by)
  c9 *= e1;
}
}

% gcc-8.0.0-alpha20171119 -O1 -ftree-parallelize-loops=2 -floop-parallelize-all
-w -c dbuks5p2.c
during GIMPLE pass: parloops
dbuks5p2.c: In function 'ew':
dbuks5p2.c:2:1: internal compiler error: in transform_to_exit_first_loop_alt,
at tree-parloops.c:1713
 ew (unsigned short int c9)
 ^~
0xcf558a transform_to_exit_first_loop_alt
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/tree-parloops.c:1711
0xcf5eac try_transform_to_exit_first_loop_alt
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/tree-parloops.c:1835
0xcf7d45 gen_parallel_loop
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/tree-parloops.c:2379
0xcf826c parallelize_loops
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/tree-parloops.c:3366
0xcf852f execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/tree-parloops.c:3448

[Bug lto/83121] [8 Regression] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.c:995

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Markus Trippelsdorf  ---
Strangely, it started with r255066.

[Bug libstdc++/83127] New: Missing overload for operator << of std::stringstream for old ABI

[ghjghj530-bubu at yahoo dot de]

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

Bug ID: 83127
   Summary: Missing overload for operator << of std::stringstream
for old ABI
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ghjghj530-bubu at yahoo dot de
  Target Milestone: ---

Compiling the following testcode

#include 
#include 

void Main(void)
{
std::string testStr("Hello");
std::string testStr2("World");
std::stringstream ss;

ss << testStr;

testStr2 = ss.str();
}

with flag: -D_GLIBCXX_USE_CXX11_ABI=0 leads to linker error:
undefined reference to `std::basic_ostream&
std::operator<< (std::basic_ostream&, std::basic_string const&)'

Setting -D_GLIBCXX_USE_CXX11_ABI=1 fixes the bug.

We narrowed the problem down to a missing overload in libstdc++.a using:
nm.exe -gC "libstdc++.a" > libstdc++.a.out

There is only one overload for operator << and string:
"std::__cxx11::basic_string"
 W std::basic_ostream& std::operator<<
(std::basic_ostream&, std::__cxx11::basic_string const&)

But two overloads for operator >>:
"std::__cxx11::basic_string" and "std::basic_string"
 W std::basic_istream&
std::operator>>(std::basic_istream&,
std::__cxx11::basic_string&)
 W std::basic_istream&
std::operator>>(std::basic_istream&,
std::basic_string&)

[Bug rtl-optimization/83124] wrong code on arm-linux-gnueabi-gcc with -O3 optimization

[yangyibiao at nju dot edu.cn]

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

--- Comment #2 from Yibiao Yang  ---
Thanks and Very sorry for this wrong bug report. 
(In reply to ktkachov from comment #1)
> The code has undefined behaviour.
> If you remove the -w, two of the warnings are:
> bad.c:5:10: warning: initialization of ‘int *’ from incompatible pointer
> type ‘union  *’ [-Wincompatible-pointer-types]
>  int *c = 
>   ^
> bad.c:7:11: warning: initialization of ‘long int *’ from incompatible
> pointer type ‘union  *’ [-Wincompatible-pointer-types]
>  long *d = 
>^
> 
> These break strict-aliasing rule.
> So if you use -fno-strict-aliasing you'll get  as the output at all
> optimisation levels

[Bug c++/81888] [7/8 Regression] Structured bindings stopped working

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with my r249947 aka PR81258 fix.

[Bug rtl-optimization/82881] [8 Regression] ICE: in df_compact_blocks, at df-core.c:1729 with -freorder-blocks-algorithm=simple

[asolokha at gmx dot com]

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

--- Comment #4 from Arseny Solokha  ---
Unfortunately, I don't seem to have right permissions to reopen the PR.

[Bug lto/83121] [8 Regression] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.c:995

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
   Target Milestone|--- |8.0

--- Comment #2 from Richard Biener  ---
Probably a latent issue.  Always smells like mixed up BLOCKs :/

[Bug target/82975] ICE in baseness at rtlanal.c:6220

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan  ---
Can you put the output of arm-none-linux-gnueabi-gcc -v ? What's the
cross-compiler been configured with ?

[Bug target/82848] [8 Regression] ICE in expand_expr_real_2, at expr.c:8715

[jakub at gcc dot gnu.org]

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

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 42692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42692=edit
gcc8-pr82848.patch

Untested fix.  I think it is better to just punt on all the ones and get
diagnostics.  Technically, the problem is mostly in stuff that
tree-vect-generic.c doesn't handle (FMA_EXPR, widening stuff, etc.), but I
think it is just wrong to error on something with -mno-fold-gimple and not with
-mfold-gimple.

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #19 from PeteVine  ---
Created attachment 42694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42694=edit
Better assembly after profiling

[Bug c/83122] -Wconversion and shifting bitwise

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The same probably happens with a division.

Note it might be an inherent limitation of the warning given apart from some
simple cases like yours we can't really tell the value range of the stored
value.  This is why it says "may" alter its value.

[Bug ipa/83125] [8 regression] ICE in edge_badness, at ipa-inline.c:1025

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  I believe this is because on mingw host HOST_LONG_LONG_FORMAT
is redefined to "I64", but that is a Microsoft-ism that pp_printf of course
doesn't handle.  pp_unsigned_wide_integer or pp_scalar it uses should handle
this fine by using the host sprintf into a temporary buffer and then just
appending the digit buffer.
As this needs mingw host, I can't really test whether it fixes this though, can
only bootstrap/regtest it on linux.

[Bug middle-end/82253] [6/7 Regression] ICE in convert_move, at expr.c:604

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE in   |[6/7 Regression] ICE in
   |convert_move, at expr.c:604 |convert_move, at expr.c:604

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug rtl-optimization/82881] [8 Regression] ICE: in df_compact_blocks, at df-core.c:1729 with -freorder-blocks-algorithm=simple

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
gcc-8.0.0-alpha20171119 snapshot (r254939) still fails:

% gcc-8.0.0-alpha20171119 -O2 -freorder-blocks-algorithm=simple -c testcase.c
during RTL pass: bbro
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in df_compact_blocks, at
df-core.c:1729
 }
 ^
0x61f30e df_compact_blocks()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/df-core.c:1729
0x1260035 compact_blocks()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/cfg.c:160
0x1259dc2 reorder_basic_blocks
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/bb-reorder.c:2483
0x1259e42 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/bb-reorder.c:2573

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[ghjghj530-bubu at yahoo dot de]

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

--- Comment #7 from ghjghj530-bubu at yahoo dot de ---
I tried debugging the GCC today (not my strong side).
I ended up to extracte the call to cc1plus.exe and started GDB with cc1plus.exe
as target.
If i just run the process the ICE still occurs with the same information as
before: "internal compiler error: in pp_format, at pretty-print.c:630"

So i set a breakpoint at this location and printed the backtrace and some
variables:

Breakpoint 2, pp_format (pp=pp@entry=0xbd9fba8, text=text@entry=0xbd9faec) at
../../gcc-6.3.0/gcc/pretty-print.c:630
630 in ../../gcc-6.3.0/gcc/pretty-print.c
(gdb) bt
#0  pp_format (pp=pp@entry=0xbd9fba8, text=text@entry=0xbd9faec) at
../../gcc-6.3.0/gcc/pretty-print.c:630
#1  0x00f469ab in pp_printf (pp=pp@entry=0xbd9fba8, msg=msg@entry=0x116423d
 "%I64d")
at ../../gcc-6.3.0/gcc/pretty-print.c:874
#2  0x009219b9 in ubsan_type_descriptor (type=,
type@entry=0xda193c0, pstyle=pstyle@entry=UBSAN_PRINT_ARRAY)
at ../../gcc-6.3.0/gcc/ubsan.c:416
#3  0x0092213a in ubsan_expand_bounds_ifn (gsi=gsi@entry=0xbd9fc9c) at
../../gcc-6.3.0/gcc/ubsan.c:693
#4  0x00927438 in (anonymous namespace)::pass_sanopt::execute (this=, fun=0x14b068) at ../../gcc-6.3.0/gcc/sanopt.c:696
#5  0x0085c61a in execute_one_pass (pass=pass@entry=0x15d4e0) at
../../gcc-6.3.0/gcc/passes.c:2336
#6  0x0085cb78 in execute_pass_list_1 (pass=0x15d4e0, pass@entry=0x15a728) at
../../gcc-6.3.0/gcc/passes.c:2420
#7  0x0085cbd9 in execute_pass_list (fn=0x14b068, pass=0x15a728) at
../../gcc-6.3.0/gcc/passes.c:2431
#8  0x005f928f in cgraph_node::expand (this=0xda28000) at
../../gcc-6.3.0/gcc/cgraphunit.c:1982
#9  0x005f9e02 in output_in_order (no_reorder=no_reorder@entry=false) at
../../gcc-6.3.0/gcc/cgraphunit.c:2220
#10 0x005fa12c in symbol_table::compile (this=this@entry=0x14b000) at
../../gcc-6.3.0/gcc/cgraphunit.c:2468
#11 0x005fc097 in compile (this=0x14b000) at
../../gcc-6.3.0/gcc/cgraphunit.c:2538
#12 symbol_table::finalize_compilation_unit (this=0x14b000) at
../../gcc-6.3.0/gcc/cgraphunit.c:2564
#13 0x009085a5 in compile_file () at ../../gcc-6.3.0/gcc/toplev.c:488
#14 0x0109b23a in do_compile () at ../../gcc-6.3.0/gcc/toplev.c:1986
#15 toplev::main (this=this@entry=0xbd9ff1e, argc=argc@entry=14,
argv=argv@entry=0xc212ff0) at ../../gcc-6.3.0/gcc/toplev.c:2094
#16 0x010b2fb6 in main (argc=14, argv=0xc212ff0) at
../../gcc-6.3.0/gcc/main.c:39
(gdb) p pp->format_decoder
$11 = (printer_fn) 0x0
(gdb) p pp
$12 = (pretty_printer *) 0xbd9fba8
(gdb)


Continuing at this position leads to the ICE

Does this help in any way? How can i contribute more information?

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #20 from PeteVine  ---
The bug doesn't reproduce in a recent GCC 8 build (profiling on a Cortex A5
system).

The generated assembly contains no __aeabi_idiv calls whatsoever. Well done.

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #5 from Tom de Vries  ---
(In reply to Oleg Endo from comment #4)
> Thanks for reporting and tracking this down.
> It seems there more such traps.  Can you please try the following:

I've done an sh-elf build using this patch, and that went ok.

FWIW, I've also done an sh-unknown-linux-gnu build and that gets as far as it
can get without an sh runtime installation.

I don't have a complete sh build and test setup. Somebody needs to build and
test this patch for the sh target.

[Bug c/83122] -Wconversion and shifting bitwise

[lh_mouse at 126 dot com]

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

--- Comment #2 from Liu Hao  ---
Yes it is hard to tell whether there is indeed loss of precision.

At the moment, the (only?) redictable way to silence the warning is to use a
bitwise and operation. That is, `ptr->b = (val >> 3) & (UINT64_MAX >> 3)`.

[Bug middle-end/82253] [6/7/8 Regression] ICE in convert_move, at expr.c:604

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 23 11:26:32 2017
New Revision: 255095

URL: https://gcc.gnu.org/viewcvs?rev=255095=gcc=rev
Log:
PR middle-end/82253
* expr.c (expand_assignment): For CONCAT to_rtx, complex type from and
bitpos/bitsize covering the whole destination, use store_expr only if
the complex mode is the same.  Otherwise, use expand_normal and if
it returns CONCAT, subreg each part separately instead of trying to
subreg the whole result.

* gfortran.dg/pr82253.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr82253.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c/83122] New: -Wconversion and shifting bitwise

[lh_mouse at 126 dot com]

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

Bug ID: 83122
   Summary: -Wconversion and shifting bitwise
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

Minimal testcase:

```c
// gcc -c test.c -Wall -Wextra -pedantic -pedantic-errors -std=c99 -Wconversion

typedef __UINT64_TYPE__ uint64_t;

struct foo {
uint64_t a :  3;
uint64_t b : 61;
};

void set_a(struct foo *ptr, uint64_t val){
ptr->b = val >> 3;
}
```


The program above results in a warning about loss of precision:

```
test.c: In function 'set_a':
test.c:11:11: warning: conversion to 'long long unsigned int:61' from 'uint64_t
{aka long long unsigned int}' may alter its value [-Wconversion]
  ptr->b = val >> 3;
   ^~~
```

This is a false positive since the 3 MSBs of `val` are filled with zeroes.

In reality, the warning persists even after I replace `val >> 3` with `val >>
63`.

[Bug rtl-optimization/83124] New: wrong code on arm-linux-gnueabi-gcc with -O3 optimization

[yangyibiao at nju dot edu.cn]

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

Bug ID: 83124
   Summary: wrong code on arm-linux-gnueabi-gcc with -O3
optimization
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
  Target Milestone: ---

this wrong code occurred while optimization flag "-O3" was used in
arm-linux-gnueabi-gcc

$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabi/5/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armel-cross/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armel-cross
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armel-cross
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib
--disable-sjlj-exceptions --with-arch=armv5t --with-float=soft --disable-werror
--enable-multilib --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=arm-linux-gnueabi
--program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)

$ cat small.c
union {
  unsigned short a
} b = {1};
*c = 
long *d = 
main() {
  *d = 4294967295;
  *c |= 55868;
  printf("%X\n", b.a);
}

$ arm-linux-gnueabi-gcc -static -w -O3 small.c; ./a.out
DA3D

$ arm-linux-gnueabi-gcc -static -w -O0 small.c; ./a.out


$ gcc -static -w -m32 -O0 small.c; ./a.out


$ clang -static -w -m32 -O0 small.c; ./a.out

[Bug tree-optimization/81403] [8 Regression] wrong code at -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 23 08:30:41 2017
New Revision: 255092

URL: https://gcc.gnu.org/viewcvs?rev=255092=gcc=rev
Log:
2017-11-23  Richard Biener  

PR tree-optimization/81403
* tree-ssa-pre.c (get_representative_for): Add parameter specifying
a block we need a leader relative to.
(phi_translate_1): For nary processing require a leader from
get_representative_for given we run expression simplification
using match-and-simplify.  Remove previous fix.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug c/82050] [8 Regression] ICE on invalid code on x86_64-linux-gnu in column_range, at diagnostic-show-locus.c:1403

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
In:
1418static column_range
1419get_affected_columns (const fixit_hint *hint)
1420{
1421  int start_column = LOCATION_COLUMN (hint->get_start_loc ());
1422  int finish_column = LOCATION_COLUMN (hint->get_next_loc ()) - 1;
1423
1424  return column_range (start_column, finish_column);
(gdb) p hint->get_start_loc ()
$3 = 438112
(gdb) p hint->get_next_loc ()
$4 = 307392
(gdb) p expand_location ($3)
$5 = {file = 0x7fffe3d1 "pr82050.c", line = 14, column = 4086, data = 0x0,
sysp = false}
(gdb) p expand_location ($4)
$6 = {file = 0x7fffe3d1 "pr82050.c", line = 14, column = 1, data = 0x0,
sysp = false}

so finish_column is 0 and smaller than start_column, which is what column_range
ICEs on.  Is that because we have:
/* Do not track column numbers higher than this one.  As a result, the
   range of column_bits is [12, 18] (or 0 if column numbers are
   disabled).  */
const unsigned int LINE_MAP_MAX_COLUMN_NUMBER = (1U << 12);
and thus effectively can only track columns up to 4095 (or 4096 if 1 based)?
If so, something should punt on it rather than ICE it is not possible.

[Bug target/83117] FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c (test for excess errors)

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Recently, compiler started to warn for:

--cut here--
extern long do_test_aligned ();

static long (*const do_test_v1) (long a, ...) = (void *) do_test_aligned;

extern void check_results (long);

int test (long a)
{
  long ret;

  ret = do_test_v1 (a);
  check_results (ret);
}
--cut here--

gcc -O2:

fcast.c: In function ‘test’:
fcast.c:11:9: warning: function called through a non-compatible type
   ret = do_test_v1 (a);

[Bug c/83117] FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c (test for excess errors)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||mpolacek at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Component|target  |c
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Looks like a bogus warning to me.

extern long do_test_aligned ();

is not a prototype so

static long (*const do_test_v1) (long a, ...) = (void *) do_test_aligned;

is a way to provide one and the return type even matches.

[Bug c/83123] New: Int compare - different asm code for different return type

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 83123
   Summary: Int compare - different asm code for different return
type
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

int test1(int a, int b)
{
  return (a < 0) && (b < 0);
}
bool test2(int a, int b)
{
  return (a < 0) && (b < 0);
}

This produces following code, when compiled with -O2. For some reason 2nd
function performs shifts first, then and. This is not necessary, you can and
first, then shift. The same issue is for checking if any of numbers is negative
- or can be executed first, then shift.

test1(int, int):
  and esi, edi
  mov eax, esi
  shr eax, 31
  ret
test2(int, int):
  mov eax, edi
  shr esi, 31
  shr eax, 31
  and eax, esi
  ret

[Bug ipa/83125] [8 regression] ICE in edge_badness, at ipa-inline.c:1025

[dimhen at gmail dot com]

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

--- Comment #1 from Dmitry G. Dyachenko  ---
(In reply to Dmitry G. Dyachenko from comment #0)
Stack for r255090

x.ii:43:10: internal compiler error: in edge_badness, at ipa-inline.c:1025
 t::~t() {}
  ^
0x9e81af edge_badness
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1024
0x18f8049 update_edge_key
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1224
0x18f8588 update_caller_keys
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1346
0x18f84cb update_caller_keys
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1335
0x18f99cb inline_small_functions
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2052
0x18f99cb ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2443
0x18f99cb execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2850

[Bug tree-optimization/23094] store ccp, or store copy prop misses an optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 23 09:05:11 2017
New Revision: 255093

URL: https://gcc.gnu.org/viewcvs?rev=255093=gcc=rev
Log:
2017-11-23  Richard Biener  

PR tree-optimization/23094
* tree-ssa-sccvn.c (vuse_ssa_val): Handle VN_TOP when we
come here from walking over backedges in the first iteration.
(vn_reference_lookup_3): Skip clobbers that store the same value.

* gcc.dg/tree-ssa/ssa-fre-61.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-61.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug target/83110] Relocation error when taking address of protected function in shared library.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1
  Known to fail||3.4.6

--- Comment #1 from Richard Biener  ---
Confirmed.  Never worked.  Not sure if this is invalid source or not.

[Bug target/82248] probe_stack can generate unpredictable STR on arm

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Thu, 23 Nov 2017, ramana at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82248
> 
> --- Comment #3 from Ramana Radhakrishnan  ---
> (In reply to Richard Biener from comment #2)
> > Miscompiles mpfr for us on armv7.  Isn't it easy enough to handle this in
> > the insn pattern by using some non pre/post-indexed memory_operand predicate
> > and or using an early clobbered match_scratch to allocate 'r0'?
> 
> 
> I was testing a patch that used 'o' instead of 'm' in the constraint as that's
> just an offsettable address and would prevent post/ pre-inc type operations 
> but
> it slipped through  the cracks with travels in September :( 
> 
> Can you test if that is sufficient for you or what's the runes in configure 
> for
> forcing probe_stack_range ? 

Will do and report back.

[Bug tree-optimization/23094] store ccp, or store copy prop misses an optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #19 from Richard Biener  ---
Fixed.

[Bug tree-optimization/83089] [8 Regression] ICE: Segmentation fault (in instantiate_scev_name)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 23 08:24:20 2017
New Revision: 255091

URL: https://gcc.gnu.org/viewcvs?rev=255091=gcc=rev
Log:
2017-11-23  Richard Biener  

PR tree-optimization/83089
* gcc.dg/pr83089.c: Require pthread.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr83089.c

[Bug ipa/83125] New: [8 regeression] ICE in edge_badness, at ipa-inline.c:1025

[dimhen at gmail dot com]

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

Bug ID: 83125
   Summary: [8 regeression] ICE in edge_badness, at
ipa-inline.c:1025
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

r254663 PASS
r254924 FAIL
r255090 FAIL

sound similar to PR83001 and PR83051

PASS if I lower
-O level
  or
--param early-inlining-insns value
  or
--param max-early-inliner-iterations value
  or
remove -fPIC -DPIC

$ g++ -Werror -Wall -O2 --param early-inlining-insns=36 --param
max-early-inliner-iterations=20 -std=c++98 -c -fpreprocessed x.ii  -fPIC -DPIC
during IPA pass: inline
x.ii:43:10: internal compiler error: in edge_badness, at ipa-inline.c:1024
 t::~t() {}
  ^
0x9e3f48 edge_badness
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1023
0x18e6859 update_edge_key
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1223
0x18e6d98 update_caller_keys
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1345
0x18e6cdb update_caller_keys
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1334
0x18e819b inline_small_functions
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2051
0x18e819b ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2442
0x18e819b execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2849
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.

$ cat x.ii
class a {
public:
  void b(int *);
};
struct c {
  c *d;
};
struct G : c {
  int *e();
};
template  struct f {
  typedef G *h;
  a i();
  void j();
  h k;
  void l() {
int m = *k->e();
i().b();
j();
  }
  void n(h);
  ~f() {
G o;
n();
  }
};
template  void f::n(h p) {
  h q, r = 0;
  while (p) {
q = h(p->d);
n(q);
  }
  l();
  p = r;
}
struct D {
  f s;
};
struct t {
  ~t();
  D v;
};
t::~t() {}

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl,extra
--enable-languages=c,c++,lto --disable-multilib --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=native
Thread model: posix
gcc version 8.0.0 20171123 (experimental) [trunk revision 255090] (GCC)

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.3

[Bug c++/83116] [6/7/8 Regression] Statement with no effect causes wrong code of static object constexpr method

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |6.5
Summary|Statement with no effect|[6/7/8 Regression]
   |causes wrong code of static |Statement with no effect
   |object constexpr method |causes wrong code of static
   ||object constexpr method

[Bug target/82248] probe_stack can generate unpredictable STR on arm

[ramana at gcc dot gnu.org]

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

--- Comment #3 from Ramana Radhakrishnan  ---
(In reply to Richard Biener from comment #2)
> Miscompiles mpfr for us on armv7.  Isn't it easy enough to handle this in
> the insn pattern by using some non pre/post-indexed memory_operand predicate
> and or using an early clobbered match_scratch to allocate 'r0'?


I was testing a patch that used 'o' instead of 'm' in the constraint as that's
just an offsettable address and would prevent post/ pre-inc type operations but
it slipped through  the cracks with travels in September :( 

Can you test if that is sufficient for you or what's the runes in configure for
forcing probe_stack_range ? 

regards
Ramana

[Bug target/83114] [7/8 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2495

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.3

[Bug target/82248] probe_stack can generate unpredictable STR on arm

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   See Also||https://bugzilla.suse.com/s
   ||how_bug.cgi?id=1068967

--- Comment #2 from Richard Biener  ---
Miscompiles mpfr for us on armv7.  Isn't it easy enough to handle this in
the insn pattern by using some non pre/post-indexed memory_operand predicate
and or using an early clobbered match_scratch to allocate 'r0'?

[Bug tree-optimization/40766] this fortran program is too slow

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #25 from Janne Blomqvist  ---
Reducing N by a factor of 100 to make the test run faster, compiling with
-Ofast -march=native I get best-of-3 runs on

a) GCC trunk as of yesterday on x86_64 Ubuntu 16.04 (glibc 2.23), AMD
Phenom(tm) II X4 940:

  - real(4) version: 6.16s
  - real(8) version: 1.60s

b) GCC 7.2 from homebrew on macOS 10.12.6 (Sierra), 2 GHz Intel Core i7,
MacBook Air mid-2012:

  - real(4) version: 0.768s
  - real(8) version: 0.512s


Observations: 

- The "perf" profiler on Linux shows that for the real version, 99% of the time
is spent in glibc libm, and for the real(8) version 97%. 

- glibc has improved, now the real(4) version is a factor of 4 slower than the
real(8) one, rather than a factor of 10 as in the previous tests by Dominique
in 2013.

- If I remove the cos() call in the loop, it vectorizes with -mveclibabi=svml.
So no vectorized sincos yet.

Anyway, I'm not sure what the Fortran frontend could do better here. Mostly
it's a glibc issue. Hence, closing as invalid.

[Bug target/83114] [7/8 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2495

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Doesn't need the -g either. Just -O3 is enough

[Bug c++/83116] [6/7/8 Regression] Statement with no effect causes wrong code of static object constexpr method

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
No idea where though.

[Bug rtl-optimization/83098] [8 regression] ICE in assert_rtx_eq_at, at selftest-rtl.c:57

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #5 from Rainer Orth  ---
Of course.  Sorry I forgot.

[Bug tree-optimization/83126] [8 Regression] ICE in transform_to_exit_first_loop_alt, at tree-parloops.c:1713

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug libstdc++/83127] Missing overload for operator << of std::stringstream for old ABI

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
It links fine on GNU/Linux using a standard start function, int main().

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #15 from Jan Hubicka  ---
I believe it was done before the inliner change, but i am now trying to
reproduce it on yttrium. It is bad idea to use periodic benchmarking machine
for random bootstraps anyway.

Thanks for the info and pointer to working itanium box!

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
Author: olegendo
Date: Thu Nov 23 14:08:12 2017
New Revision: 255097

URL: https://gcc.gnu.org/viewcvs?rev=255097=gcc=rev
Log:
gcc/
Backport from mainline
2017-11-23  Oleg Endo  

PR target/83111
* config/sh/sh.md (udivsi3, divsi3, sibcall_value_pcrel,
sibcall_value_pcrel_fdpic): Use local variable instead of
operands[3].
(calli_tbr_rel): Add missing operand 2.
(call_valuei_tbr_rel): Add missing operand 3.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/sh/sh.md

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #8 from Oleg Endo  ---
Fixed on GCC 7 and GCC 8.

[Bug c++/81888] [7/8 Regression] Structured bindings stopped working

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/83116] [6/7/8 Regression] Statement with no effect causes wrong code of static object constexpr method

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r230365.
Guess we need to remove the static var from constexpr caches at the end of
construction if the var isn't constexpr.

Testcase modified for the testsuite:

// PR c++/83116
// { dg-do run { target c++14 } }

struct S {
  constexpr S () : s(0) { foo (); }
  constexpr int foo () { return s; }
  int s;
};

int
main ()
{
  static S var;
  var.s = 5;
  if (var.s != 5 || var.foo () != 5)
__builtin_abort ();
}

[Bug tree-optimization/83128] Unable to optimize {m,c}alloc when strings builtin are used

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-23
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 255093)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -1388,10 +1388,14 @@ fully_constant_vn_reference_p (vn_refere
   else if (base->opcode == MEM_REF
   && base[1].opcode == ADDR_EXPR
   && (TREE_CODE (TREE_OPERAND (base[1].op0, 0)) == VAR_DECL
-  || TREE_CODE (TREE_OPERAND (base[1].op0, 0)) == CONST_DECL))
+  || TREE_CODE (TREE_OPERAND (base[1].op0, 0)) == CONST_DECL
+  || TREE_CODE (TREE_OPERAND (base[1].op0, 0)) == STRING_CST))
{
  decl = TREE_OPERAND (base[1].op0, 0);
- ctor = ctor_for_folding (decl);
+ if (TREE_CODE (decl) == STRING_CST)
+   ctor = decl;
+ else
+   ctor = ctor_for_folding (decl);
}
   if (ctor == NULL_TREE)
return build_zero_cst (ref->type);
@@ -2331,7 +2335,8 @@ vn_reference_lookup_3 (ao_ref *ref, tree
  rhs = TREE_OPERAND (tem, 0);
  rhs_offset += tree_to_uhwi (TREE_OPERAND (tem, 1));
}
- else if (DECL_P (tem))
+ else if (DECL_P (tem)
+  || TREE_CODE (tem) == STRING_CST)
rhs = build_fold_addr_expr (tem);
  else
return (void *)-1;

[Bug testsuite/83131] New: c-c++/common/attr-nonstring-3 failure for strcmp tests on PowerPC

[dje at gcc dot gnu.org]

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

Bug ID: 83131
   Summary: c-c++/common/attr-nonstring-3 failure for strcmp tests
on PowerPC
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

New testcase failure on PowerPC (Linux and AIX)

FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
149)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
150)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
153)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
154)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
156)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
157)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
158)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
168)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
169)

gnu++11, gnu++14, c

149-169 correspond to the line-specific strcmp and strncmp tests in the
testcase.

[Bug testsuite/83131] c-c++/common/attr-nonstring-3 failure for strcmp tests on PowerPC

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug rtl-optimization/83098] [8 regression] ICE in assert_rtx_eq_at, at selftest-rtl.c:57

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
If you are into make check, then self test already passed, right?
Thus, can this be closed as fixed?

[Bug c/82050] [8 Regression] ICE on invalid code on x86_64-linux-gnu in column_range, at diagnostic-show-locus.c:1403

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
I attempted to copy from comment #0, but couldn't reproduce the ICE
(possibly a spaces vs tabs thing?)

Jakub: please can you attach the reproducer file, and I'll take this.  Thanks.

[Bug tree-optimization/83129] calloc zero initialization is not taken into account by gcc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-23
Version|unknown |8.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed - mine.

This one is interesting because alias-wise we consider allocation functions
not clobbering anything -- dependences for the pointer will prevent any
invalid transform.

That of course means we'll never visit it via vn_reference_lookup_3.

One trick we don't pull is that if there's a must-alloc in the path we can
stop walking.  Another trick we don't pull is that if we don't find any
may-def the memory we load is uninitialized (or in this case zero-initialized
as we don't find the calloc as may-def either - an issue for calloc and
-Wuninit maybe).  So we could in theory optimistically value-number each
of those to zero (conservatively to treat calloc "right").

Need to think about that -Wuninitialized case.  Ah, we only ever warn
using the oracle walking for decls, so never for allocated memory.

So in theory the following but it doesn't trigger because of the above.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 255093)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -2412,6 +2417,21 @@ vn_reference_lookup_3 (ao_ref *ref, tree
   return NULL;
 }

+  /* 7) calloc, optimize ref to all zeros.  */
+  else if (is_gimple_reg_type (vr->type)
+  && gimple_call_builtin_p (def_stmt, BUILT_IN_CALLOC)
+  && TREE_CODE (base) == MEM_REF
+  && TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME
+  && SSA_VAL (TREE_OPERAND (base, 0)) != VN_TOP
+  && SSA_VAL (TREE_OPERAND (base, 0)) == gimple_call_lhs (def_stmt))
+{
+  /* We do not bother to check whether the ref is in range because
+ we'll usually not be able to anyway.  */
+  tree val = build_zero_cst (vr->type);
+  return vn_reference_lookup_or_insert_for_pieces
+   (vuse, vr->set, vr->type, vr->operands, val);
+}
+
   /* Bail out and stop walking.  */
   return (void *)-1;
 }

[Bug libstdc++/83127] Missing overload for operator << of std::stringstream for old ABI

[ghjghj530-bubu at yahoo dot de]

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

--- Comment #3 from ghjghj530-bubu at yahoo dot de ---
Changed my testcode to int main(). The error stil occurs.
The system is Windows 7, 64 bit, mingw.

Is use the GCC in a company-specific enviroment with some customized
linkersripts.

We first compile the source file with:
i686-elf-gcc.exe -c C:\temp\2\Main.cpp -o c:\temp\2\Main.cpp.o
-D_GLIBCXX_USE_CXX11_ABI=0

and then call the linker:
i686-elf-gcc.exe C:\Temp\2\Main.cpp.o -o C:\Temp\2\a.out
-Wl,-lstdc++,-lsupc++,-lm -lc 
(i have removed a -specs paramter and some target plattform specific
parameters).

I'm sorry for the incomplete command line.

I still hope the *.a-File analysis from my original post can help you.

[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676

[siddhesh at gotplt dot org]

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

--- Comment #4 from Siddhesh Poyarekar  ---
Reduced C test case:

#define MAX 98

void foo (unsigned long *res, unsigned long in)
{
  for (unsigned long a = 0; a < MAX; a++)
for (unsigned long b = 0; b < MAX; b++)
  for (unsigned long c = 0; c < MAX; c++)
for (unsigned long d = 0; d < MAX; d++)
  for (unsigned long e = 0; e < MAX; e++)
for (unsigned long f = 0; f < MAX; f++)
  for (unsigned long g = 0; g < MAX; g++)
*res += a * in;
}



foo.c: In function 'foo':
foo.c:13:1: internal compiler error: in from_gcov_type, at profile-count.h:676
 }
 ^
0xaaf57f profile_count::from_gcov_type(long)
/home/siddhesh/src/gcc/gcc/profile-count.h:676
0xaaf57f estimate_bb_frequencies(bool)
/home/siddhesh/src/gcc/gcc/predict.c:3623
0xab40af tree_estimate_probability(bool)
/home/siddhesh/src/gcc/gcc/predict.c:2849
0xab45c3 execute
/home/siddhesh/src/gcc/gcc/predict.c:3760
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/82459] AVX512F instruction costs: vmovdqu8 stores may be an extra uop, and vpmovwb is 2 uops on Skylake and not always worth using

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich  changed:

   What|Removed |Added

 CC||andrew.n.senkevich at gmail 
dot co
   ||m

--- Comment #2 from Andrew Senkevich  ---
Currently -mprefer-avx256 is default for SKX and vzeroupper addition was fixed,
code generated is:

.L3:
vpsrlw  $8, (%rsi,%rax,2), %ymm0
vpsrlw  $8, 32(%rsi,%rax,2), %ymm1
vpand   %ymm0, %ymm2, %ymm0
vpand   %ymm1, %ymm2, %ymm1
vpackuswb   %ymm1, %ymm0, %ymm0
vpermq  $216, %ymm0, %ymm0
vmovdqu8%ymm0, (%rdi,%rax)
addq$32, %rax
cmpq%rax, %rdx
jne .L3

vmovdqu8 remains but I cannot confirm it is slower.

[Bug target/83114] [5/6/7/8 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2495

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

   Target Milestone|7.3 |6.6
Summary|[7/8 Regression] ICE in |[5/6/7/8 Regression] ICE in
   |gen_vec_cmpv2dfv2di, at |gen_vec_cmpv2dfv2di, at
   |config/aarch64/aarch64-simd |config/aarch64/aarch64-simd
   |.md:2495|.md:2495

[Bug rtl-optimization/83123] Int compare - different asm code for different return type

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
In the first case (with the extend to SImode) the extend is combined
with the AND, to an AND in SImode.  After that, the 3-insn combination
of the two shifts with the AND is something combine knows how to split.

In the second case this of course does not happen.

[Bug target/83114] [7/8 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2495

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com,
   ||jgreenhalgh at gcc dot gnu.org,
   ||sudi.das at arm dot com
  Known to work|6.4.1   |4.8.1
  Known to fail||4.9.1, 5.1.1

--- Comment #3 from James Greenhalgh  ---
Looks like we're missing handling for LTGT in our vcmp/vcond handlers.

  /* This is an ordered NE, ie !UNEQ, ie false for NaN.  */
  DEF_RTL_EXPR(LTGT, "ltgt", "ee", RTX_COMM_COMPARE)

I bet this would fail even further back with a modified testcase (this one is
somewhat undefined behaviour).

  void *a;
  void b(double *in) {
char c;
long d = -1024;
char *e = a;
for (; d; d++) {
  double f = in[d], g = in[d+1];
  c = g < f || g > f;
  e[d] = c;
}
  }

Is broken back to at least GCC 4.9.

Well... I implemented the original version of this code in GCC 4.9 and today is
the first time I heard of LTGT, so not surprising I missed it!

[Bug fortran/83064] DO CONCURRENT inconsistent results

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On November 23, 2017 6:30:34 PM GMT+01:00, "dominiq at lps dot ens.fr"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
>
>--- Comment #5 from Dominique d'Humieres 
>---
>> As I said in the other bug we're seeing
>>
>>real(real64), dimension(nsplit) :: tmp
>>
>> as "shared" amongst the outer loop iterations.
>>
>> ...
>>
>> Not sure if you need to mark compute somehow to avoid this
>> and the testcase is invalid fortran or if the frontend is at fault.
>
>IMO the testcase is valid fortran and, with my naive view of arrays
>returned by
>a function, the returned array should be private to the function.
>
>If I do the following changes
>
>...
>real(real64), dimension(nsplit) :: pi, pik
>...
>do concurrent (i = 1:nsplit)
>pik = compute( low(i), high(i) )
>pi(i) = sum(pik)
>end do
>...
>
>the code works as expected, at least for my limited testing.

I looked at the IL from the Fortran FE and it clearly uses a single memory area
for tmp for each outer loop iteration. That is, the memory is allocated by the
caller. 

>
>Do you understand why the code is not parallelized with
>-ftree-parallelize-loops=4?

Because the outer loop has four iterations and we statically require at least
two per thread for outer loops. 

Richard.

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[randy.macleod at windriver dot com]

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

--- Comment #28 from Randy MacLeod  ---
Alex, thanks for confirming, I was worried that it was one of the _perfectly_
sensible local patches we have in YP.  ;-)

FYI, a local toolchain expert has started working on this defect so stay tuned
/ keeep refreshing.

[Bug c++/83132] Error while redeclaring an enum with extra qualification

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Similar error for classes:

namespace N { struct E; }
struct ::N::E {};

x.C:2:15: error: global qualification of class name is invalid before ‘{’ token
 struct ::N::E {};
   ^

[Bug fortran/36313] [F03] {MIN,MAX}{LOC,VAL} should accept character arguments

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Nov 23 17:52:05 2017
New Revision: 255109

URL: https://gcc.gnu.org/viewcvs?rev=255109=gcc=rev
Log:
2017-11-23  Thomas Koenig  

PR fortran/36313
* m4/maxloc2s.m4: Replace int for character length by
gfc_charlen_type.
* m4/minloc2s.m4: Likewise.
* generated./maxloc2_16_s1.c: Regenerated.
* generated./maxloc2_16_s4.c: Regenerated.
* generated./maxloc2_4_s1.c: Regenerated.
* generated./maxloc2_4_s4.c: Regenerated.
* generated./maxloc2_8_s1.c: Regenerated.
* generated./maxloc2_8_s4.c: Regenerated.
* generated./minloc2_16_s1.c: Regenerated.
* generated./minloc2_16_s4.c: Regenerated.
* generated./minloc2_4_s1.c: Regenerated.
* generated./minloc2_4_s4.c: Regenerated.
* generated./minloc2_8_s1.c: Regenerated.
* generated./minloc2_8_s4.c: Regenerated.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/maxloc2_16_s1.c
trunk/libgfortran/generated/maxloc2_16_s4.c
trunk/libgfortran/generated/maxloc2_4_s1.c
trunk/libgfortran/generated/maxloc2_4_s4.c
trunk/libgfortran/generated/maxloc2_8_s1.c
trunk/libgfortran/generated/maxloc2_8_s4.c
trunk/libgfortran/generated/minloc2_16_s1.c
trunk/libgfortran/generated/minloc2_16_s4.c
trunk/libgfortran/generated/minloc2_4_s1.c
trunk/libgfortran/generated/minloc2_4_s4.c
trunk/libgfortran/generated/minloc2_8_s1.c
trunk/libgfortran/generated/minloc2_8_s4.c
trunk/libgfortran/m4/maxloc2s.m4
trunk/libgfortran/m4/minloc2s.m4

[Bug c++/81722] [7/8 Regression] memory hog building c++ on i686-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Jakub Jelinek  ---
Let's just close this.

[Bug testsuite/81807] [8 Regression] many *.cc asan tests fail

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Is that still the case or was it some short episode in August?  I certainly
don't see such FAILs in my x86_64 or i686-linux regtests, nor can see them on
current powerpc64{,le}-linux gcc-testresults.

[Bug c++/83132] New: Error while redeclaring an enum with extra qualification

[jenda.tusil at gmail dot com]

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

Bug ID: 83132
   Summary: Error while redeclaring an enum with extra
qualification
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jenda.tusil at gmail dot com
  Target Milestone: ---

g++ -std=c++14 does not compile this:

enum E : int;
enum ::E : int{};

It says:
2:10: error: expected unqualified-id before ‘:’ token

Clang compiles it without errors, but gives a little wierd warning:
warning: extra qualification on member 'E' [-Wextra-qualification]

The bug was found in the context of this SO thread:
https://stackoverflow.com/q/47383199/6209703

It manifestes in most (all?) gcc versions on https://gcc.godbolt.org/

[Bug rtl-optimization/83133] New: Superflous x86 test instructions in generated assembly.

[maxim.yegorushkin at gmail dot com]

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

Bug ID: 83133
   Summary: Superflous x86 test instructions in generated
assembly.
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.yegorushkin at gmail dot com
  Target Milestone: ---

Consider the following code:

int negative(int);
int positive(int);
int nonnegative(int);
int nonpositive(int);

int f(int a, int b) {
int diff = a - b;
if(diff < 0)
return negative(diff);
else
return nonnegative(diff);
}

int g(int a, int b) {
int diff = a - b;
if(diff > 0)
return positive(diff);
else
return nonpositive(diff);
}

And the assembly generated with `-O3 -march=broadwell`:

f(int, int):
  subl %esi, %edi
  js .L4
  jmp nonnegative(int)
.L4:
  jmp negative(int)

g(int, int):
  subl %esi, %edi
  testl %edi, %edi < unnecessary instruction.
  jle .L6
  jmp positive(int)
.L6:
  jmp nonpositive(int)

g function assembly contains a superflous test instruction. It should not
generate that instruction, since sub instruction already sets all the required
flags. I first discovered this issue in gcc-4.9.2 and it is still there in
gcc-7.2.0.

Double-checked it with clang-5.0.0 and it seem to generate optimal assembly:

f(int, int): # @f(int, int)
  subl %esi, %edi
  js .LBB0_1
  jmp nonnegative(int) # TAILCALL
.LBB0_1:
  jmp negative(int) # TAILCALL

g(int, int): # @g(int, int)
  subl %esi, %edi
  jle .LBB1_2
  jmp positive(int) # TAILCALL
.LBB1_2:
  jmp nonpositive(int) # TAILCALL

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Does this still happen?  I'm bootstrapping/regtesting with
--enable-languages=default,obj-c++,lto,go,brig --enable-checking=yes,rtl,extra
on i686-linux often several times a day and haven't seen this.

[Bug fortran/83064] DO CONCURRENT inconsistent results

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> As I said in the other bug we're seeing
>
>real(real64), dimension(nsplit) :: tmp
>
> as "shared" amongst the outer loop iterations.
>
> ...
>
> Not sure if you need to mark compute somehow to avoid this
> and the testcase is invalid fortran or if the frontend is at fault.

IMO the testcase is valid fortran and, with my naive view of arrays returned by
a function, the returned array should be private to the function.

If I do the following changes

...
real(real64), dimension(nsplit) :: pi, pik
...
do concurrent (i = 1:nsplit)
pik = compute( low(i), high(i) )
pi(i) = sum(pik)
end do
...

the code works as expected, at least for my limited testing.

Do you understand why the code is not parallelized with
-ftree-parallelize-loops=4?

[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #27 from Jerry DeLisle  ---
This should be fixed now fairly well.  At this point there are not a lot of
major issues in our own libgfortran library. I will leave this bug report open
for a while if any issues arise.

Here is my latest profile. On my machine I am actuall getting slightly better
performance on trunk (8) vs. gfortran 6

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self  
 time   seconds   seconds name
 15.11  4.30 4.30 printf_positional
 14.65  8.47 4.17 __printf_fp_l
  7.13 10.50 2.03 __parse_one_specmb
  6.08 12.23 1.73 build_float_string
  4.16 13.42 1.19 formatted_transfer_scalar_write
  2.39 14.10 0.68 next_format0
  2.28 14.75 0.65 _IO_no_init
  2.23 15.38 0.64 __mpn_mul_1
  2.21 16.01 0.63 strtol_l_internal
  2.18 16.63 0.62 vfprintf
  1.86 17.16 0.53 __strchrnul_sse2
  1.79 17.67 0.51 _gfortrani_next_format
  1.77 18.18 0.51 _IO_str_init_static_internal
  1.76 18.68 0.50 __mpn_extract_double
  1.72 19.17 0.49 vsnprintf
  1.72 19.66 0.49 _IO_default_xsputn
  1.69 20.14 0.48 _int_malloc
  1.62 20.60 0.46 __memmove_sse2_unaligned_erms
  1.28 20.96 0.37 get_float_string
  1.12 21.28 0.32 _IO_padn
  1.02 21.57 0.29 __memset_sse2_unaligned
  1.02 21.86 0.29 __wmemset_sse2_unaligned
  0.91 22.12 0.26 flt128_ais

[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #26 from Jerry DeLisle  ---
Author: jvdelisle
Date: Thu Nov 23 17:19:18 2017
New Revision: 255108

URL: https://gcc.gnu.org/viewcvs?rev=255108=gcc=rev
Log:
2017-11-23  Jerry DeLisle  

Backport from trunk
PR libgfortran/78549
* io/io.h (newunit_free): Add declaration. Clean some whitespace.
* io/transfer.c (st_read_done, st_write_done): Call newunit_free.
* io/unit.c (newunit_free): Change type from static void to void.

Modified:
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/io.h
branches/gcc-7-branch/libgfortran/io/transfer.c
branches/gcc-7-branch/libgfortran/io/unit.c

[Bug target/83110] Relocation error when taking address of protected function in shared library.

[yyc1992 at gmail dot com]

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

--- Comment #2 from Yichao Yu  ---
What might be invalid about the source?

[Bug target/82975] ICE in baseness at rtlanal.c:6220

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
$CC -S -O2 -mtune=cortex-a57 -fno-sched-pressure -mfpu=neon -mfloat-abi=softfp
-O3 /work/wa3/src/gcc/gcc/testsuite/gcc.target/i386/pr78904-6.c 

Confirmed.

[Bug libstdc++/83127] Missing overload for operator << of std::stringstream for old ABI

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-23
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
What is void Main(void) ? Is this using mingw or something?

Please provide the missing information as requested by https://gcc.gnu.org/bugs

[Bug fortran/83064] DO CONCURRENT inconsistent results

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #4 from Richard Biener  ---
As I said in the other bug we're seeing

   real(real64), dimension(nsplit) :: tmp

as "shared" amongst the outer loop iterations.

It seems it is constructed that way by the frontend though:

MAIN__ ()
{
...
  real(kind=8) A.11[4];
...
  atmp.10.dtype = 537;
  atmp.10.dim[0].stride = 1;
  atmp.10.dim[0].lbound = 0;
  atmp.10.dim[0].ubound = 3;
  atmp.10.data = 
  atmp.10.offset = 0;
  compute (, _73, _74); [static-chain: ]

and

compute (struct array1_real(kind=8) & __result, integer(kind=8) & restrict low,
integer(kind=8) & restrict high)
{
  real(kind=8)[0:D.3540] * restrict __result.0;

so each invocation gets the same local array in MAIN__.

Not sure if you need to mark compute somehow to avoid this and the testcase
is invalid fortran or if the frontend is at fault.

[Bug tree-optimization/83129] New: calloc zero initialization is not taken into account by gcc

[denis.campredon at gmail dot com]

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

Bug ID: 83129
   Summary: calloc zero initialization is not taken into account
by gcc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

It seems that GCC does not know that calloc initialize the memory to zero.

The the following functions could be optimized to the same assemble, but only
f3 is optimized to:
xor eax, eax
ret

--
int f1() {
  char * i = __builtin_calloc(1, 1);
  return *i;
}

int f2() {
  struct s{int i;}* a = __builtin_calloc(1, sizeof(*a));

  return a->i;
}

int f3() {
char * i = (char*)__builtin_calloc(1, 1);
i[0] = 0;
return *i;
}
--

[Bug c++/83130] New: Compilation error related to 'using', template instantiations and default constructors

[nadult at fastmail dot fm]

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

Bug ID: 83130
   Summary: Compilation error related to 'using', template
instantiations and default constructors
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nadult at fastmail dot fm
  Target Milestone: ---

The following code fails to compile on new GCC (7.1, 7.2, 8.0). It compiles
without any problems on Clang. Compiled with: -std=c++1z

#include 

template  struct ValueBase {
ValueBase() {}
ValueBase(const ValueBase ) {}
ValueBase(ValueBase &) {}
void operator=(ValueBase &) {}
void operator=(const ValueBase ) {}
};

template  struct Value : public ValueBase {
Value(void *) {}
using ValueBase::ValueBase;
using ValueBase::operator=;
};

struct MyObj {
MyObj();
MyObj(const MyObj &);

struct Impl {
// Uncomment these lines to make the bug go away:
//Impl() = default;
//Impl(const Impl &) = default;

Value value;
};

std::pair pair;
};

MyObj::MyObj(const MyObj &) = default;

void someFunc() {
std::pair impl;
// Comment this line to make the bug go away
impl.first.value = nullptr;
}

[Bug c++/83130] Compilation error related to 'using', template instantiations and default constructors

[nadult at fastmail dot fm]

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

--- Comment #1 from Krzysztof Jakubowski  ---
someFunc() at the bottom is unnecessary.

[Bug target/82974] [8 regression] ICE in extract_insn, at recog.c:2305 on aarch64

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||ramana at gcc dot gnu.org
Version|7.0 |c++-concepts
Summary|ICE in extract_insn, at |[8 regression] ICE in
   |recog.c:2305 on aarch64 |extract_insn, at
   ||recog.c:2305 on aarch64
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
I can't provoke the latest tip of GCC7 to ICE but GCC 8 does ICE.

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||ramana at gcc dot gnu.org
Summary|Inexplicable use of NEON|[7/8 regression ]
   |for 64-bit math |Inexplicable use of NEON
   ||for 64-bit math
 Ever confirmed|0   |1
  Known to fail||7.2.1, 8.0

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  ---
Works as expected in GCC 6.

[Bug fortran/82973] [8 regression] ICE in output_constant_pool_2, at varasm.c:3896 on aarch64

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
Summary|ICE in  |[8 regression] ICE in
   |output_constant_pool_2, at  |output_constant_pool_2, at
   |varasm.c:3896 on aarch64|varasm.c:3896 on aarch64

--- Comment #3 from Ramana Radhakrishnan  ---
Confirmed.

I can't provoke this on GCC 7 though. Are you sure this is coming out GCC 7
rather than trunk ?

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
Author: olegendo
Date: Thu Nov 23 14:06:15 2017
New Revision: 255096

URL: https://gcc.gnu.org/viewcvs?rev=255096=gcc=rev
Log:
gcc/
PR target/83111
* config/sh/sh.md (udivsi3, divsi3, sibcall_value_pcrel,
sibcall_value_pcrel_fdpic): Use local variable instead of
operands[3].
(calli_tbr_rel): Add missing operand 2.
(call_valuei_tbr_rel): Add missing operand 3.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md

[Bug tree-optimization/83128] New: Unable to optimize {m,c}alloc when strings builtin are used

[denis.campredon at gmail dot com]

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

Bug ID: 83128
   Summary: Unable to optimize {m,c}alloc when strings builtin are
used
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

Currently gcc with -03 is able to optimize 
--
char f() {
  char * i = (char*)__builtin_malloc(100);

 i[0] = 'a';
 return i[0];
}
--
to
--
mov al, 97
ret

But is unable to do the same when string builtins are used with either malloc
or calloc.

-
char f() {
  char * i = (char*)__builtin_malloc(100);

  __builtin_memcpy(i, "a", 1);
  return i[0];
}
-

[Bug c/82050] [8 Regression] ICE on invalid code on x86_64-linux-gnu in column_range, at diagnostic-show-locus.c:1403

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 42697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42697=edit
pr82050.c

Here it is.