[Bug go/65616] New: libgobegin.a not compiled with -fPIC

[nyh at math dot technion.ac.il]

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

Bug ID: 65616
   Summary: libgobegin.a not compiled with -fPIC
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: nyh at math dot technion.ac.il
CC: cmang at google dot com

When one tries to build a position-independent executable (PIE or shared
object) with gccgo, the final linking stage fails. For example:

$ gccgo -pie -fpie hello.go
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.9.2/libgobegin.a(go-main.o):
relocation R_X86_64_32 against `runtime_main' can not be used when making a
shared object; recompile with -fPIC

The problem is that libgobegin.a was not compiled with -fPIC, so the main() it
contains is not usable to produce a shared object or PIE. That could easily be
rectified - go-main.c should be compiled with -fPIC. The main() function is
obviously not performance sensitive, so there is no downside in compiling it
with -fPIC.

When I compile go-main.o myself with -fPIC, and do "gccgo -pie -fpic hello.go
go-main.o", things work correctly.

There are many reasons why someone might want to produce a PIE or shared
object. My personal interest is for the OSv operating system (http://osv.io),
which can run Linux executables, but only position-independent ones (because
OSv is a single-address-space operating system).

[Bug ipa/65478] [5 regression] crafty performance regression

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #13 from Jan Hubicka  ---
Thanks, Martin.  I now get Search unduplicated by ipa-cp.  Funnily enough
however the fix to vortex slowdown (caused by bug in inliner's LTO
inline_failed bookeeping) caused differences in the inline decisions and now we
do not inline FirstOne and LastOne.
This seems to be very stupid implementation of clz
  int FirstOne(BITBOARD arg1)   
  { 
union doub {
  unsigned short i[4];  
  BITBOARD d;   
};  
#ifndef SPEC_CPU2000
register union doub x;  
#else   
union doub x;   
#endif /* SPEC_CPU2000 */   
x.d=arg1;   
#  if defined(LITTLE_ENDIAN_ARCH)   
if (x.i[3]) 
  return (first_ones[x.i[3]]);  
if (x.i[2]) 
  return (first_ones[x.i[2]]+16);   
if (x.i[1]) 
  return (first_ones[x.i[1]]+32);   
if (x.i[0]) 
  return (first_ones[x.i[0]]+48);   
#  endif
#  if !defined(LITTLE_ENDIAN_ARCH)  
if (x.i[0]) 
  return (first_ones[x.i[0]]);  
if (x.i[1]) 
  return (first_ones[x.i[1]]+16);   
if (x.i[2]) 
  return (first_ones[x.i[2]]+32);   
if (x.i[3]) 
  return (first_ones[x.i[3]]+48);   
#  endif
return(64); 
  } 
which unfortunately gets estimates as quite large by inliner:

Analyzing function body size: FirstOne  
Accounting size:2.00, time:0.00 on new predicate:(not inlined)  

 BB 2 predicate:(true)  
  x.d = arg1_3(D);  
freq:1.00 size:  1 time:  1 
Accounting size:1.00, time:1.00 on predicate:(true) 
  _5 = x.i[3];  
freq:1.00 size:  1 time:  1 
Accounting size:1.00, time:1.00 on predicate:(true) 
  if (_5 != 0)  
freq:1.00 size:  2 time:  2 
Accounting size:2.00, time:2.00 on predicate:(true) 

 BB 4 predicate:(true)  
  _9 = x.i[2];  
freq:0.61 size:  1 time:  1 
Accounting size:1.00, time:0.61 on predicate:(true) 
  if (_9 != 0)  
freq:0.61 size:  2 time:  2 
Accounting size:2.00, time:1.22 on predicate:(true) 
...
so at thi

[Bug c++/65617] New: new valgrind error in update_costs_from_copies

[dcb314 at hotmail dot com]

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

Bug ID: 65617
   Summary: new valgrind error in update_costs_from_copies
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Created attachment 35170
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35170&action=edit
C++ source code

Given the source code from #47903, there is a new valgrind error in
update_costs_from_copies.

$ diff 20150323.out 20150329.out
> ==13155== Conditional jump or move depends on uninitialised value(s)
> ==13155==at 0xBDF10D: update_costs_from_copies(ira_allocno*, bool, bool) [
clone .constprop.58] (ira-color.c:1445)
> ==13155==by 0xBE12B9: assign_hard_reg(ira_allocno*, bool) [clone .constpro
p.55] (ira-color.c:1896)
> ==13155==by 0xBEA536: pop_allocnos_from_stack (ira-color.c:2589)
> ==13155==by 0xBEA536: color_allocnos (ira-color.c:3095)

This new error appeared sometime >= 20150323.

ira-color.c:1445 is

  ira_assert (hard_regno >= 0 && ALLOCNO_CLASS (allocno) != NO_REGS);

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[trippels at gcc dot gnu.org]

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

--- Comment #28 from Markus Trippelsdorf  ---
Yes, it is still 15% on my machine, too:

markus@x4 ~ % time g++ -w -Ofast tramp3d-v4.cpp
g++ -w -Ofast tramp3d-v4.cpp  25.45s user 0.33s system 99% cpu 25.832 total

(At least this is still faster than clang:
markus@x4 ~ % time clang++ -w -Ofast tramp3d-v4.cpp
clang++ -w -Ofast tramp3d-v4.cpp  31.03s user 0.15s system 100% cpu 31.183
total)

[Bug libfortran/65563] Segfault on reopening fort.xxx file with explicit name

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
I upgraded to recent trunk (which I hadn't done for some time) and found that I
can no longer reproduce the error with 5.0.

So I'll make this into a test case and commit this as obvious, to make sure no
regressions come up.

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #13 from Mikael Pettersson  ---
This wrong-code bug still occurs with gcc-4.9 and gcc-4.8 on powerpc64, but not
with gcc-4.7 so it's a regression there.

[Bug testsuite/64983] Incomplete summary when regtesting with dejagnu 1.5.2.

[howarth.at.gcc at gmail dot com]

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

--- Comment #9 from Jack Howarth  ---
Note that this issue seems to only be fixable from within dejagnu and that the
commit of 6d2e2d3791bcea70131a6cf64a0a522a7b8e effectively broke the
log_summary proc in dejagnu's lib/framework.exp by reseting the testcnt global
which is used as follows...

# If the tool set `testcnt', it wants us to do a sanity check on the
# total count, so compare the reported number of testcases with the
# expected number.  Maintaining an accurate count in `testcnt' isn't easy
# so it's not clear how often this will be used.
if {[info exists testcnt]} {
if { $testcnt > 0 } {
set totlcnt 0
# total all the testcases reported
foreach x { FAIL PASS XFAIL KFAIL XPASS KPASS UNTESTED UNRESOLVED
UNSUPPORTED } {
incr totlcnt test_counts($x,$which)
}
set testcnt test_counts(total,$which)

if { $testcnt>$totlcnt || $testcnt<$totlcnt } {
if { $testcnt > $totlcnt } {
set mismatch "unreported  [expr {$testcnt - $totlcnt}]"
}
if { $testcnt < $totlcnt } {
set mismatch "misreported [expr {$totlcnt - $testcnt}]"
}
} else {
verbose "# of testcases run $testcnt"
}

if {[info exists mismatch]} {
clone_output "### ERROR: totals do not equal number of
testcases run"
clone_output "### ERROR: # of testcases expected$testcnt"
clone_output "### ERROR: # of testcases reported$totlcnt"
clone_output "### ERROR: # of testcases $mismatch\n"
}
}
}
foreach x { PASS FAIL XPASS XFAIL KPASS KFAIL UNRESOLVED UNTESTED
UNSUPPORTED } {
set val $test_counts($x,$which)
if { $val > 0 } {
set mess "# of $test_counts($x,name)"
if { $xml } {
xml_output "  "
xml_output "$x"
xml_output "$mess"
xml_output "$val"
xml_output "  "
}
if { [string length $mess] < 24 } {
append mess "\t"
}
clone_output "$mess\t$val"
}

[Bug testsuite/64983] Incomplete summary when regtesting with dejagnu 1.5.2.

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
I confirm that the dejagnu 1.5.2-3 packaging in fink restores the correct
results.

Thanks for the debugging.

[Bug target/65564] [5 Regression] builtin-bnd-narrow-ptr-bounds-2-nov.c:15:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5745

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 29 14:20:29 2015
New Revision: 221761

URL: https://gcc.gnu.org/viewcvs?rev=221761&root=gcc&view=rev
Log:
2015-03-29  Thomas Koenig  

PR libgfortran/65564
* gfortran.dg/open_errors_2.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/open_errors_2.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/65563] Segfault on reopening fort.xxx file with explicit name

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
Test case committed, resolving as FIXED.

[Bug libfortran/65563] Segfault on reopening fort.xxx file with explicit name

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 29 14:33:09 2015
New Revision: 221762

URL: https://gcc.gnu.org/viewcvs?rev=221762&root=gcc&view=rev
Log:
2015-03-29  Thomas Koenig  

PR libgfortran/65563
Refer to correct PR in ChangeLog.



Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/65564] [5 Regression] builtin-bnd-narrow-ptr-bounds-2-nov.c:15:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5745

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
Of course, the commit had nothing to do with this PR.

[Bug ada/65618] New: [5 Regression] gnat bootstrap comparison failure on mips{,el}-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 65618
   Summary: [5 Regression] gnat bootstrap comparison failure on
mips{,el}-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

seen building trunk 20150328. I'm not entirely sure if this is a regression.
Apparently my earlier distro builds set STAGE3_CFLAGS += -gtoggle (same as in
stage2) in the past, and maybe were papering over the problem.

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/ada/a-except.o differs
Makefile:22697: recipe for target 'compare' failed
make[4]: *** [compare] Error 1

reference to the complete build logs:
https://buildd.debian.org/status/package.php?p=gcc-5&suite=experimental

[Bug ipa/65478] [5 regression] crafty performance regression

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka  ---
Author: hubicka
Date: Sun Mar 29 15:38:52 2015
New Revision: 221763

URL: https://gcc.gnu.org/viewcvs?rev=221763&root=gcc&view=rev
Log:

PR ipa/65478
* params.def (PARAM_IPA_CP_RECURSION_PENALTY) : New.
(PARAM_IPA_CP_SINGLE_CALL_PENALTY): Likewise.
* ipa-prop.h (ipa_node_params): New flags node_within_scc and
node_calling_single_call.
* ipa-cp.c (count_callers): New function.
(set_single_call_flag): Likewise.
(initialize_node_lattices): Count callers and set single_flag_call if
necessary.
(incorporate_penalties): New function.
(good_cloning_opportunity_p): Use it, dump new flags.
(propagate_constants_topo): Set node_within_scc flag if appropriate.
* doc/invoke.texi (ipa-cp-recursion-penalty,
ipa-cp-single-call-pentalty): Document.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-prop.h
trunk/gcc/params.def

[Bug ipa/65588] [5 Regression] lto1: internal compiler error: Segmentation fault

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Author: hubicka
Date: Sun Mar 29 15:41:55 2015
New Revision: 221764

URL: https://gcc.gnu.org/viewcvs?rev=221764&root=gcc&view=rev
Log:

PR ipa/65588
* gcc.target/i386/pr65588.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr65588.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/65456] powerpc64le autovectorized copy loop missed optimization

[wschmidt at gcc dot gnu.org]

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

--- Comment #15 from Bill Schmidt  ---
That last bit also needs an update to the table in ISA 2.07 II.2, p. 754.

I'm planning to include the change for the vector alignment piece in my P8
unaligned vectors patch, since it seems relevant there.  I think we should
probably fix this other bit separately, as that will likely need some more
extensive testing.

[Bug target/63683] m32c-rtems ICE unable to find spill register compiling libgcc

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #2 from Bernd Edlinger  ---
Hi,

this looks like a duplicate of pr50928

[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Jason Merrill  ---
I think these additional testcases should go on bug 65398, not this one; these
cases also deal with the address of an array element.

[Bug target/65456] powerpc64le autovectorized copy loop missed optimization

[wschmidt at gcc dot gnu.org]

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

--- Comment #16 from Bill Schmidt  ---
Proposed patch added to the general P8 unaligned vector patch:

https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01502.html

[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||jason at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #5 from Jason Merrill  ---
Another testcase, derived from one attached to bug 65509:

char s[] = "s";

#define SA(X) static_assert((X),#X);
SA((&s[0] + 0) != (&s[0] + 1));

here we aren't indirecting the addresses, so I think cxx_fold_indirect_ref
isn't the right place for the fix.

[Bug c++/65619] New: friend declaration with template template parameter not recognized

[nathanm at outlook dot de]

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

Bug ID: 65619
   Summary: friend declaration with template template parameter
not recognized
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathanm at outlook dot de

The following code:
template 
class foo
{
int i;

template  class T>
friend foo> func();
};

template  class T>
foo> func()
{
foo> f;
f.i = 3;
return f;
}

template 
struct test {};

int main()
{
func();
}
does not compile with g++ 4.9.2. It is as far as I can tell, valid C++ code and
does compile with clang.
The error message is:
prog.cpp: In instantiation of 'foo > func() [with T = test]':
prog.cpp:23:13:   required from here
prog.cpp:4:6: error: 'int foo >::i' is private
  int i;
  ^
prog.cpp:14:6: error: within this context
  f.i = 3;
  ^
Changing the code, so T isn't a template template parameter any more makes it
compile. Also changing the return value to void.

[Bug lto/61635] LTO partitioner does not handle &&label in statics

[andi-gcc at firstfloor dot org]

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

--- Comment #7 from Andi Kleen  ---
Still happens with current trunk and with newer LTO Linux kernels (4.0-rc*)

[Bug bootstrap/60946] Current 4.9 branch does not boot strap on FC20 with systemtap-devel installed

[andi-gcc at firstfloor dot org]

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

--- Comment #8 from Andi Kleen  ---
I still get that one with current trunk on my fedora 21 system.

[Bug target/65612] g++.dg/ext/mvXX.C don't work with -fPIE -pie

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
I don't think the compiler is at fault here.

Tracing the executable, I got:

Breakpoint 1, 0x4780 in __cpu_indicator_init@plt ()
(gdb) disass
Dump of assembler code for function __cpu_indicator_init@plt:
=> 0x4780 <+0>: jmpq   *0x2018ba(%rip)# 0x55756040
<__cpu_indicator_i...@got.plt>
   0x4786 <+6>: pushq  $0x4
   0x478b <+11>:jmpq   0x4720
End of assembler dump.
(gdb) p/x *0x55756040
$1 = 0x786

(gdb) si
0x0786 in ?? ()

Some kind of fixup is missing for __cpu_indicator_i...@got.plt value.

[Bug fortran/59016] f951: internal compiler error: Segmentation fault

[drikosev at otenet dot gr]

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

drikosev at otenet dot gr changed:

   What|Removed |Added

 CC||drikosev at otenet dot gr

--- Comment #6 from drikosev at otenet dot gr ---
Created attachment 35171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35171&action=edit
Invalid locus when an interface function is undefined

The attached patch has various prerequisites and can be applied only manually!

A complete list of the prerequisites (patches) for gcc-4.8.4 can be found at: 

http://users.otenet.gr/~drikosev/downloads/pc-2015-03-28.tar.xz

[Bug fortran/59016] f951: internal compiler error: Segmentation fault

[drikosev at otenet dot gr]

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

--- Comment #7 from drikosev at otenet dot gr ---
Hi,

The reduced test case which has been posted by janus (comment 1) crashes also
4.8.4 and gcc 5.0 (the latter was copied from trunc a few days ago).

The backtrace I get agrees with that of Dominique's (comment 4). The problem is
likely in function "check_interface0"; the locus of "p->sym" is invalid when
gfc_error is called:

   gfc_error ("Procedure '%s' in %s at %L is neither function nor "
  "subroutine", p->sym->name, interface_name,
  &p->sym->declared_at);

Likely, the reason is that there is a symbol only in the access statement but
the expected function/subroutine hasn't been defined. 

Perhaps, one can avoid the segmentation fault with an addition argument in
function "check_interface0".  The argument will be not null only if called by
function "check_sym_interfaces"; in which case it will be the symbol that
appears in the access-stmt.

I'm not really if we can reproduce the error for intrinsic assignment operators
but the solution could be similar.

Provided that such a patch will be implemented, the second error message for
the example at comment 1 would look like:

pr59016.f90:2.30:

PUBLIC :: atomic_kind_type
  1
Error: undefined function/subroutine for generic interface 'atomic_kind_type'
at (1) 

---
PS: please also note that I've not run the regression tests!

[Bug c/65620] New: Incorrect warning for !! with -Wlogical-not-parentheses

[andi-gcc at firstfloor dot org]

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

Bug ID: 65620
   Summary: Incorrect warning for !! with
-Wlogical-not-parentheses
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org

Created attachment 35172
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35172&action=edit
test case

When building the linux 4.0-rc5 kernel with 5.0 there are several imho
bogus warnings like

warning: logical not is only applied to the left hand side of comparison
[-Wlogical-not-parentheses]

for constructs like this:

  !!test_bit(...) != ...

The warning shouldn't warn for !! which is reasonably common. Looking at the
c/cp parsers there is already code to check for this, but it doesn't seem to
work here.

In the kernel case test_bit actually expands to a complex macro like

 if (usage->type == 0x01  && !!(__builtin_constant_p((usage->code)) ? 
  constant_test_bit((usage->code), (input->key)) :
variable_test_bit((usage->key),   
   (input->key)))

I'm attaching an (already delta'ed but still quite big) test case

C++ likely has the same problem (but not tested)

[Bug target/65612] g++.dg/ext/mvXX.C don't work with -fPIE -pie

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-29
 CC||tmsriram at google dot com
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
(gdb) bt
#0  0x0706 in ?? ()
#1  0x4b69 in foo ()
at /export/gnu/import/git/gcc/gcc/testsuite/g++.dg/ext/mv1.C:32
#2  0x77de76b8 in _dl_relocate_object ()
   from /lib64/ld-linux-x86-64.so.2
#3  0x77ddea4a in dl_main () from /lib64/ld-linux-x86-64.so.2
#4  0x77df28d5 in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2
#5  0x77ddfce1 in _dl_start () from /lib64/ld-linux-x86-64.so.2
#6  0x77ddbcd8 in _start () from /lib64/ld-linux-x86-64.so.2
#7  0x0001 in ?? ()
#8  0x7fffe18d in ?? ()
#9  0x in ?? ()
(gdb) f 1
#1  0x4b69 in foo ()
at /export/gnu/import/git/gcc/gcc/testsuite/g++.dg/ext/mv1.C:32
32int (*p)() = &foo;
(gdb) disass
Dump of assembler code for function _Z3foov.resolver(void):
   0x4b60 <+0>:sub$0x8,%rsp
   0x4b64 <+4>:callq  0x4700 <__cpu_indicator_init@plt>
=> 0x4b69 <+9>:mov0x200740(%rip),%rsi#
0x557552b0
   0x4b70 <+16>:mov0xc(%rsi),%edx
   0x4b73 <+19>:mov%edx,%eax
   0x4b75 <+21>:mov%edx,%ecx
   0x4b77 <+23>:and$0x400,%eax
   0x4b7c <+28>:and$0x40,%ecx
   0x4b7f <+31>:cmp%ecx,%eax
   0x4b81 <+33>:cmovg  %ecx,%eax
   0x4b84 <+36>:test   %eax,%eax
   0x4b86 <+38>:jle0x4b98
<_Z3foov.resolver(void)+56>
   0x4b88 <+40>:lea-0xbf(%rip),%rax# 0x4ad0
<_Z3foov.avx2_ssse3>
   0x4b8f <+47>:add$0x8,%rsp
   0x4b93 <+51>:retq   
   0x4b94 <+52>:nopl   0x0(%rax)
   0x4b98 <+56>:cmpl   $0x8,0x8(%rsi)
   0x4b9c <+60>:jne0x4bb0
<_Z3foov.resolver(void)+80---Type  to continue, or q  to
quit---q
Quit
(gdb) disass 0x4700,+16
Dump of assembler code from 0x4700 to 0x4710:
   0x4700 <__cpu_indicator_init@plt+0>:jmpq   *0x200be2(%rip)  
 # 0x557552e8 <__cpu_indicator_i...@got.plt>
   0x4706 <__cpu_indicator_init@plt+6>:pushq  $0x2
   0x470b <__cpu_indicator_init@plt+11>:jmpq   0x46c0
End of assembler dump.
(gdb) 

We can't call __cpu_indicator_init in PIE while PIE is being relocated.
Its .got.plt section hasn't been updated.  It works for non-PIE since
no update on .got.plt section is required.  Can we move __cpu_indicator_init
to main executable?

[Bug target/65612] g++.dg/ext/mvXX.C don't work with -fPIE -pie

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Created attachment 35173
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35173&action=edit
A patch to move __cpu_indicator_init

This patch is incomplete.  We need to handle backward compatibility
as well as versioned functions in shared library.

[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level

[aoliva at gcc dot gnu.org]

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

--- Comment #26 from Alexandre Oliva  ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01491.html

[Bug target/65351] [5 Regression] ld: absolute addressing (perhaps -mdynamic-no-pic) used in _byte_common_op_match_null_string_p from ../libiberty/pic/libiberty.a(regex.o) not allowed ... on powerpc-a

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  ---
Created attachment 35174
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35174&action=edit
Patch addressing review comments

Will be posting this to @patches after some more checking.

[Bug fortran/59016] f951: internal compiler error: Segmentation fault

[drikosev at otenet dot gr]

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

--- Comment #8 from drikosev at otenet dot gr ---

When gfortran reports the error, it expects that the name 'atomic_kind_type' is
likely a procedure or function; but the syntax of the access-stmt is:

access-stmt ::= access-spec [ [ :: ] access-id-list ]
access-id   ::= use-name | generic-spec
access-spec::=

Each use-name shall be the name of a named variable, procedure, derived type,
named constant, or namelist group.

Perhaps, a more accurate error message could be:

PUBLIC :: atomic_kind_type
  1
Error: Undefined use-name 'atomic_kind_type' in access statement at (1)

[Bug libffi/65567] ERROR: tcl error sourcing /test/gnu/gcc/gcc/libffi/testsuite/libffi.complex/complex.exp

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Author: danglin
Date: Sun Mar 29 20:46:17 2015
New Revision: 221765

URL: https://gcc.gnu.org/viewcvs?rev=221765&root=gcc&view=rev
Log:
PR libffi/65567
* testsuite/lib/libffi.exp (libffi_feature_test): Use split to ensure
lindex is applied to a list.


Modified:
trunk/libffi/ChangeLog
trunk/libffi/testsuite/lib/libffi.exp

[Bug target/65612] g++.dg/ext/mvXX.C don't work with -fPIE -pie

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #35173|0   |1
is obsolete||

--- Comment #4 from H.J. Lu  ---
Created attachment 35175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35175&action=edit
A patch to add __cpu_indicator_init to libgcc.a

This patch adds _cpu_indicator_init to libgcc.a and hides
it from linker with backward binary compatibility.

[Bug libffi/65567] ERROR: tcl error sourcing /test/gnu/gcc/gcc/libffi/testsuite/libffi.complex/complex.exp

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Fixed.

[Bug libstdc++/65500] [5 Regression] FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #5 from John David Anglin  ---
Testsuite failures are fixed.

[Bug bootstrap/65621] New: boot strap with checking enabled ICEs

[andi-gcc at firstfloor dot org]

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

Bug ID: 65621
   Summary: boot strap with checking enabled ICEs
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org

target: x86_64-linux

../../../../gcc/libstdc++-v3/libsupc++/tinfo.cc:82:1: internal compiler error:
in mark_functions_to_output, at cgraphunit.c:1307
 }
 ^
0xb25f0b mark_functions_to_output
../../gcc/gcc/cgraphunit.c:1302
0xb29137 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2330
0xb29313 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2444
0x884c9a cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4755

[Bug bootstrap/65621] boot strap with checking enabled ICEs

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andi Kleen  ---
Never mind. Was caused by a local modification.

[Bug ipa/65478] [5 regression] crafty performance regression

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka  ---
The inline bump needed is about 23.  Richard, i guess convincing early
optimizers to turn that hack into shifts (that is done by GCC but only at RTL
time), is out of reach for this release, right?

[Bug target/65507] avr-gcc -fmerge-all-constants causes internal compiler error in get_section, at varasm.c:312

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #3 from Georg-Johann Lay  ---
Duplicate.

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

[Bug target/57597] ICE: in get_section, at varasm.c:312: Segmentation fault with -fmerge-all-constants

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||dfnsonfsduifb at gmx dot de

--- Comment #1 from Georg-Johann Lay  ---
*** Bug 65507 has been marked as a duplicate of this bug. ***

[Bug c++/65622] New: No known conversion to initializer_list with default argument in constructor

[david.d.kretzmer at gmail dot com]

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

Bug ID: 65622
   Summary: No known conversion to initializer_list with default
argument in constructor
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.d.kretzmer at gmail dot com


#include 
struct Foo
{
  Foo(std::initializer_list = {}) {}
};
Foo f{1};


The above code produces the following error (tested in 4.7, 4.8 and 4.9):

error: no matching function for call to 'Foo::Foo()'
note: candidates are:
note: constexpr Foo::Foo(const Foo&)
note: no known conversion for argument 1 from 'int' to 'const Foo&'
note: constexpr Foo::Foo(Foo&&)
note: no known conversion for argument 1 from 'int' to 'Foo&&'
note: Foo::Foo(std::initializer_list)
note: no known conversion for argument 1 from 'int' to
'std::initializer_list'

When I remove the default argument it compiles without errors.
The error only occurs in constructors, normal functions are not affected.

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[hubicka at gcc dot gnu.org]

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

--- Comment #29 from Jan Hubicka  ---
I also tested with -Os and compile times seems about same as for 4.9 modulo
noise.

The following one liner brings instruction and function count in final binary
to same as in 4.9:
Index: ipa-inline.c
===
--- ipa-inline.c(revision 221757)
+++ ipa-inline.c(working copy)
@@ -1099,7 +1099,7 @@ edge_badness (struct cgraph_edge *edge,
numerator = numerator >> 11;
   denominator = growth;
   if (callee_info->growth > 0)
-   denominator *= callee_info->growth;
+   denominator *= callee_info->growth * callee_info->growth;

   badness = - numerator / denominator;



I think this makes a lot of sense - it somehow makes growth of a given call
more important than growth for inlining everything and it also makes inliner to
more strongly prefer small growth, so I think I will commit it after testing
with plan for quick reversal if some benchmarks decrease significantly. (in
fact I had that patch scheduled for bechmarking for couple months)

I am testing it on my copy of C++ suite and will try to run firefox benchmarks
and look for off-noise differences.

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[hubicka at gcc dot gnu.org]

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

--- Comment #30 from Jan Hubicka  ---
Author: hubicka
Date: Mon Mar 30 02:00:56 2015
New Revision: 221769

URL: https://gcc.gnu.org/viewcvs?rev=221769&root=gcc&view=rev
Log:

PR ipa/65076
* ipa-inline.c (edge_badness): Base denominator on callee's
grwoth squared.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c

[Bug target/65612] Multiversioning doesn't work with DSO nor PIE

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.5
Summary|g++.dg/ext/mvXX.C don't |Multiversioning doesn't
   |work with -fPIE -pie|work with DSO nor PIE

[Bug target/65612] Multiversioning doesn't work with DSO nor PIE

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
Created attachment 35176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35176&action=edit
A testcase with DSO

[hjl@gnu-tools-1 pr65612]$ make
g++ -O2-c -o main.o main.cc
g++ -shared -fPIC -O2  -o libmv20.so mv20.cc
g++ -O2  -o x main.o libmv20.so -Wl,-R,.
./x
Makefile:8: recipe for target 'all' failed
make: *** [all] Segmentation fault (core dumped)
[hjl@gnu-tools-1 pr65612]$

[Bug lto/61635] LTO partitioner does not handle &&label in statics

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

--- Comment #8 from Jan Hubicka  ---
I am testing fix that is small enough for GCC 5 (and backportable to release
branches I guess)

[Bug lto/61635] LTO partitioner does not handle &&label in statics

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  ---
This is patch I am testing

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
I filled in binutils PR for extension of plugin API
https://sourceware.org/bugzilla/show_bug.cgi?id=18178

[Bug c++/65623] New: Incorrect location of error messages on calling copy constructor of unique_ptr

[chengniansun at gmail dot com]

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

Bug ID: 65623
   Summary: Incorrect location of error messages on calling copy
constructor of unique_ptr
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com

When I was compiling a large class file, gcc emit an error that I called the
copy constructor of unique_ptr. It took me a while to figure out the cause of
the error. I find that clang pinpoints this error.  

I think this error message can be improved with a precise location of the
error. The current location is just the end of the initializer list.  

$: cat t.cc 
#include 
using namespace std;

class A {
  const int a;
  const unique_ptr b;
  const int c;
public:
  A(const A& copy) : a(copy.a), 
b(copy.b), 
c(copy.c) {
  }
};


$: g++-4.9 -std=c++11 -c t.cc 
t.cc: In copy constructor ‘A::A(const A&)’:
t.cc:11:13: error: use of deleted function ‘std::unique_ptr<_Tp,
_Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = A; _Dp =
std::default_delete]’
 c(copy.c) {
 ^
In file included from /usr/local/gcc-4.9.0/include/c++/4.9.0/memory:81:0,
 from t.cc:1:
/usr/local/gcc-4.9.0/include/c++/4.9.0/bits/unique_ptr.h:356:7: note: declared
here
   unique_ptr(const unique_ptr&) = delete;
   ^



$: clang-trunk -std=c++11 -c t.cc 
t.cc:10:5: error: call to deleted constructor of 'const unique_ptr'
b(copy.b), 
^ ~~
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:273:7:
note: 'unique_ptr' has been explicitly marked deleted here
  unique_ptr(const unique_ptr&) = delete;
  ^
1 error generated.
$:

[Bug target/65624] New: ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic.

[chefmax at gcc dot gnu.org]

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

Bug ID: 65624
   Summary: ICE in aarch64-builtins.c when expanding 4-argument
aarch64 intrinsic.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chefmax at gcc dot gnu.org
  Host: i686-linux-gnu
Target: aarch64-linux-gnu
 Build: i686-pc-linux-gnu

Created attachment 35178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35178&action=edit
Reprocase.

When testing cross toolchain for AArch64 on 32 bit host (i686), I ran to the
such issue:

$
/home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/libexec/gcc/aarch64-tizen-linux-gnueabi/5.0.0/cc1
-quiet ref_vqdmlsl_lane.c -quiet -dumpbase ref_vqdmlsl_lane.c
-march=armv8-a+simd -mlittle-endian -mabi=lp64 -auxbase-strip
ref_vqdmlsl_lane.gccarm.o -g -Wall -Wno-unused-variable -Wno-unused-function
-Wno-error=unused-local-typedefs -fshort-wchar -freport-bug

// In file included from ref_vqdmlal_lane.c:27:0,
//  from ref_vqdmlsl_lane.c:29:
//
/home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/lib/gcc/aarch64-tizen-linux-gnueabi/5.0.0/include/arm_neon.h:
In function 'exec_vqdmlsl_lane':
//
/home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/lib/gcc/aarch64-tizen-linux-gnueabi/5.0.0/include/arm_neon.h:19165:10:
internal compiler error: tree check: accessed operand 8 of call_expr with 7
operands in aarch64_simd_expand_args, at config/aarch64/aarch64-builtins.c:915
//return __builtin_aarch64_sqdmlsl_lanev4hi (__a, __b, __c, __d);
//   ^
// 0x89b4948 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/tree.c:9507
// 0x8a3c9f9 tree_operand_check
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/tree.h:3346
// 0x8a3c9f9 aarch64_simd_expand_args
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/config/aarch64/aarch64-builtins.c:915
// 0x8a3c9f9 aarch64_simd_expand_builtin(int, tree_node*, rtx_def*)
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/config/aarch64/aarch64-builtins.c:1075
// 0x828256b expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/builtins.c:5967
// 0x83a3bb0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/expr.c:10489
// 0x83b0ce6 store_expr_with_bounds(tree_node*, rtx_def*, int, bool,
tree_node*)
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/expr.c:5385
// 0x83b37c9 expand_assignment(tree_node*, tree_node*, bool)
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/expr.c:5154
// 0x82a9a6e expand_call_stmt
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/cfgexpand.c:2397
// 0x82a9a6e expand_gimple_stmt_1
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/cfgexpand.c:3343
// 0x82a9a6e expand_gimple_stmt
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/cfgexpand.c:3497
// 0x82aaf80 expand_gimple_basic_block
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/cfgexpand.c:5509
// 0x82ad761 execute
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/cfgexpand.c:6127
// Please submit a full bug report,
// with preprocessed source if appropriate.
// Please include the complete backtrace with any bug report.
// See  for instructions.

Looking to the GCC source code (aarch64_simd_expand_builtin function), I've
noticed that all arguments and return value types are stored to
args[SIMD_MAX_BUILTIN_ARGS] array. In aarch64_simd_expand_builtin, we also
write special SIMD_ARG_STOP indicator to this array after all arguments. But if
we have 4-argument intrinsic with return value, we will overflow
args[SIMD_MAX_BUILTIN_ARGS] with SIMD_ARG_STOP since SIMD_MAX_BUILTIN_ARGS is
defined as 5. I'm attaching preprocessed reprocase and trivial fix.

max@max:~/build$ aarch64-tizen-linux-gnueabi-gcc -v
// Configured with:
/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=aarch64-tizen-linux-gnueabi
--prefix=/home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen
--with-sysroot=/home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/aarch64-tizen-linux-gnueabi/sys-root
--disable-libmudflap --enable-libssp --disable-nls --disable-libstdcxx-pch
--disable-multilib --disable-gnu-unique-object --enable-linker-build-id
--with-arch=armv8-a --enable-libgomp --enable-p

[Bug target/65624] ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic.

[chefmax at gcc dot gnu.org]

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

--- Comment #1 from Maxim Ostapenko  ---
Created attachment 35179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35179&action=edit
Trivial fix

Trivial fix.