[Bug middle-end/83764] internal compiler error: in gimple_get_virt_method_for_vtable

[lesliezhai at llvm dot org.cn]

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

--- Comment #2 from Leslie Zhai  ---
And GCC 8.x workaround just remove the assert:

6751   /* The virtual tables should always be born with constructors
6752  and we always should assume that they are avaialble for   
6753  folding.  At the moment we do not stream them in all cases,   
6754  but it should never happen that ctor seem unreachable.  */
6755   gcc_assert (init);   
6756   if (init == error_mark_node) 
6757 {  
6758   /* Pass down that we lost track of the target.  */   
6759   if (can_refer)   
6760 *can_refer = false;
6761   return NULL_TREE;
6762 }

[Bug middle-end/83764] internal compiler error: in gimple_get_virt_method_for_vtable

[lesliezhai at llvm dot org.cn]

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

--- Comment #1 from Leslie Zhai  ---
Typo:
- I have no idea why `in_lto_p` is NULL?
+ I have no idea why `in_lto_p` is false?

[Bug middle-end/83764] New: internal compiler error: in gimple_get_virt_method_for_vtable

[lesliezhai at llvm dot org.cn]

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

Bug ID: 83764
   Summary: internal compiler error: in
gimple_get_virt_method_for_vtable
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lesliezhai at llvm dot org.cn
  Target Milestone: ---

Hi GCC developers,

When I use Linaro GCC 7.2-2017.11 arm-linux-gnueabihf cross-compile
toolchain[1] to build L4Re and L4Linux[2] 

Toolchain thrown such error:
/data/project/xiangzhai/l4re/l4/pkg/io/io/server/src/virt/vmsi.cc:28:1:
internal compiler error: in gimple_get_virt_method_for_vtable, at
gimple-fold.c:6467
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


l4re/l4/pkg/io/io/server/src/virt/vmsi.cc:28 define a static variable in an
anonymous namespace[3]

26 namespace {  
27   static Vi::Resource_factory_t
__vmsifactory;
28 }


Linaro gcc-7.2.1/gcc/gimple-fold.c:6467 call gcc_assert[4]

6460   /* The virtual tables should always be born with constructors
6461  and we always should assume that they are avaialble for   
6462  folding.  At the moment we do not stream them in all cases,   
6463  but it should never happen that ctor seem unreachable.  */
6464   gcc_assert (init);   
6465   if (init == error_mark_node) 
6466 {  
6467   gcc_assert (in_lto_p);   
6468   /* Pass down that we lost track of the target.  */   
6469   if (can_refer)   
6470 *can_refer = false;
6471   return NULL_TREE;
6472 }

I have no idea why `in_lto_p` is NULL?
Please give me some suggestion, thanks a lot!

[1]
https://releases.linaro.org/components/toolchain/binaries/latest/arm-linux-gnueabihf/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz
[2] http://os.inf.tu-dresden.de/pipermail/l4-hackers/2018/008189.html
[3]
https://svn.l4re.org/repos/oc/l4re/trunk/l4/pkg/io/io/server/src/virt/vmsi.cc
[4]
https://releases.linaro.org/components/toolchain/gcc-linaro/latest/gcc-linaro-7.2-2017.11.tar.xz

Regards,
Leslie Zhai

[Bug fortran/83763] New: PDT variable sees content deallocated if variable is passed as an input to a function, and the function result is assigned to that same variable

[berke.durak at gmail dot com]

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

Bug ID: 83763
   Summary: PDT variable sees content deallocated if variable is
passed as an input to a function, and the function
result is assigned to that same variable
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: berke.durak at gmail dot com
  Target Milestone: ---

% cat test_case.f90
module bar
  implicit none

  type :: foo(n)
 integer, len :: n=10
 real :: vec(n)
  end type foo

contains

  function baz(a) result(b)
type(foo(n=*)), intent(in) :: a
type(foo(n=a%n)) :: b

b%vec(1)=a%vec(1)
  end function baz

end module bar

program test
  use bar
  implicit none
  call main

contains

  subroutine main
!type(foo(n)) :: x,y
type(foo) :: x!,y

x%vec=0
x=baz(x)! Segmentation fault
!x=baz(y)   ! THIS WORKS
  end subroutine main

end program test

% /usr/local/gfortran-bin/bin/gfortran test_case.f90 -o tc -Wall -Wextra -g -O0
-fdump-tree-all


% ./tc  

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f455c722aef in ???
#1  0x4008f2 in __bar_MOD_baz
at /home/alpha/src/fortran/24_Autoder_with_PDTs/test_case.f90:15
#2  0x4009ec in main
at /home/alpha/src/fortran/24_Autoder_with_PDTs/test_case.f90:32
zsh: segmentation fault  ./tc

Looking at some intermediate representation, it seems to me that x%vec
is deallocated just before calling the function baz(), probably because the
result will be assigned to x:

% cat test_case.f90.088t.fixup_cfg4

...

   :
  _2 = x.vec.data;
  if (_2 != 0B)
goto ; [INV]
  else
goto ; [INV]

   :
  _3 = x.vec.data;
  __builtin_free (_3);

   :
  x.vec.data = 0B;
  D.3841 = baz (); [return slot optimization]

...


% /usr/local/gfortran-bin/bin/gfortran --version
GNU Fortran (GCC) 8.0.0 20180109 (experimental) [trunk revision 256361]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug libstdc++/81584] Pretty Printer for string* doesn't work

[ghjghj530-bubu at yahoo dot de]

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

--- Comment #2 from ghjghj530-bubu at yahoo dot de ---
You are right. The original script from GCC 6.3.0 contains a check for new/old
string implementation in the "init" function.

This bugreport can be closed. Sorry for the inconvenience.

[Bug fortran/83762] New: ICE on variable declaration with undefined PDT parameter

[berke.durak at gmail dot com]

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

Bug ID: 83762
   Summary: ICE on variable declaration with undefined PDT
parameter
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: berke.durak at gmail dot com
  Target Milestone: ---

% cat test_case2.f90
module bar
  implicit none
  type :: foo(n)
 integer, len :: n=10
  end type foo
contains
  subroutine main
type(foo(undefined)) :: x
  end subroutine main
end module bar



% /usr/local/gfortran-bin/bin/gfortran test_case2.f90 -o tc -Wall -Wextra
test_case2.f90:11:0:

 end module bar

internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1116
0x6a0840 ???
../sysdeps/x86_64/elf/start.S:113
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.



% /usr/local/gfortran-bin/bin/gfortran --version 
GNU Fortran (GCC) 8.0.0 20180109 (experimental) [trunk revision 256361]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug target/83761] New: bfin: ICE: in require, at machmode.h:292

[sebastian.hu...@embedded-brains.de]

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

Bug ID: 83761
   Summary: bfin: ICE: in require, at machmode.h:292
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

make[4]: Entering directory
`/run/user/10351/b-gcc-bfin/bfin-rtems5/libgfortran'
/bin/sh ./libtool  --tag=CC   --mode=compile
/run/user/10351/b-gcc-bfin/./gcc/xgcc -B/run/user/10351/b-gcc-bfin/./gcc/
-nostdinc -B/run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/ -isystem
/run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/targ-include -isystem
/home/sh/src/gcc/newlib/libc/include -B/home/sh/install/bfin-rtems5/bin/
-B/home/sh/install/bfin-rtems5/lib/ -isystem
/home/sh/install/bfin-rtems5/include -isystem
/home/sh/install/bfin-rtems5/sys-include-DHAVE_CONFIG_H -I.
-I/home/sh/src/gcc/libgfortran  -iquote/home/sh/src/gcc/libgfortran/io
-I/home/sh/src/gcc/libgfortran/../gcc
-I/home/sh/src/gcc/libgfortran/../gcc/config  -I../.././gcc
-I/home/sh/src/gcc/libgfortran/../libgcc -I../libgcc
-I/home/sh/src/gcc/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace  -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla  -fcx-fortran-rules
-ffunction-sections -fdata-sections   -g -O2 -MT sum_c8.lo -MD -MP -MF
.deps/sum_c8.Tpo -c -o sum_c8.lo `test -f
'/home/sh/src/gcc/libgfortran/generated/sum_c8.c' || echo
'/home/sh/src/gcc/libgfortran/'`/home/sh/src/gcc/libgfortran/generated/sum_c8.c
libtool: compile:  /run/user/10351/b-gcc-bfin/./gcc/xgcc
-B/run/user/10351/b-gcc-bfin/./gcc/ -nostdinc
-B/run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/ -isystem
/run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/targ-include -isystem
/home/sh/src/gcc/newlib/libc/include -B/home/sh/install/bfin-rtems5/bin/
-B/home/sh/install/bfin-rtems5/lib/ -isystem
/home/sh/install/bfin-rtems5/include -isystem
/home/sh/install/bfin-rtems5/sys-include -DHAVE_CONFIG_H -I.
-I/home/sh/src/gcc/libgfortran -iquote/home/sh/src/gcc/libgfortran/io
-I/home/sh/src/gcc/libgfortran/../gcc
-I/home/sh/src/gcc/libgfortran/../gcc/config -I../.././gcc
-I/home/sh/src/gcc/libgfortran/../libgcc -I../libgcc
-I/home/sh/src/gcc/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT sum_c8.lo -MD -MP -MF
.deps/sum_c8.Tpo -c /home/sh/src/gcc/libgfortran/generated/sum_c8.c -o sum_c8.o
during RTL pass: reload
/home/sh/src/gcc/libgfortran/generated/sum_c8.c: In function 'sum_c8':
/home/sh/src/gcc/libgfortran/generated/sum_c8.c:191:1: internal compiler error:
in require, at machmode.h:292
 }
 ^
0x101e4f43 opt_mode::require() const
/home/sh/src/gcc/gcc/machmode.h:292
0x101e4f43 replace_reg_with_saved_mem
/home/sh/src/gcc/gcc/caller-save.c:1151
0x101e49a3 mark_referenced_regs
/home/sh/src/gcc/gcc/caller-save.c:1053
0x101e49f3 mark_referenced_regs
/home/sh/src/gcc/gcc/caller-save.c:1073
0x101e49f3 mark_referenced_regs
/home/sh/src/gcc/gcc/caller-save.c:1073
0x101e6e2f save_call_clobbered_regs()
/home/sh/src/gcc/gcc/caller-save.c:893
0x10771d27 reload(rtx_insn*, int)
/home/sh/src/gcc/gcc/reload1.c:981
0x1059e8bb do_reload
/home/sh/src/gcc/gcc/ira.c:5474
0x1059e8bb execute
/home/sh/src/gcc/gcc/ira.c:5646

[Bug middle-end/83729] [8 Regression] AVR ICE on convert_memory_address_addr_space_1 at explow.c:300

[gandalf at winds dot org]

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

--- Comment #3 from gandalf at winds dot org ---
Another regression test case (compile with -O):

void code_to_ascii(char buf[1], unsigned int code)
{
  __attribute__((used))
  static const char __flash test[5]="ABCDE";

  static const char __flash code_tab[32]="0123456789ABCDEFGHJKLMNPRSTUWXYZ";

  buf[0]=code_tab[code];
}

Variable "test" is correctly placed in section .progmem.data.

Variable "code_tab" is incorrectly placed in section .rodata.

This causes a problem for programs that are larger than 64KB in size. In my
case, "code_to_ascii" is one of the last functions in my .c file, and therefore
it is at the very end of the executable. Since "code_tab" appears next to
"code_to_ascii" after the 64KB boundary, __flash no longer references the
correct area in program memory.

GCC 7.2 correctly places both variables in .progmem.data.

[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from acsawdey at gcc dot gnu.org ---
At present trunk is vectorizing this in the vect pass not unrolling and
vectorizing in slp.

Code generated for mydata::Set is:

_ZN6mydata3SetEf:
.LFB4:
.cfi_startproc
xscvdpspn 1,1
li 9,16
xxspltw 0,1,0
stxvd2x 0,0,3
stxvd2x 0,3,9
blr

It seems like the test case should be looking for this alternative, I can't see
how a loop with a single stxvd2x that runs two iterations would be better.

[Bug fortran/83093] ICE in fold_convert_loc, at fold-const.c:2266

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
I have a patch that is currently being tested.

Note, z9.f90 is a user error that a compiler is
not required to diagnosis.  A user is required
to define a variable before it is used.

[Bug rtl-optimization/78585] unaligned vmovaps memory operand generated for i686 target

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 7.0.

[Bug rtl-optimization/78585] unaligned vmovaps memory operand generated for i686 target

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Jan  9 23:15:40 2018
New Revision: 256402

URL: https://gcc.gnu.org/viewcvs?rev=256402=gcc=rev
Log:
i386: Add a test for PR target/78585

PR target/78585 has been fixed for GCC 7 by

commit 7ed04d053eead43d87dff40fb4e2904219afc4d5
Author: jakub 
Date:   Wed Nov 30 13:02:07 2016 +

* config/i386/i386.c (dimode_scalar_chain::convert_op): Avoid
sharing the SUBREG rtx between move and following insn.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@243018
138bc75d-0d04-0410-961f-82ee72b054a4

PR target/78585:
* gcc.target/i386/pr78585.c: New test.

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

[Bug c/33167] Hex constant characters with \x escape not parsing correctly

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
"longest sequence of characters that can constitute the escape sequence" 
resolves an ambiguity between alternative parses permitted by the syntax; 
it doesn't need to deal with anything that is not permitted by the syntax.  
Four or more octal characters in an octal sequence are not a parse 
permitted by the syntax, whereas more than two hex characters in a hex 
sequence are a parse permitted by the syntax.

[Bug tree-optimization/83759] New test cases gcc.dg/torture/inf-compare-1.c (and -2, -3, and -4) in r256380 all fail on powerpc64

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Joseph S. Myers  ---
Feel free to XFAIL for powerpc with a comment referencing bug 58684 until that
bug is fixed (likewise gcc.dg/torture/pr52451.c).

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

[Bug target/58684] powerpc uses only unordered floating-point compares

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #2 from Joseph S. Myers  ---
*** Bug 83759 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/78585] unaligned vmovaps memory operand generated for i686 target

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
It is fixed by r243018.

[Bug c/33167] Hex constant characters with \x escape not parsing correctly

[albertmcchan at yahoo dot com]

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

--- Comment #6 from Albert Chan  ---
if gcc hex escape AND octal is right, does it contradict comment #1 ?

"octal or hexadecimal ... longest sequence that constitute escape sequence"

I noticed OLD python (2.0) also use the C rule regarding hex escapes,
but later switch to a more sensible 2 hex = 1 byte rule (\xX or \xXX)

[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Which is perfectly fine, except the error message is a bit confusing if you
don't know what's going on.

[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #2)
> The driver asks the kernel, and the kernel knows.  It's just a string.

Correct, the kernel passes a string to the driver and the driver blindly uses
it as its -mcpu= option, without first determining whether it recognizes (ie,
supports it) or not.

[Bug testsuite/83737] FAIL: gcc.dg/stdint-width-1.c (test for excess errors) for with newlib stdint.h

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
Most configurations (for which the libc used has a working stdint.h) 
should probably be using use_gcc_stdint=wrap, so that GCC's stdint.h 
includes libc's for hosted compilations but GCC's own for freestanding 
compilations.  *-*-elf configurations do, for example.  I'd advise adding 
that for nvptx.  This test deliberately uses -ffreestanding so that any 
configurations using GCC's stdint.h for freestanding compilations have no 
problems with system stdint.h lacking TS 18661-1 support.

[Bug testsuite/80946] [8 regression] test cases gfortran.dg/vect/vect-2.f90 and gfortran.dg/vect/vect-5.f90 fail starting with r247544

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
In trunk 256391 all three loops are vectorized with vsx unaligned instructions:

lfs 1,564(1)
bl logf
nop
lis 10,0x3
mr 9,30
ori 10,10,0xd090
mtctr 10
xscvdpspn 0,1
xxspltw 0,0,0
.p2align 4,,15
.L2:
stxvd2x 0,0,9
addi 9,9,16
bdnz .L2
lfs 1,560(1)
bl logf
nop
lis 10,0x3
mr 9,29
ori 10,10,0xd090
mtctr 10
xscvdpspn 0,1
xxspltw 0,0,0
.p2align 4,,15
.L3:
stxvd2x 0,0,9
addi 9,9,16
bdnz .L3
lis 10,0x3
li 9,0
ori 10,10,0xd090
mtctr 10
.p2align 5,,31
.L4:
lxvd2x 0,29,9
lxvd2x 12,30,9
xvaddsp 0,0,12
stxvd2x 0,31,9
addi 9,9,16
bdnz .L4

[Bug c/33167] Hex constant characters with \x escape not parsing correctly

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
The standard syntax production for octal-escape-sequence (C11 6.4.4.4#1) 
only allows one, two or three digits.

[Bug libstdc++/80276] pretty printer for std::unique_ptr<T[]> shows type as std::unique_ptr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for GCC 8.

[Bug target/83740] [8 Regression] ICE in maybe_legitimize_operand, at optabs.c:7140

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jb at gcc dot gnu.org

[Bug target/83740] [8 Regression] ICE in maybe_legitimize_operand, at optabs.c:7140

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-09
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
I certainly can't reproduce ICE in the middle-end/backend, but can reproduce
starting with r256284 following ICE:
internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159
0x8fb176 gfc_add_modify_loc(unsigned int, stmtblock_t*, tree_node*, tree_node*)
../../gcc/fortran/trans.c:158
0x8fb1e3 gfc_add_modify(stmtblock_t*, tree_node*, tree_node*)
../../gcc/fortran/trans.c:170
0x9067d9 gfc_trans_array_ctor_element
../../gcc/fortran/trans-array.c:1565
0x9071af gfc_trans_array_constructor_value
../../gcc/fortran/trans-array.c:1781
0x90917f trans_array_constructor
../../gcc/fortran/trans-array.c:2541
0x909b30 gfc_add_loop_ss_code
../../gcc/fortran/trans-array.c:2817
0x9107a1 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5109
0x991a08 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2657
0x901372 trans_code
../../gcc/fortran/trans.c:2028
0x9014db gfc_trans_code_cond(gfc_code*, tree_node*)
../../gcc/fortran/trans.c:2131
0x990030 build_dt
../../gcc/fortran/trans-io.c:2028
0x99010b gfc_trans_write(gfc_code*)
../../gcc/fortran/trans-io.c:2067
0x9012e8 trans_code
../../gcc/fortran/trans.c:2000

[Bug libstdc++/80276] pretty printer for std::unique_ptr<T[]> shows type as std::unique_ptr

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Jan  9 21:46:13 2018
New Revision: 256400

URL: https://gcc.gnu.org/viewcvs?rev=256400=gcc=rev
Log:
PR libstdc++/80276 fix pretty printers for array smart pointers

PR libstdc++/80276
* python/libstdcxx/v6/printers.py (SharedPointerPrinter)
(UniquePointerPrinter): Print correct template argument, not type of
the pointer.
(TemplateTypePrinter._recognizer.recognize): Handle failure to lookup
a type.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Test unique_ptr of
array type.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Test shared_ptr and
weak_ptr of array types.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx17.cc

[Bug c++/83739] [8 Regression] error: range-based 'for' expression of type 'auto' has incomplete type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Started with r251433.

[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00678.html

[Bug c++/83734] [8 Regression] ice in cxx_eval _statement_list, at cp/constexpr.c:3869

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug c++/83734] [8 Regression] ice in cxx_eval _statement_list, at cp/constexpr.c:3869

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan  9 21:21:03 2018
New Revision: 256397

URL: https://gcc.gnu.org/viewcvs?rev=256397=gcc=rev
Log:
PR c++/83734
* constexpr.c (cxx_eval_statement_list): Ignore DEBUG_BEGIN_STMTs
in STATEMENT_LIST.  Remove unneeded assert.

* g++.dg/cpp0x/pr83734.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr83734.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/83709] Inserting duplicates into an unordered associative containers causes the container to invalidate iterators

[fdumont at gcc dot gnu.org]

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

--- Comment #2 from François Dumont  ---
Author: fdumont
Date: Tue Jan  9 21:05:10 2018
New Revision: 256396

URL: https://gcc.gnu.org/viewcvs?rev=256396=gcc=rev
Log:
2018-01-09  François Dumont  

PR libstdc++/83709
* include/bits/hashtable_policy.h
(__distance_fwd(_Iterator, _Iterator, input_iterator_tag)): Return 1 if
__first != __last.
(_Insert_base::_M_insert_range(_Ite, _Ite, _NodeGetter, true_type)):
New.
(_Insert_base::_M_insert_range(_Ite, _Ite, _NodeGetter, false_type)):
Add false_type parameter.
(_Insert_base::insert): Adapt.
* include/bits/hashtable.h (_Hashtable::operator=(initializzr_list<>)):
Adapt.
(_Hashtable::_M_insert(_Arg&&, const _NodeGen&, true_type, size_t)):
 Add __n_elt parameter, defaulted to 1.
(_Hashtable::_M_insert_unique_node): Likewise. Use it to call rehash
policy _M_need_rehash.
(_Hashtable::_M_merge_unique): Pass target number of elements to add to
produce only 1 rehash if necessary.
* testsuite/23_containers/unordered_map/insert/83709.cc: New.
* testsuite/23_containers/unordered_set/insert/83709.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/insert/83709.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/insert/83709.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h
trunk/libstdc++-v3/include/bits/hashtable_policy.h

[Bug target/83660] ICE with vec_extract inside expression statement

[kelvin at gcc dot gnu.org]

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

--- Comment #4 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Tue Jan  9 20:50:30 2018
New Revision: 256394

URL: https://gcc.gnu.org/viewcvs?rev=256394=gcc=rev
Log:

Use this branch to reproduce and resolve PR 83660.


Added:
branches/ibm/pr83660/
  - copied from r256393, trunk/

[Bug target/83760] New: [8 Regression] [SH] ICE in maybe_record_trace_start building glibc tst-copy_file_range.c

[jsm28 at gcc dot gnu.org]

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

Bug ID: 83760
   Summary: [8 Regression] [SH] ICE in maybe_record_trace_start
building glibc tst-copy_file_range.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: law at gcc dot gnu.org
  Target Milestone: ---
Target: sh4eb-linux-gnu

Created attachment 43083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43083=edit
preprocessed source

Compile the attached test (from the glibc testsuite) with -g -O2 for
sh4eb-linux-gnu, GCC trunk.  I see an ICE:

during RTL pass: dwarf2
tst-copy_file_range.c: In function 'simple_file_copy':
tst-copy_file_range.c:246:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2344
0x79ad31 maybe_record_trace_start
/scratch/jmyers/glibc/many8/src/gcc/gcc/dwarf2cfi.c:2344
0x79b023 create_trace_edges
/scratch/jmyers/glibc/many8/src/gcc/gcc/dwarf2cfi.c:2440
0x79ec6a scan_trace
/scratch/jmyers/glibc/many8/src/gcc/gcc/dwarf2cfi.c:2653
0x79f8aa create_cfi_notes
/scratch/jmyers/glibc/many8/src/gcc/gcc/dwarf2cfi.c:2679
0x79f8aa execute_dwarf2_frame
/scratch/jmyers/glibc/many8/src/gcc/gcc/dwarf2cfi.c:3037
0x79f8aa execute
/scratch/jmyers/glibc/many8/src/gcc/gcc/dwarf2cfi.c:3525
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This only appeared recently in glibc testing (where the exact sources being
compiled would have varied over time), but if I fix the .i file used in
testing, my bisection says this appeared with r255387.  Which makes no real
sense, so I'm supposing that actually exposed a latent bug elsewhere.  It's
entirely possible the issue is really the same as bug 78459, bug 80863 or both
of them (both are SH bugs reporting ICEs in maybe_record_trace_start which
later mysteriously disappeared).

Note: according to the logs from my glibc bot the problem only appeared for
sh4eb-linux-gnu, not for little-endian or soft-float, which might also be an
indication of a latent bug being more or less randomly perturbed by other
variations.

[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction

[bergner at gcc dot gnu.org]

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

--- Comment #12 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #11)
> It is not valid:  (void *) - 32  does not point inside a (or just behind
> it).
> 
> Perhaps you can make it valid using uintptr_t.  Either way: should not ICE

I'm not THAT interested in fixing that! :-)  Invalid is fine with me.

[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #11 from Segher Boessenkool  ---
It is not valid:  (void *) - 32  does not point inside a (or just behind it).

Perhaps you can make it valid using uintptr_t.  Either way: should not ICE ;-)

[Bug target/83757] [8 regression] gcc.dg/pr82190.c fails starting with r256351

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
This is the test case for 82190, which was failing because my memcmp loop
changes to the same code inadvertently removed part of the fix for 82190. I've
restored the two lines in question and now the test case passes again.

Fixed in 256392.

[Bug libstdc++/83754] Segmentation fault in regex_search

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||timshen at gcc dot gnu.org

--- Comment #1 from Tim Shen  ---
This is actually the same as bug 61601. The crash is due to stack overflow,
because the implementation uses recursion.

If you set the stack limit to 100x higher (ulimit -s 819200 for me), it stops
crashing and have the somewhat expected quadratic behavior.

[Bug fortran/83742] [8 Regression] ICE in gfc_is_simply_contiguous, at fortran/expr.c:5323

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Fixed on truck.  Thanks for bug report.

[Bug c++/81933] [7/8 Regression] Invalid "constexpr call flows off the end of the function" error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug fortran/83742] [8 Regression] ICE in gfc_is_simply_contiguous, at fortran/expr.c:5323

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Jan  9 19:49:25 2018
New Revision: 256391

URL: https://gcc.gnu.org/viewcvs?rev=256391=gcc=rev
Log:
2018-01-09  Steven G. Kargl  

PR fortran/83742
* expr.c (gfc_is_simply_contiguous): Check for NULL pointer.

2018-01-09  Steven G. Kargl  

PR fortran/83742
* gfortran.dg/contiguous_6.f90: New test.

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

[Bug tree-optimization/83759] New: New test cases gcc.dg/torture/inf-compare-1.c (and -2, -3, and -4) all fail on powerpc64

[seurer at gcc dot gnu.org]

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

Bug ID: 83759
   Summary: New test cases gcc.dg/torture/inf-compare-1.c (and -2,
-3, and -4) all fail on powerpc64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Some of the new tests in this revision fail on powerpc64 both le and be:

FAIL: gcc.dg/torture/inf-compare-1.c   -O0  execution test
FAIL: gcc.dg/torture/inf-compare-1.c   -O1  execution test
FAIL: gcc.dg/torture/inf-compare-1.c   -O2  execution test
FAIL: gcc.dg/torture/inf-compare-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/torture/inf-compare-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/inf-compare-1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/inf-compare-1.c   -Os  execution test
FAIL: gcc.dg/torture/inf-compare-2.c   -O0  execution test
FAIL: gcc.dg/torture/inf-compare-2.c   -O1  execution test
FAIL: gcc.dg/torture/inf-compare-2.c   -O2  execution test
FAIL: gcc.dg/torture/inf-compare-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/torture/inf-compare-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/inf-compare-2.c   -O3 -g  execution test
FAIL: gcc.dg/torture/inf-compare-2.c   -Os  execution test
FAIL: gcc.dg/torture/inf-compare-3.c   -O0  execution test
FAIL: gcc.dg/torture/inf-compare-3.c   -O1  execution test
FAIL: gcc.dg/torture/inf-compare-3.c   -O2  execution test
FAIL: gcc.dg/torture/inf-compare-3.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/torture/inf-compare-3.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/inf-compare-3.c   -O3 -g  execution test
FAIL: gcc.dg/torture/inf-compare-3.c   -Os  execution test
FAIL: gcc.dg/torture/inf-compare-4.c   -O0  execution test
FAIL: gcc.dg/torture/inf-compare-4.c   -O1  execution test
FAIL: gcc.dg/torture/inf-compare-4.c   -O2  execution test
FAIL: gcc.dg/torture/inf-compare-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/torture/inf-compare-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/inf-compare-4.c   -O3 -g  execution test
FAIL: gcc.dg/torture/inf-compare-4.c   -Os  execution test

seurer@makalu-lp1:~/gcc/build/gcc-trunk$
/home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/torture/inf-compare-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -g -lm -o
./inf-compare-1.exe

seurer@makalu-lp1:~/gcc/build/gcc-trunk$ gdb ./inf-compare-1.exe 
(gdb) run
Program received signal SIGABRT, Aborted.
0x3fffb7cd129c in .raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-196.el7_4.2.ppc64
(gdb) where
#0  0x3fffb7cd129c in .raise () from /lib64/libc.so.6
#1  0x3fffb7cd34a8 in .abort () from /lib64/libc.so.6
#2  0x1570 in main () at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/torture/inf-compare-1.c:18

[Bug tree-optimization/83695] [8 Regression] ICE on valid code at -O3: Segmentation fault

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On January 9, 2018 6:39:39 PM GMT+01:00, "amker at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83695
>
>--- Comment #4 from amker at gcc dot gnu.org ---
>Given 3-level loop nest: , the ICE
>happens
>when estimate_numbers_of_iterations called for the outermost Loop_1. 
>The
>function tries to infer niter information from all stmts inside the
>loop.  In
>this case, the scev_info for variables defined in innermost loop is not
>updated
>in previous interchange.
>
>If I deliberately call estimate_numbers_of_iterations for all loops in
>nest
>before actual interchange, the ICE will be gone.  But I am not sure if
>this is
>the only case outdated scev info in inner loops is used.
>
>A full fix would be introducing additional interface cleaning up cached
>scev
>information for variables defined in LOOP from scalar_evolution_info. 
>And call
>the interface for interchanged loops.  Given interchange executed for
>only
>limited times, I guess that won't be too expensive?
>
>I am testing a patch following the latter method.

Just clear all of the cache? Or avoid doing analysis after transform...

[Bug middle-end/83758] New: ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

Bug ID: 83758
   Summary: ICE building gccgo on powerpc64le --with-cpu=power8
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: dje at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le power8

Attempting to bootstrap trunk 256388

../trunk/configure --enable-languages=all --with-cpu=power8

make fails with an ICE building some go stuff:

libtool: compile:  /home/sawdey/src/gcc/trunk/build/./gcc/gccgo
-B/home/sawdey/src/gcc/trunk/build/./gcc/
-B/home/sawdey/install/gcc/trunk_memcmp/powerpc64le-unknown-linux-gnu/bin/
-B/home/sawdey/install/gcc/tru
nk_memcmp/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/sawdey/install/gcc/trunk_memcmp/powerpc64le-unknown-linux-gnu/include
-isystem
/home/sawdey/install/gcc/trunk_memcmp/powerpc64le-unknown-linux-gnu/sys-
include -O2 -g -I . -c -fgo-pkgpath=crypto/x509
../../../trunk/libgo/go/crypto/x509/cert_pool.go
../../../trunk/libgo/go/crypto/x509/pem_decrypt.go
../../../trunk/libgo/go/crypto/x509/pkcs1.go ../../../trunk/lib
go/go/crypto/x509/pkcs8.go ../../../trunk/libgo/go/crypto/x509/root.go
../../../trunk/libgo/go/crypto/x509/root_linux.go
../../../trunk/libgo/go/crypto/x509/root_unix.go
../../../trunk/libgo/go/crypto/x509/sec1.
go ../../../trunk/libgo/go/crypto/x509/verify.go
../../../trunk/libgo/go/crypto/x509/x509.go -o crypto/x509.o >/dev/null 2>&1
during RTL pass: vartrack
../../../trunk/libgo/go/cmd/go/internal/work/gccgo.go: In function
‘work.gc.N35_cmd_go_internal_work.gccgoToolchain’:
../../../trunk/libgo/go/cmd/go/internal/work/gccgo.go:54:1: internal compiler
error: in vt_expand_var_loc_chain, at var-tracking.c:8331
 func (tools gccgoToolchain) gc(b *Builder, a *Action, archive string,
importcfg []byte, asmhdr bool, gofiles []string) (ofile string, output []byte,
err error) {
 ^
0x10d8e7db vt_expand_var_loc_chain
../../trunk/gcc/var-tracking.c:8331
0x10d8e7db vt_expand_loc_callback
../../trunk/gcc/var-tracking.c:8527
0x103e8c7f cselib_expand_value_rtx_1
../../trunk/gcc/cselib.c:1714
0x103e8a6b cselib_expand_value_rtx_1
../../trunk/gcc/cselib.c:1752
0x103e8a6b cselib_expand_value_rtx_1
../../trunk/gcc/cselib.c:1752
0x103ebdaf cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../trunk/gcc/cselib.c:1561
0x10d8dfc7 vt_expand_var_loc_chain
../../trunk/gcc/var-tracking.c:8364
0x10d8dfc7 vt_expand_loc_callback

[Bug libstdc++/59253] Python pretty printer should be improved for unique_ptr, shared_ptr and map

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Tue Jan  9 18:49:57 2018
New Revision: 256390

URL: https://gcc.gnu.org/viewcvs?rev=256390=gcc=rev
Log:
PR libstdc++/59253 Improve pretty printers for smart pointers

PR libstdc++/59253 (partial)
* python/libstdcxx/v6/printers.py (SmartPtrIterator): Common iterator
type for pointer stored by shared_ptr, weak_ptr and unique_ptr.
(SharedPointerPrinter, UniquePointerPrinter): Treat stored values as
children.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Update expected output
of unique_ptr printer.
* testsuite/libstdc++-prettyprinters/shared_ptr.cc: Update expected
output of shared_ptr printer.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc

[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
 Status|NEW |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-01/msg00656.ht
   ||ml
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #10 from Peter Bergner  ---
Patch submitted.  I'm also changing the keyword to ice-on-valid-code, since I
think the minimal test case in Comment 6 is valid, unlike the original test
case.

[Bug tree-optimization/83753] ICE: in exact_div, at poly-int.h:2139

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-09
 CC||rsandifo at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Created attachment 43082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43082=edit
Candidate patch

Looks like a latent bug.  Here's the patch I'm testing.

[Bug tree-optimization/83695] [8 Regression] ICE on valid code at -O3: Segmentation fault

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Given 3-level loop nest: , the ICE happens
when estimate_numbers_of_iterations called for the outermost Loop_1.  The
function tries to infer niter information from all stmts inside the loop.  In
this case, the scev_info for variables defined in innermost loop is not updated
in previous interchange.

If I deliberately call estimate_numbers_of_iterations for all loops in nest
before actual interchange, the ICE will be gone.  But I am not sure if this is
the only case outdated scev info in inner loops is used.

A full fix would be introducing additional interface cleaning up cached scev
information for variables defined in LOOP from scalar_evolution_info.  And call
the interface for interchanged loops.  Given interchange executed for only
limited times, I guess that won't be too expensive?

I am testing a patch following the latter method.

[Bug target/83757] New: [8 regression] gcc.dg/pr82190.c fails starting with r256351

[seurer at gcc dot gnu.org]

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

Bug ID: 83757
   Summary: [8 regression] gcc.dg/pr82190.c fails starting with
r256351
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Saw this only on powerpc64le and not on be.

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr82190.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fno-optimize-strlen
-fweb -lm -o ./pr82190.exe
PASS: gcc.dg/pr82190.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
spawn [open ...]
FAIL: gcc.dg/pr82190.c execution test

seurer@genoa:~/gcc/build/gcc-test2$ /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr82190.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -g
-fno-optimize-strlen -fweb -lm -o ./pr82190.exe
seurer@genoa:~/gcc/build/gcc-test2$ gdb ./pr82190.exe 

(gdb) run
Starting program: /home/seurer/gcc/build/gcc-test2/pr82190.exe 

Program received signal SIGABRT, Aborted.
0x3fffb7ccedb0 in __GI_raise (sig=) at
../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0  0x3fffb7ccedb0 in __GI_raise (sig=) at
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x3fffb7cd1270 in __GI_abort () at abort.c:89
#2  0x153c in main () at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr82190.c:13

[Bug c++/83756] gcc (mingw64) 7.2.0 ICE on boost::call_once

[jacobgodserv at gmail dot com]

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

--- Comment #5 from Jacob Godserv  ---
Created attachment 43081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43081=edit
mingw-w64 7.2.0 TestClass.ii

This is the intermediate output from a 7.2.0 run.

[Bug c++/83756] gcc (mingw64) 7.2.0 ICE on boost::call_once

[jacobgodserv at gmail dot com]

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

--- Comment #4 from Jacob Godserv  ---
Created attachment 43080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43080=edit
7.2.0 test case output

This is output from a 7.2.0 run. It produces the same crash.

[Bug preprocessor/83063] [8 Regression] ICE on an invalid preprocessor snippet

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #43070|0   |1
is obsolete||

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

Small progress.

[Bug c++/83756] gcc (mingw64) 7.2.0 ICE on boost::call_once

[jacobgodserv at gmail dot com]

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

--- Comment #3 from Jacob Godserv  ---
Created attachment 43078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43078=edit
mingw-w64 5.4.0 TestClass.ii

I've attached gcc's intermediate output to make this even easier to reproduce.

Compile it like so:
x86_64-5.4.0-release-win32-seh-rt_v5-rev0/mingw64/bin/g++ -std=c++11
TestClass.ii

[Bug c++/83756] gcc (mingw64) 7.2.0 ICE on boost::call_once

[jacobgodserv at gmail dot com]

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

--- Comment #2 from Jacob Godserv  ---
Created attachment 43077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43077=edit
Minimal test case

With:
x86_64-w64-mingw32-g++ -std=c++11 -I path/to/official/boost/1.57/includes/ -L
path/to/official/boost/1.57/64bit/libraries/ TestClass.cpp

I am able to reproduce the failure. See the attached file for the minimal test
case.

[Bug rtl-optimization/83628] [8 Regression] performance regression when accessing arrays on alpha

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jan  9 16:27:11 2018
New Revision: 256387

URL: https://gcc.gnu.org/viewcvs?rev=256387=gcc=rev
Log:
PR target/83628
* combine.c (force_int_to_mode) : Use mode instead of
op_mode in the force_to_mode call.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug c++/83756] gcc (mingw64) 7.2.0 ICE on boost::call_once

[jacobgodserv at gmail dot com]

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

--- Comment #1 from Jacob Godserv  ---
Obviously you need a way to reproduce this bug. The original comment does not
include that information. I'm going to attach a minimal test case, instructions
on how to run it, and the .ii to make it even easier.

[Bug c++/83756] New: gcc (mingw64) 7.2.0 ICE on boost::call_once

[jacobgodserv at gmail dot com]

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

Bug ID: 83756
   Summary: gcc (mingw64) 7.2.0 ICE on boost::call_once
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jacobgodserv at gmail dot com
  Target Milestone: ---

Created attachment 43076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43076=edit
Original sanitized output

- The exact version of GCC: x86_64-5.4.0-release-win32-seh-rt_v5-rev0. I was
able to reproduce also on 4.9.4 and 7.2.0 equivalents but I forgot to write the
exact versions. I tried to keep the toolchains as equal as possible except for
versions. I can get exact names if you guys need them. The maintainer of
mingw64 said they could also reproduce on 7.2.1, and said it's a vanilla gcc
bug which is why it's here.

- The system type: Windows 7 64-bit, Intel

- The options given when GCC was configured/built:
This is a mingw-w64-distributed build:

Configured with: ../../../src/gcc-5.4.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw540/x86_64-540-win32-seh-rt_v5-rev0/mingw64
--with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared
--enable-static --disable-multilib --enable-languages=c,c++,fortran,lto
--enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp
--enable-libatomic --enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-gnu-as --with-gnu-ld
--with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw540/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw540/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw540/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw540/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-win32-seh-rev0, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/c/mingw540/x86_64-540-win32-seh-rt_v5-rev0/mingw64/opt/include
-I/c/mingw540/prerequisites/x86_64-zlib-static/include
-I/c/mingw540/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -I/c/mingw540/x86_64-540-win32-seh-rt_v5-rev0/mingw64/opt/include
-I/c/mingw540/prerequisites/x86_64-zlib-static/include
-I/c/mingw540/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=
LDFLAGS='-pipe -L/c/mingw540/x86_64-540-win32-seh-rt_v5-rev0/mingw64/opt/lib
-L/c/mingw540/prerequisites/x86_64-zlib-static/lib
-L/c/mingw540/prerequisites/x86_64-w64-mingw32-static/lib '

- The complete command line that triggers the bug:
Really barely anything. I'm using gradle to build so it's nothing fancy:
-x c++ -c -DCLASSA_EXPORT -DCLASSB_IMPORT -std=c++11 -I 
-m64

the compiler output (error messages, warnings, etc.):
I've attached the original output.

[Bug libstdc++/80276] pretty printer for std::unique_ptr<T[]> shows type as std::unique_ptr

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> We can prevent this by always casting the stored pointer to void*
> 
> self.pointer = self.pointer.cast(gdb.lookup_type("void").pointer())

Oops, that was a comment for a different bug.

[Bug libstdc++/83755] Pretty printers treat char* as NTBS

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
We can prevent this by always casting the stored pointer to void*

self.pointer = self.pointer.cast(gdb.lookup_type("void").pointer())

[Bug libstdc++/80276] pretty printer for std::unique_ptr<T[]> shows type as std::unique_ptr

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
We can prevent this by always casting the stored pointer to void*

self.pointer = self.pointer.cast(gdb.lookup_type("void").pointer())

[Bug libstdc++/83755] Pretty printers treat char* as NTBS

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-09
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
In the original example the address really is a null-terminated string, but it
isn't always:

#include 
int main()
{
  char a[] = {'a', 'b', 'c', 'd'};
  std::unique_ptr p([0]);
  p.release();
}

This just prints garbage on the stack until it reaches a nul:

$1 = std::unique_ptr containing 0x7fffd38c "abcd \t@"

[Bug libstdc++/83755] New: Pretty printers treat char* as NTBS

[redi at gcc dot gnu.org]

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

Bug ID: 83755
   Summary: Pretty printers treat char* as NTBS
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
int main()
{
  char a[] = {"abcd";
  std::unique_ptr p([0]);
  p.release();
}

This prints:

$1 = std::unique_ptr containing 0x7fffd38b "abcd"

The stored pointer is not a NTBS, it's just a single char.

(Related to PR 59170)

[Bug target/83663] [8 regression] aarch64_be regressions after r255946

[vp at gcc dot gnu.org]

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

--- Comment #3 from Vidya Praveen  ---
regressed tests passing now after the patch revert.

[Bug libstdc++/83754] New: Segmentation fault in regex_search

[antoshkka at gmail dot com]

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

Bug ID: 83754
   Summary: Segmentation fault in regex_search
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

The following code 

#include 
#include 

int main() {
  std::regex pattern("\\w+\\.");
  std::string s(100, 'a');
  return std::regex_search(s, pattern);
}


leads to segmentation fault. Backtrace reports the following:

#1  0x004174a2 in std::_Function_handler, false, false>
>::_M_invoke(std::_Any_data const&, char&&) ()
#2  0x00415544 in std::function::operator()(char) const ()
#3  0x00411222 in std::__detail::_State::_M_matches(char) const
()
#4  0x0040cde3 in std::__detail::_Executor::_M_handle_match

#5  0x00409cb0 in std::__detail::_Executor::_M_dfs
#6  0x00411656 in std::__detail::_Executor::_M_rep_once_more
#7  0x0040ca05 in std::__detail::_Executor::_M_handle_repeat
<...>
#11350  0x00409cb0 in std::__detail::_Executor::_M_dfs
#11351  0x00411656 in std::__detail::_Executor::_M_rep_once_more
#11352  0x0040ca05 in std::__detail::_Executor::_M_handle_repeat
<...>


This issue could be related to the bug 79539

[Bug libstdc++/81584] Pretty Printer for string* doesn't work

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-09
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This should work, the python script was updated when the new string
implementation was committed.

The python code you've shown does not come from GCC 6.3.0, so you're not using
the right script.

[Bug libstdc++/80276] pretty printer for std::unique_ptr<T[]> shows type as std::unique_ptr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-09
 Ever confirmed|0   |1

[Bug tree-optimization/83753] New: ICE: in exact_div, at poly-int.h:2139

[vp at gcc dot gnu.org]

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

Bug ID: 83753
   Summary: ICE: in exact_div, at poly-int.h:2139
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vp at gcc dot gnu.org
  Target Milestone: ---

$ cat a.c
typedef struct {
  int m1[10];
  double m2[10][8];
} blah;

void
foo (blah *info) {
  int i, d;

  for (d=0; d<10; d++) {
info->m1[d] = 0;
info->m2[d][0] = 1;
for (i=1; i<8; i++)
  info->m2[d][i] = 2;
  }
}

$ /path/to/aarch64-unknown-linux-gnu-gcc -O3 -c -mcpu=xgene1 a.c
during GIMPLE pass: vect
a.c: In function ‘foo’:
a.c:7:1: internal compiler error: in exact_div, at poly-int.h:2139
 foo (blah *info) {
 ^~~
0xb17b4b poly_int<1u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
exact_div<1u, unsigned long, int>(poly_int_pod<1u, unsigned long> const&, int)
../../../gcc-fsf/gcc/poly-int.h:2139
0x1a1a5f7 vect_grouped_store_supported(tree_node*, unsigned long)
../../../gcc-fsf/gcc/tree-vect-data-refs.c:4676
0x13186c7 get_group_load_store_type
../../../gcc-fsf/gcc/tree-vect-stmts.c:1866
0x1318b3b get_load_store_type
../../../gcc-fsf/gcc/tree-vect-stmts.c:1999
0x1325e1b vectorizable_store
../../../gcc-fsf/gcc/tree-vect-stmts.c:5760
0x1330293 vect_analyze_stmt(gimple*, bool*, _slp_tree*, _slp_instance*)
../../../gcc-fsf/gcc/tree-vect-stmts.c:8686
0x133db0b vect_analyze_loop_operations
../../../gcc-fsf/gcc/tree-vect-loop.c:1771
0x133e6fb vect_analyze_loop_2
../../../gcc-fsf/gcc/tree-vect-loop.c:2062
0x133f647 vect_analyze_loop(loop*, _loop_vec_info*)
../../../gcc-fsf/gcc/tree-vect-loop.c:2376
0x136d69f vectorize_loops()
../../../gcc-fsf/gcc/tree-vectorizer.c:664
0x121217f execute
../../../gcc-fsf/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Seem to have caused by the commit r256216.

[Bug middle-end/83718] [8 Regression] ICE: Floating point exception in profile_count::apply_scale

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
Let me take a look.

[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov  ---
(In reply to Peter Bergner from comment #8)
> Created attachment 43064 [details]
> Proposed fix
> 
> I'm testing the attached patch.

Thank you, Peter.  I thought about resurrection of address mutations (e.g. AND)
in LRA.  But I would definitely prefer your approach as it is
machine-dependent, does not affect other targets, and less complicated than my
approach.

[Bug rtl-optimization/83575] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Once BB order is finalized we should not move them across partitions.

The problem seems to start with loop2_unroll which for some reason introduce
blocks of count 0 that looks like a misupdate of profile, this seems to trigger
some bug in bb-reorder with profile absent.

I will try to take a look.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #43074|0   |1
is obsolete||

--- Comment #54 from Richard Biener  ---
Created attachment 43075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43075=edit
Updated patch with SHT_GROUP and extended section index handling

More fixes accumulated.  Works for the large # input section testcase now. 
Also goes happily into stage2 with bootstrap-lto.

[Bug tree-optimization/83668] [8 Regression] wrong code with -O -fno-tree-dominator-opts -fgraphite-identity

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenther at suse dot de]

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

--- Comment #53 from rguenther at suse dot de  ---
On Tue, 9 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
> 
> --- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE  > Uni-Bielefeld.DE> ---
> [...]
> >> that should have been used as the reloc section for the new section 2.
> >> I see sh_info is still 9, it should be 2.  That's eventually
> >> missing handling in the section removal patch.
> >
> > I'll try to figure this out.
> 
> However, testing the patch on Linux produced weird results: during a
> regular make check run, many LTO tests FAIL like this:
> 
> *** Error in
> `/var/scratch/gcc/regression/trunk/4.10.10-gcc-gas-gld/build/gcc/testsuite/g++5/../../lto-wrapper':
> free(): invalid next size (normal): 0x0197a900 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x791fb)[0x7fe8b712c1fb]
> /lib64/libc.so.6(+0x8288a)[0x7fe8b713588a]
> /lib64/libc.so.6(cfree+0x4c)[0x7fe8b71392bc]
> /var/scratch/gcc/regression/trunk/4.10.10-gcc-gas-gld/build/gcc/testsuite/g++5/../../lto-wrapper[0x472b2e]
> /var/scratch/gcc/regression/trunk/4.10.10-gcc-gas-gld/build/gcc/testsuite/g++5/../../lto-wrapper[0x472c76]
> /var/scratch/gcc/regression/trunk/4.10.10-gcc-gas-gld/build/gcc/testsuite/g++5/../../lto-wrapper[0x40668d]
> /var/scratch/gcc/regression/trunk/4.10.10-gcc-gas-gld/build/gcc/testsuite/g++5/../../lto-wrapper[0x407245]
> /var/scratch/gcc/regression/trunk/4.10.10-gcc-gas-gld/build/gcc/testsuite/g++5/../../lto-wrapper[0x404ab6]
> /lib64/libc.so.6(__libc_start_main+0xf1)[0x7fe8b70d3401]
> /var/scratch/gcc/regression/trunk/4.10.10-gcc-gas-gld/build/gcc/testsuite/g++5/../../lto-wrapper[0x404bea]

I belive this is your new code in handle_lto_debug_sections which doesn't
NUL terminate the .rela in newname but then strcats on it.  
s/XNEWVEC/XCNEWVEC/ fixes that for me.

not yet fixed in the updated patch.  Btw, the following has been helful
a few times to me...

Index: lto-plugin.c
===
--- lto-plugin.c(revision 256378)
+++ lto-plugin.c(working copy)
@@ -551,7 +551,7 @@ exec_lto_wrapper (char *argv[])
   char *at_args;
   FILE *args;
   FILE *wrapper_output;
-  char *new_argv[3];
+  char *new_argv[4];
   struct pex_obj *pex;
   const char *errmsg;

@@ -583,9 +583,10 @@ exec_lto_wrapper (char *argv[])
}
 }

-  new_argv[0] = argv[0];
-  new_argv[1] = at_args;
-  new_argv[2] = NULL;
+  new_argv[0] = "/usr/bin/valgrind";//argv[0];
+  new_argv[1] = argv[0];//at_args;
+  new_argv[2] = at_args;//NULL;
+  new_argv[3] = NULL;

   if (debug)
 {
@@ -595,7 +596,7 @@ exec_lto_wrapper (char *argv[])
 }


-  pex = pex_init (PEX_USE_PIPES, "lto-wrapper", NULL);
+  pex = pex_init (PEX_USE_PIPES, "valgrind"/*"lto-wrapper"*/, NULL);
   check (pex != NULL, LDPL_FATAL, "could not pex_init lto-wrapper");

   errmsg = pex_run (pex, 0, new_argv[0], new_argv, NULL, NULL, );

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #43073|0   |1
is obsolete||

--- Comment #52 from Richard Biener  ---
Created attachment 43074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43074=edit
Updated patch with SHT_GROUP and extended section index handling

Fixed some goofs.  At least passes lto.exp now, LTO bootstrap running.

[Bug tree-optimization/83668] [8 Regression] wrong code with -O -fno-tree-dominator-opts -fgraphite-identity

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Jan  9 13:35:43 2018
New Revision: 256381

URL: https://gcc.gnu.org/viewcvs?rev=256381=gcc=rev
Log:
2018-01-09  Richard Biener  

PR tree-optimization/83668
* graphite.c (canonicalize_loop_closed_ssa): Add edge argument,
move prologue...
(canonicalize_loop_form): ... here, renamed from ...
(canonicalize_loop_closed_ssa_form): ... this and amended to
swap successor edges for loop exit blocks to make us use
the RPO order we need for initial schedule generation.

* gcc.dg/graphite/pr83668.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr83668.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/83706] [8 regression] gcc.dg/ipa/inline-2.c and gcc.dg/ipa/inline-3.c fail starting with r256279

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
Seen on arm and aarch64 too.

[Bug tree-optimization/64811] fold_inf_compare bogus for NaNs (given -ftrapping-math)

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #2 from Joseph S. Myers  ---
Fixed for GCC 8.

[Bug tree-optimization/64811] fold_inf_compare bogus for NaNs (given -ftrapping-math)

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  ---
Author: jsm28
Date: Tue Jan  9 13:25:38 2018
New Revision: 256380

URL: https://gcc.gnu.org/viewcvs?rev=256380=gcc=rev
Log:
Fix folding of Inf/NaN comparisons for -ftrapping-math (PR
tree-optimization/64811).

The folding of comparisons against Inf (to constants or comparisons
with the maximum finite value) has various cases where it introduces
or loses "invalid" exceptions for comparisons with NaNs.

Folding x > +Inf to 0 should not be about HONOR_SNANS - ordered
comparisons of both quiet and signaling NaNs should raise invalid.

x <= +Inf is not the same as x == x, because again that loses an
exception (equality comparisons don't raise exceptions except for
signaling NaNs).

x == +Inf is not the same as x > DBL_MAX, and a similar issue applies
with the x != +Inf case - that transformation causes a spurious
exception.

This patch fixes the conditionals on the folding to avoid such
introducing or losing exceptions.

Bootstrapped with no regressions on x86_64-pc-linux-gnu (where the
cases involving spurious exceptions wouldn't have failed anyway before
GCC 8 because of unordered comparisons wrongly always having formerly
been used by the back end).  Also tested for powerpc-linux-gnu
soft-float that this fixes many glibc math/ test failures that arose
in that configuration because this folding affected the IBM long
double support in libgcc (no such failures appeared for hard-float
because of the bug of powerpc hard-float always using unordered
comparisons) - some failures remain, but I believe them to be
unrelated.

PR tree-optimization/64811
gcc:
* match.pd: When optimizing comparisons with Inf, avoid
introducing or losing exceptions from comparisons with NaN.

gcc/testsuite:
* gcc.dg/torture/inf-compare-1.c, gcc.dg/torture/inf-compare-2.c,
gcc.dg/torture/inf-compare-3.c, gcc.dg/torture/inf-compare-4.c,
gcc.dg/torture/inf-compare-5.c, gcc.dg/torture/inf-compare-6.c,
gcc.dg/torture/inf-compare-7.c, gcc.dg/torture/inf-compare-8.c:
New tests.
* gcc.c-torture/execute/ieee/fp-cmp-7.x: New file.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/ieee/fp-cmp-7.x
trunk/gcc/testsuite/gcc.dg/torture/inf-compare-1.c
trunk/gcc/testsuite/gcc.dg/torture/inf-compare-2.c
trunk/gcc/testsuite/gcc.dg/torture/inf-compare-3.c
trunk/gcc/testsuite/gcc.dg/torture/inf-compare-4.c
trunk/gcc/testsuite/gcc.dg/torture/inf-compare-5.c
trunk/gcc/testsuite/gcc.dg/torture/inf-compare-6.c
trunk/gcc/testsuite/gcc.dg/torture/inf-compare-7.c
trunk/gcc/testsuite/gcc.dg/torture/inf-compare-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenth at gcc dot gnu.org]

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

--- Comment #51 from Richard Biener  ---
Created attachment 43073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43073=edit
Updated patch with SHT_GROUP and extended section index handling

Tested on the big testcase, otherwise untested.  I belive that the large index
works unpatched is a co-incidence, so we need to fix that anyway.  Simplified
by assuming the extended index will not be needed after section
purging/remapping.

Added SHT_GROUP remapping support as well.

Will now throw this on LTO bootstrap...

[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
I am testing this patch:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8696f931806..8558995e067 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -11259,7 +11259,8 @@ ix86_compute_frame_layout (void)
   /* Calculate the size of the va-arg area (not including padding, if any). 
*/
   frame->va_arg_size = ix86_varargs_gpr_size + ix86_varargs_fpr_size;

-  if (stack_realign_fp)
+  /* Adjust stack_realign_offset for stack_alignment_needed.  */
+  if ((offset % stack_alignment_needed) != 0)
 {
   /* We may need a 16-byte aligned stack for the remainder of the
register save area, but the stack frame for the local function

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap after r254379

[marxin at gcc dot gnu.org]

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

--- Comment #30 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #29)
> Does the patch fix or make latent PR83575 ?

Unfortunately it doesn't. I'll try to take a look at the PR83575.

[Bug target/82214] [AArch64] Incorrect checking of LDP/STP offsets in aarch64_print_operand

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #1 from Wilco  ---
Note r255230 introduces 'y' and 'z' operand printing specifiers to solve this
issue, however they are not yet enabled on all LDP/STP instructions.

[Bug testsuite/83752] New: gfortran.dg/common_align_2.f90 fails in execution for target with __BIGGEST_ALIGNMENT__ < 8

[vries at gcc dot gnu.org]

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

Bug ID: 83752
   Summary: gfortran.dg/common_align_2.f90 fails in execution for
target with __BIGGEST_ALIGNMENT__ < 8
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

The test contains a list of common vars:
...
  real(8) x, y
  common i, x, j, y ! { dg-warning "Padding" }  
...

and assumes a byte layout:
...
i:  0-3
x:  8-15
j: 16-19
y: 24-31
...
based on 8-byte alignment for the real(8).

On targets with BIGGEST_ALIGNMENT == 32 (so __BIGGEST_ALIGNMENT__ == 4), we
have instead:
...
i:  0-3
x:  4-11
j: 12-15
y: 16-23
...

So this minimal version:
...
subroutine foo ()
  common i(8)
  if ((i(5) .ne. 43)) call abort
end subroutine

  real(8) x, y
  common i, x, j, y
  j = 43
  call foo ()
end
...
tests i(5), which is at offset ((5 - 1) * 4) == 16, where it expects to find j,
but instead finds y.

This test needs a:
...
! { dg-require-biggest-alignment ">=" "8" }
...
or some such.

Just adding -cpp and conditionalizing on __BIGGEST_ALIGNMENT__ will work for
the execution failure, but not for the missing padding warning.

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap after r254379

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #29 from Jakub Jelinek  ---
Does the patch fix or make latent PR83575 ?

[Bug ipa/83178] [8 regression] g++.dg/ipa/devirt-22.C fail

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
Difference is that a new specialized clone is created with the revision:

--- /tmp/before/devirt-22.C.075i.cp 2018-01-09 13:30:36.973652893 +0100
+++ /tmp/after/devirt-22.C.075i.cp  2018-01-09 13:30:07.333100054 +0100
@@ -114,12 +114,12 @@
   Node: void lookupSourceDone()/8:
   Node: void sort(C&, C&)/7:
 param [0]: VARIABLE
- ctxs: Outer type:struct C offset 0 [loc_time: 0, loc_size: 0,
prop_time: 0, prop_size: 0]
+ ctxs: Outer type:struct C offset 0 [loc_time: 0, loc_size: 0,
prop_time: 32, prop_size: 13]
  Bits: value = 0x0, mask = 0xfff8
  ~[0, 0]
 ref offset 0: [(void *)&_ZTV1C + 16B] [loc_time: 0, loc_size: 0,
prop_time: 0, prop_size: 0]
-param [1]:  [loc_time: 0, loc_size: 0, prop_time: 0, prop_size: 0]
- ctxs: Outer type:struct C offset 0 [loc_time: 0, loc_size: 0,
prop_time: 0, prop_size: 0]
+param [1]:  [loc_time: 0, loc_size: 0, prop_time: 70, prop_size: 32]
+ ctxs: Outer type:struct C offset 0 [loc_time: 0, loc_size: 0,
prop_time: 64, prop_size: 26]
  Bits: value = 0x0, mask = 0xfff8
  ~[0, 0]
 AGGS VARIABLE
@@ -156,6 +156,10 @@
 replacing param #1 p1 with const 0
 ipa-prop: Discovered a virtual call to a known target (operator[].constprop/21
-> virtual int C::m_fn1()/0), for stmt OBJ_TYPE_REF(_2;this_4(D)->0)
(this_4(D));
 Speculative call turned into direct call.
+  Creating a specialized node of A& C::operator[](int)/1.
+replacing param #1 p1 with const 0
+ipa-prop: Discovered a virtual call to a known target (operator[].constprop/22
-> virtual int C::m_fn1()/0), for stmt OBJ_TYPE_REF(_2;this_4(D)->0)
(this_4(D));
+Speculative call turned into direct call.
   Creating a specialized node of virtual int C::m_fn1()/0.
 replacing param #0 this with const 
  - Creating a specialized node of virtual int C::m_fn1()/0 for all known
contexts.

Martin can you please take a look and adjust expected scan output?

[Bug ipa/83178] [8 regression] g++.dg/ipa/devirt-22.C fail

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Created attachment 43072
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43072=edit
IPA CP dump file after the revision

[Bug ipa/83178] [8 regression] g++.dg/ipa/devirt-22.C fail

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Created attachment 43071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43071=edit
IPA CP dump file before the revision

[Bug preprocessor/83063] [8 Regression] ICE on an invalid preprocessor snippet

[jakub at gcc dot gnu.org]

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

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

WIP patch.  It still doesn't handle #__VA_OPT__(whatever) or #__VA_OPT__()
properly and there seems to be other issues.

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap after r254379

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap after r254379

[marxin at gcc dot gnu.org]

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

--- Comment #28 from Martin Liška  ---
I've just sent patch to gcc-patches:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00604.html

[Bug c++/83749] Types with different language linkage are treated as equivalent types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
It's a duplicate of PR 2316.

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

[Bug c++/2316] g++ fails to overload on language linkage

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dan.cermak@cgc-instruments.
   ||com

--- Comment #54 from Jonathan Wakely  ---
*** Bug 83749 has been marked as a duplicate of this bug. ***

[Bug sanitizer/82517] use-after-scope for a variable with big alignment causes a false positive

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail|8.0 |

--- Comment #6 from Martin Liška  ---
Fixed on trunk so far.

[Bug c++/83749] Types with different language linkage are treated as equivalent types

[dan.cer...@cgc-instruments.com]

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

--- Comment #2 from dan.cer...@cgc-instruments.com ---
Well I don't mind the current behavior at all and to be honest I find it more
logical that way, so I would welcome a change in the standard.

Should I then close this bugreport or keep it open for further reference?

[Bug sanitizer/82517] use-after-scope for a variable with big alignment causes a false positive

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Tue Jan  9 11:47:26 2018
New Revision: 256378

URL: https://gcc.gnu.org/viewcvs?rev=256378=gcc=rev
Log:
Add gcc_assert about stack alignment (PR sanitizer/82517).

2018-01-09  Martin Liska  

PR sanitizer/82517
* asan.c (shadow_mem_size): Add gcc_assert.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from ktkachov at gcc dot gnu.org ---
Fixed on all supported branches.

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

[ktkachov at gcc dot gnu.org]

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Jan  9 11:38:04 2018
New Revision: 256377

URL: https://gcc.gnu.org/viewcvs?rev=256377=gcc=rev
Log:
[arm] PR target/82975: Guard against reg_renumber being NULL in arm.h

Backport from mainline
2017-12-19  Kyrylo Tkachov  

PR target/82975
* config/arm/arm.h (TEST_REGNO): Check reg_renumber is set before
accessing it.  Adjust comment.

* gcc.dg/pr82975.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr82975.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/arm/arm.h
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"

[gjl at gcc dot gnu.org]

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

--- Comment #18 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Jan  9 11:27:34 2018
New Revision: 256376

URL: https://gcc.gnu.org/viewcvs?rev=256376=gcc=rev
Log:
PR target/79883
* gcc.target/avr/torture/pr57631.c (dg-warning): Quote 'signal'.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/avr/torture/pr57631.c

[Bug tree-optimization/83750] CSE erf/erfc pair

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-09
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
In the past we've done canonicalization instead, so I'd "fold" erfc (x) to 1.0
- erf (x) and then at a later stage when ! canonicalize_math_p () replace
1.0 - erf (x) with erfc (x) again.

Thus, add two patterns to match.pd to achieve this.

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[tnfchris at gcc dot gnu.org]

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

--- Comment #13 from Tamar Christina  ---
Author: tnfchris
Date: Tue Jan  9 11:04:50 2018
New Revision: 256375

URL: https://gcc.gnu.org/viewcvs?rev=256375=gcc=rev
Log:
2018-01-09  Tamar Christina    

PR target/82641
* gcc.target/arm/pragma_fpu_attribute.c: Rewrite to use
no NEON and require softfp or hard float-abi.
* gcc.target/arm/pragma_fpu_attribute_2.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/pragma_fpu_attribute.c
trunk/gcc/testsuite/gcc.target/arm/pragma_fpu_attribute_2.c

[Bug testsuite/83737] FAIL: gcc.dg/stdint-width-1.c (test for excess errors) for with newlib stdint.h

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
(In reply to Georg-Johann Lay from comment #2)
> Author: gjl
> Date: Tue Jan  9 10:38:45 2018
> New Revision: 256373

Typo in the ChangeLog :-( This was intended for PR83738