[Bug fortran/68078] segfault with allocate and stat for derived types with default initialization

2016-09-17 Thread lkrupp at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68078

--- Comment #3 from lkrupp at gcc dot gnu.org ---
Author: lkrupp
Date: Sun Sep 18 05:52:23 2016
New Revision: 240219

URL: https://gcc.gnu.org/viewcvs?rev=240219=gcc=rev
Log:
2016-09-17  Louis Krupp  

PR fortran/68078
* gfortran.dg/pr68078.f90: New test.
* gfortran.dg/set_vm_limit.c: New, called by pr68078.

2016_09_17  Louis Krupp  

PR fortran/68078
* resolve.c (resolve_allocate_expr): Check that derived type
pointer, object or array has been successfully allocated before
initializing.


Added:
trunk/gcc/testsuite/gfortran.dg/pr68078.f90
trunk/gcc/testsuite/gfortran.dg/set_vm_limit.c
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/66675] Could improve vector lane folding style operations.

2016-09-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66675

Andrew Pinski  changed:

   What|Removed |Added

 Target|aarch64*-*-*, arm*-*-*  |

--- Comment #5 from Andrew Pinski  ---
maybe SRA can handle this.  Right now SRA does not handle vectors (but it does
handle complex).  So if it handled vectors as an array it might be able to
handle this case too.

[Bug middle-end/63273] atomic operations lead to inefficient code

2016-09-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug tree-optimization/63271] Should commute arithmetic with vector load

2016-09-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63271

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug gcov-profile/77630] lcov fails to write files when relative paths are used but works with absolute paths

2016-09-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77630

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Lcov is not part of gcc. Please report it to them direcrly.

[Bug gcov-profile/77630] New: lcov fails to write files when relative paths are used but works with absolute paths

2016-09-17 Thread philipp.classen at gmx dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77630

Bug ID: 77630
   Summary: lcov fails to write files when relative paths are used
but works with absolute paths
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philipp.classen at gmx dot net
  Target Milestone: ---

I run into a problem with lcov 1.12. It fails when writing files when the
output file is a relative path but works when instead an absolute path is used,
for instance:

lcov -d /home/phil/ghost -a test_fast_cxxtest_gcov__base.info -a
test_fast_cxxtest_gcov__test.info   -o test_fast_cxxtest_gcov__total.info
Combining tracefiles.
Reading tracefile test_fast_cxxtest_gcov__base.info
Reading tracefile test_fast_cxxtest_gcov__test.info
lcov: WARNING: function data mismatch at /home/phil/ghost/constants.h:1862
Writing data to test_fast_cxxtest_gcov__total.info
lcov: ERROR: cannot write to test_fast_cxxtest_gcov__total.info!

Running the command with strace reveals that it changes the directory to '/'.
Not sure why but it, at least, explains why it fails to write the file. Here is
part of the strace output:

brk(0x32c8000)  = 0x32c8000
read(4, "2Ev\nFN:202,_ZN6Output8AutoLockD2"..., 8192) = 8192
read(4, "cxx1112basic_stringIcSt11char_tr"..., 8192) = 8192
read(4, "DA:1865,0\nDA:1866,0\nDA:1877,0\nDA"..., 8192) = 8192
read(4, ",_ZNK9__gnu_cxx17__normal_iterat"..., 8192) = 8192
read(4, "goryISt13move_iteratorIN9__gnu_c"..., 8192) = 8192
read(4, ":118,0\nDA:121,0\nDA:122,0\nDA:127,"..., 8192) = 8192
read(4, "\nDA:993,5\nDA:994,5\nDA:995,5\nDA:9"..., 8192) = 8192
read(4, "r_traitsIcESaIcNSt9enable_if"..., 8192) = 8192
read(4, ",0\nDA:81,0\nDA:83,0\nDA:84,0\nDA:85"..., 8192) = 8192
read(4, "gnu_cxx17__normal_iteratorIPNSt7"..., 8192) = 8192
read(4, "DA:138,0\nDA:139,0\nLF:5\nLH:0\nend_"..., 8192) = 8192
read(4, "9_M_range_initializeISt13move_it"..., 8192) = 8192
read(4, "000,_Z22Build_R0_Occupied_ByteiR"..., 8192) = 8192
read(4, "DA:527,5\nDA:528,5\nDA:529,5\nDA:53"..., 8192) = 8192
read(4, "EEC2Ev\nFNDA:0,_ZNSaINSt7__cxx111"..., 8192) = 8192
read(4, "ZSt27__unguarded_partition_pivot"..., 8192) = 8192
read(4, "49,0\nDA:577,0\nDA:582,0\nDA:590,0\n"..., 8192) = 8192
read(4, "K9__gnu_cxx17__normal_iteratorIP"..., 8192) = 8192
read(4, "N:167,_ZNSt12_Vector_baseINSt7__"..., 8192) = 8192
read(4, "2basic_stringIcSt11char_traitsIc"..., 8192) = 8192
read(4, "iantEv\nFNDA:13395,_ZN10GhostUtil"..., 8192) = 1903
read(4, "", 8192)   = 0
close(4)= 0
brk(0x32e9000)  = 0x32e9000
brk(0x330a000)  = 0x330a000
brk(0x332b000)  = 0x332b000
chdir("/")  = 0
write(2, "lcov: WARNING: function data mis"..., 75lcov: WARNING: function data
mismatch at /home/phil/ghost/constants.h:1862
) = 75
brk(0x334c000)  = 0x334c000
brk(0x336d000)  = 0x336d000
brk(0x338e000)  = 0x338e000
brk(0x33af000)  = 0x33af000
brk(0x33d)  = 0x33d
brk(0x33f1000)  = 0x33f1000
brk(0x3412000)  = 0x3412000
brk(0x3433000)  = 0x3433000
brk(0x3454000)  = 0x3454000
brk(0x3475000)  = 0x3475000
brk(0x3496000)  = 0x3496000
brk(0x34b7000)  = 0x34b7000
brk(0x34d8000)  = 0x34d8000
brk(0x34f9000)  = 0x34f9000
brk(0x351a000)  = 0x351a000
brk(0x353c000)  = 0x353c000
brk(0x356)  = 0x356
brk(0x3584000)  = 0x3584000
brk(0x35a5000)  = 0x35a5000
brk(0x35c6000)  = 0x35c6000
brk(0x35e7000)  = 0x35e7000
brk(0x3608000)  = 0x3608000
brk(0x3629000)  = 0x3629000
brk(0x364a000)  = 0x364a000
brk(0x366b000)  = 0x366b000
brk(0x368c000)  = 0x368c000
brk(0x36ad000)  = 0x36ad000
brk(0x36ce000)  = 0x36ce000
brk(0x36ef000)  = 0x36ef000
brk(0x3711000)  = 0x3711000
brk(0x3732000)  = 0x3732000
brk(0x3753000)  = 0x3753000
brk(0x3774000)  = 0x3774000
brk(0x3795000)  = 0x3795000
brk(0x37b6000)  = 0x37b6000
brk(0x37d7000)  = 0x37d7000
brk(0x37f8000)  = 0x37f8000

[Bug c++/77629] New: internal compiler error: same canonical type node for different types

2016-09-17 Thread wen...@mitsuba-renderer.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77629

Bug ID: 77629
   Summary: internal compiler error: same canonical type node for
different types
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wen...@mitsuba-renderer.org
  Target Milestone: ---

Created attachment 39640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39640=edit
Preprocessed source code

I am running into the following internal compiler error with GCC TRUNK. The
preprocessed file is attached.

$ /usr/local/bin/gcc7 out.cpp

In file included from include/simdarray/array.h:58:0,
 from tests/testsuite.cpp:21:
include/simdarray/array_recursive.h:124:93: internal compiler error: same
canonical type node for different types simd::ArrayBase::peel != -1),
void>::type>::Base and simd::ArrayOperations
 SIMD_INLINE ArrayBase(Scalar value) : a1(value), a2(value) { }
   
 ^
0x781d74 comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:1437
0x6bcd01 resolve_typename_type(tree_node*, bool)
../../gcc/cp/pt.c:23721
0x7802ec structural_comptypes
../../gcc/cp/typeck.c:1204
0x7848ad comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:1409
0x7848ad compparms(tree_node const*, tree_node const*)
../../gcc/cp/typeck.c:1539
0x703b5c add_method(tree_node*, tree_node*, tree_node*)
../../gcc/cp/class.c:1155
0x7d0c64 finish_member_declaration(tree_node*)
../../gcc/cp/semantics.c:2997
0x76d3d8 cp_parser_member_declaration
../../gcc/cp/parser.c:22770
0x747b7a cp_parser_member_specification_opt
../../gcc/cp/parser.c:22331
0x747b7a cp_parser_class_specifier_1
../../gcc/cp/parser.c:21496
0x74a069 cp_parser_class_specifier
../../gcc/cp/parser.c:21745
0x74a069 cp_parser_type_specifier
../../gcc/cp/parser.c:15971
0x75da97 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:12889
0x76b965 cp_parser_single_declaration
../../gcc/cp/parser.c:25975
0x76bd0c cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:25667
0x76c68c cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:25902
0x76c68c cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:25920
0x7735a9 cp_parser_declaration
../../gcc/cp/parser.c:12209
0x771d7b cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12139
0x7724b2 cp_parser_namespace_body
../../gcc/cp/parser.c:17763
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

2016-09-17 Thread egall at gwmail dot gwu.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009

--- Comment #8 from Eric Gallager  ---
I reduced the command line required to trigger the ICE. It depends on whether
-fmath-errno is set or not. With:

$ /usr/local/bin/gcc -c -Ofast -I. -I../include -DHAVE_CONFIG_H -I../bfd
-Imacosx -Iconfig -Wno-deprecated-declarations -fno-math-errno valarith.c

...it ICEs as it did previously, but with:

$ /usr/local/bin/gcc -c -Ofast -I. -I../include -DHAVE_CONFIG_H -I../bfd
-Imacosx -Iconfig -Wno-deprecated-declarations -fmath-errno valarith.c

...it compiles successfully. That could explain why it wouldn't reproduce on
x86_64-linux-gnu, as I believe the default for -fmath-errno is different
between Darwin and GNU/Linux.

[Bug target/77628] New: avx512: unnecessary GR extending after kmovw

2016-09-17 Thread wojciech.mula at microgen dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77628

Bug ID: 77628
   Summary: avx512: unnecessary GR extending after kmovw
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wojciech.mula at microgen dot com
  Target Milestone: ---

According to the latests documentation from Intel, the kmovw instruction
zeros the higher part of a GP register:

KMOVW
IF *destination is a memory location*
DEST[15:0] <- SRC[15:0]
IF *destination is a mask register or a GPR *
DEST <- ZeroExtension(SRC[15:0])

GCC adds superfluous movzwl after kmovw:

Program:

#include 
#include 

uint32_t test(__m512i a, __m512i b) {

uint32_t c = _mm512_cmpeq_epi32_mask(a, b);
return c;
}

Invocation:

$ gcc-5 --version
gcc-5 (Debian 5.3.1-13) 5.3.1 20160323
$ gcc-5 -O3 -S -mavx512f report.cpp

Assembly output:

vpcmpeqd%zmm1, %zmm0, %k1
kmovw   %k1, %eax
movzwl  %ax, %eax  HERE
ret

[Bug tree-optimization/77627] Unexpected void * dereference in uninit warning (and missed out-of-bounds warning)

2016-09-17 Thread fw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77627

--- Comment #1 from Florian Weimer  ---
Observed with the trunk from 2016-09-08.

[Bug tree-optimization/77627] New: Unexpected void * dereference in uninit warning (and missed out-of-bounds warning)

2016-09-17 Thread fw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77627

Bug ID: 77627
   Summary: Unexpected void * dereference in uninit warning (and
missed out-of-bounds warning)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

This snippet, derived from code provided by Ron Garret:

int main(int argc, char* argv[]) {
  int x[100] = {0};
  int y = x[101];
  int z = *(x+102);
  return y+z;
}

results in the following warning:

t.c: In function ‘main’:
t.c:3:12: warning: array subscript is above array bounds [-Warray-bounds]
   int y = x[101];
   ~^
t.c:4:7: warning: ‘*((void *)+408)’ is used uninitialized in this function
[-Wuninitialized]
   int z = *(x+102);
   ^

The expression *((void *)+408) looks rather out of place. C programmers do
not expect that void * pointers can be dereferenced in this way.

GCC clearly realizes that the subscript is out of bounds, so perhaps it would
be possible to issue an out-of-bounds warning for this case, too.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

2016-09-17 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767

--- Comment #15 from Dominique d'Humieres  ---
Created attachment 39639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39639=edit
assembly for g++.old-deja/g++.pt/static11.C with Xcode 8 + patch and -m32

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

2016-09-17 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767

--- Comment #14 from Dominique d'Humieres  ---
Created attachment 39638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39638=edit
exhaustive results for libstdc++ with Xcode 8 + patch

Silenced with

+# Ignore harmless warnings from Xcode 8.0.
+regsub -all "(^|\n)ld: warning: direct access in function\[^\n\]* means
the weak symbol cannot be overridden\[^\n\]*" $text "" text

in libstdc++-v3/testsuite/lib/prune.exp.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

2016-09-17 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767

--- Comment #13 from Dominique d'Humieres  ---
Test failures with the patch in comment 4

FAIL: g++.old-deja/g++.pt/static11.C  -std=c++11 (test for excess errors)
FAIL: g++.old-deja/g++.pt/static11.C  -std=c++14 (test for excess errors)
FAIL: g++.old-deja/g++.pt/static11.C  -std=c++98 (test for excess errors)

-m32 only

FAIL: obj-c++.dg/qual-types-1.mm -fgnu-runtime (test for excess errors)

for both -m32 and -m64

FAIL: libgomp.c++/taskloop-6.C (test for excess errors)

-m32 only

=== libstdc++ tests ===


Running target unix/-m32
FAIL: 20_util/scoped_allocator/1.cc (test for excess errors)
FAIL: 20_util/scoped_allocator/2.cc (test for excess errors)
FAIL: 21_strings/basic_string/allocator/char/copy.cc (test for excess errors)
...
FAIL: tr1/6_containers/unordered_set/swap/1.cc (test for excess errors)
FAIL: tr1/6_containers/unordered_set/swap/2.cc (test for excess errors)

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

# of expected passes9965
# of unexpected failures426
# of expected failures  65
# of unsupported tests  663

Running target unix/-m64

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

# of expected passes10389
# of expected failures  65
# of unsupported tests  664

=== libstdc++ Summary ===

# of expected passes20354
# of unexpected failures426
# of expected failures  130
# of unsupported tests  1327

The failures are of the kind

[Book15] f90/bug% /opt/gcc/gcc7w/bin/g++
/opt/gcc/_clean/gcc/testsuite/g++.old-deja/g++.pt/static11.C -std=c++98 -m32
ld: warning: direct access in function
'__static_initialization_and_destruction_0(int, int)' from file
'/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccPdDjOW.o' to global weak
symbol 'guard variable for C::a' from file
'/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccPdDjOW.o' means the weak
symbol cannot be overridden at runtime. This was likely caused by different
translation units being compiled with different visibility settings.

[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary

2016-09-17 Thread n8tm at aol dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593

--- Comment #7 from n8tm at aol dot com ---
The bootstrap was working for me on Windows 8.1 the last few days although it
had been broken for a month or 2.  The symptom was that file edits made during
build were being dropped or the files from various stages were mixed (although
ok after build stopped).  Not the same as this corrupt f951.
I am away from my win10 and linux machines and have insufficient internet
access but I think I ruled out any difference between the Linux and cygwin svn
drops.  
By the way I haven't seen any internet installer vans this trip.

Sent via the ASUS PadFone X mini, an AT 4G LTE smartphone

 Original Message 
From:"jvdelisle at gcc dot gnu.org" 
Sent:Fri, 16 Sep 2016 16:41:45 -0400
To:tpri...@computer.org
Subject:[Bug bootstrap/77593] [7 Regression] Bootstrap failure with
configure-target-libgfortran " cygwin64 Windows 10 anniversary

>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593
>
>Jerry DeLisle  changed:
>
>   What|Removed |Added
>
> CC||jvdelisle at gcc dot gnu.org
>
>--- Comment #6 from Jerry DeLisle  ---
>(In reply to Thomas Koenig from comment #5)
>> Tim, can you grab a clean copy of trunk (from a Linux box or from
>> whereever), cooy that to your Windows machine and try again?
>
>Thomas, do you have bootstrap working?
>
>I have it building without bootstrap, but I am totally unclear about some of
>the configure parameters, when I tried some of the odd ones used by the Cygwin
>released 5.4 I could not get through stage 1
>
>-- 
>You are receiving this mail because:
>You reported the bug.

[Bug lto/63242] memory starvation caused by flatten attribute

2016-09-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63242

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Andrew Pinski  ---
Dup of bug 77472.

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

[Bug lto/77472] __attribute__((flatten)) when used with -flto can lead to extreme number of inlined functions

2016-09-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77472

Andrew Pinski  changed:

   What|Removed |Added

 CC||wbrana at gmail dot com

--- Comment #11 from Andrew Pinski  ---
*** Bug 63242 has been marked as a duplicate of this bug. ***

[Bug lto/63242] memory starvation caused by flatten attribute

2016-09-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63242

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Andrew Pinski  ---
,  There is another bug about this now too.

[Bug testsuite/63299] ASan reported alloc-dealloc-mismatch in g++.old-deja/g++.jason/init3.C

2016-09-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63299

--- Comment #1 from Andrew Pinski  ---
Does this still happen?

[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant

2016-09-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-17
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #5 from Andrew Pinski  ---
.

[Bug c++/77626] [6/7 Regression] ICE with -Wall on x86_64-linux-gnu (internal compiler error: Segmentation fault, byte_from_pos, cxx_fold_indirect_ref)

2016-09-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77626

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-17
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.3
Summary|ICE with -Wall on   |[6/7 Regression] ICE with
   |x86_64-linux-gnu (internal  |-Wall on x86_64-linux-gnu
   |compiler error: |(internal compiler error:
   |Segmentation fault, |Segmentation fault,
   |byte_from_pos,  |byte_from_pos,
   |cxx_fold_indirect_ref)  |cxx_fold_indirect_ref)
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r230365.

[Bug middle-end/77624] [5/6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: in fold_builtin_atomic_always_lock_free, at builtins.c:5583)

2016-09-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77624

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r216982, I'll have a look.

[Bug middle-end/77624] [5/6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: in fold_builtin_atomic_always_lock_free, at builtins.c:5583)

2016-09-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77624

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-17
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE on x86_64-linux-gnu |[5/6/7 Regression] ICE on
   |(internal compiler error:   |x86_64-linux-gnu (internal
   |in  |compiler error: in
   |fold_builtin_atomic_always_ |fold_builtin_atomic_always_
   |lock_free, at   |lock_free, at
   |builtins.c:5583)|builtins.c:5583)
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/77626] New: ICE with -Wall on x86_64-linux-gnu (internal compiler error: Segmentation fault, byte_from_pos, cxx_fold_indirect_ref)

2016-09-17 Thread chengniansun at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77626

Bug ID: 77626
   Summary: ICE with -Wall on x86_64-linux-gnu (internal compiler
error: Segmentation fault, byte_from_pos,
cxx_fold_indirect_ref)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160916 (experimental) [trunk revision 240207] (GCC) 
$ 
$ g++-trunk -Wall small.C 
small.C:2:18: error: field ‘aligned’ has incomplete type ‘struct2’
   struct struct2 aligned;
  ^~~
small.C:2:10: note: forward declaration of ‘struct struct2’
   struct struct2 aligned;
  ^~~
small.C: In function ‘void fn1(int)’:
small.C:6:15: internal compiler error: Segmentation fault
   fn1((int &)a);
   ^
0xdc7baf crash_signal
../../gcc-source-trunk/gcc/toplev.c:336
0xdb6a3c byte_from_pos(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/stor-layout.c:862
0x895eac cxx_fold_indirect_ref
../../gcc-source-trunk/gcc/cp/constexpr.c:2897
0x89e8f0 cxx_eval_indirect_ref
../../gcc-source-trunk/gcc/cp/constexpr.c:3029
0x89e8f0 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3903
0x8a46df cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:4382
0x8a79cc maybe_constant_value_1
../../gcc-source-trunk/gcc/cp/constexpr.c:4576
0x8a79cc maybe_constant_value(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:4600
0x65704a build_over_call
../../gcc-source-trunk/gcc/cp/call.c:7766
0x662c4f build_new_function_call(tree_node*, vec**, bool, int)
../../gcc-source-trunk/gcc/cp/call.c:4190
0x8062d8 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2440
0x77d54b cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6937
0x77b972 cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8019
0x785877 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8696
0x785e43 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8798
0x786733 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9086
0x789069 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9253
0x78968f cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:10736
0x797f3a cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10587
0x798e35 cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10859
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 
$ g++-trunk small.C
small.C:2:18: error: field ‘aligned’ has incomplete type ‘struct2’
   struct struct2 aligned;
  ^~~
small.C:2:10: note: forward declaration of ‘struct struct2’
   struct struct2 aligned;
  ^~~
$ 
$ cat small.C
struct A {
  struct struct2 aligned;
};
void fn1(int) {
  A a;
  fn1((int &)a);
}