[Bug target/67887] New: FAIL: gcc.dg/pr65345-3.c (internal compiler error)

[sch...@linux-m68k.org]

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

Bug ID: 67887
   Summary: FAIL: gcc.dg/pr65345-3.c (internal compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: powerpc*-*-*

This crash exists at least since r222762.

$ gcc/xgcc -B gcc/ ../gcc/testsuite/gcc.dg/pr65345-3.c 
../gcc/testsuite/gcc.dg/pr65345-3.c:8:1: internal compiler error: Segmentation
fault
 float a3 = sizeof (i++);
 ^
0x106a5c4b crash_signal
../../gcc/toplev.c:353
0x1043df50 gimple_body(tree_node*)
../../gcc/gimple-expr.c:312
0x1045b05b gimple_add_tmp_var(tree_node*)
../../gcc/gimplify.c:700
0x1043e433 create_tmp_var(tree_node*, char const*)
../../gcc/gimple-expr.c:467
0x109734f7 rs6000_atomic_assign_expand_fenv
../../gcc/config/rs6000/rs6000.c:36506
0x101bce0f build_atomic_assign
../../gcc/c/c-typeck.c:3738
0x101bde53 build_unary_op(unsigned int, tree_code, tree_node*, int)
../../gcc/c/c-typeck.c:4131
0x101e5303 c_parser_postfix_expression_after_primary
../../gcc/c/c-parser.c:8089
0x101de7af c_parser_postfix_expression
../../gcc/c/c-parser.c:7806
0x101e103b c_parser_unary_expression
../../gcc/c/c-parser.c:6693
0x101e1db7 c_parser_cast_expression
../../gcc/c/c-parser.c:6531
0x101e202b c_parser_binary_expression
../../gcc/c/c-parser.c:6347
0x101e29eb c_parser_conditional_expression
../../gcc/c/c-parser.c:6123
0x101e2f5b c_parser_expr_no_commas
../../gcc/c/c-parser.c:6041
0x101e3627 c_parser_expression
../../gcc/c/c-parser.c:8113
0x101decbf c_parser_postfix_expression
../../gcc/c/c-parser.c:7309
0x101e103b c_parser_unary_expression
../../gcc/c/c-parser.c:6693
0x101e15b3 c_parser_sizeof_expression
../../gcc/c/c-parser.c:6743
0x101e15b3 c_parser_unary_expression
../../gcc/c/c-parser.c:6664
0x101e1db7 c_parser_cast_expression
../../gcc/c/c-parser.c:6531

[Bug target/67887] FAIL: gcc.dg/pr65345-3.c (internal compiler error)

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug libstdc++/67173] experimental/filesystem/operations/current_path.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct  7 21:00:50 2015
New Revision: 228584

URL: https://gcc.gnu.org/viewcvs?rev=228584=gcc=rev
Log:
Backport Filesystem TS fixes from mainline.

PR libstdc++/67173
PR libstdc++/67747
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check _XOPEN_VERSION
and PATH_MAX for _GLIBCXX_USE_REALPATH.  Remove _GLIBCXX_ prefix
from HAVE_STRUCT_DIRENT_D_TYPE.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/bits/locale_conv.h [!_GLIBCXX_USE_WCHAR_T]
(__do_str_codecvt, __str_codecvt_in, __str_codecvt_out): Enable.
* include/experimental/fs_dir.h (operator==, operator==):
Use owner_before instead of pointer equality.
(directory_iterator(std::shared_ptr<_Dir>, error_code*)): Remove.
* include/experimental/fs_path.h (operator==, operator==):
* include/experimental/fs_path.h [!_GLIBCXX_USE_WCHAR_T]
(path::wstring, path::generic_wstring): Disable.
* src/filesystem/path.cc (path::_S_convert_loc)
[!_GLIBCXX_USE_WCHAR_T]: Skip conversion.
* src/filesystem/Makefile.am: Add cxx11_abi_sources.
* src/filesystem/Makefile.in: Regenerate.
* src/filesystem/cow-dir.cc: New.
* src/filesystem/cow-ops.cc: New.
* src/filesystem/cow-path.cc: New.
* src/filesystem/dir.cc: Define macro for new ABI.
(native_readdir): Remove.
(_Dir::advance): Use readdir instead of native_readdir.
(recursive_directory_iterator(const path&, directory_options,
error_code*)): Use swap instead of reset.
(ErrorCode): Remove.
(_Dir::advance): Change ErrorCode parameter to error_code*, add
directory_options parameter and check it on error.
(opendir): Rename to open_dir to avoid clashing with macro. Change
ErrorCode parameter to error_code*.
(make_shared_dir): Remove.
(native_readdir) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Don't set errno.
(directory_iterator(std::shared_ptr<_Dir>, error_code*)): Remove.
(directory_iterator(const path&, directory_options, error_code*)):
Pass options to _Dir::advance and create non-end iterator on error.
(recursive_directory_iterator(const path&, directory_options,
error_code*)): Clear error_code on ignored error, create non-end
iterator otherwise.
(recursive_directory_iterator::increment): Pass _M_options to
_Dir::advance.
(recursive_directory_iterator::pop): Likewise.
* src/filesystem/ops.cc: Define macro for new ABI.
(canonical) [!_GLIBCXX_USE_REALPATH]: Add alternative implementation.
(is_dot, is_dotdot): Define new helpers.
(create_directories): Fix error handling.
* src/filesystem/path.cc: Define macro for new ABI.
(path::_S_convert_loc) [!_GLIBCXX_USE_WCHAR_T]: Skip conversion.
* testsuite/experimental/filesystem/iterators/directory_iterator.cc:
New.
* testsuite/experimental/filesystem/iterators/
recursive_directory_iterator.cc: New.
* testsuite/experimental/filesystem/operations/canonical.cc: New.
* testsuite/experimental/filesystem/operations/create_directories.cc:
New.
* testsuite/experimental/filesystem/operations/exists.cc: Add more
tests.
* testsuite/experimental/filesystem/operations/absolute.cc: Add test
variables.
* testsuite/experimental/filesystem/operations/copy.cc: Likewise.
* testsuite/experimental/filesystem/operations/current_path.cc:
Likewise.
* testsuite/experimental/filesystem/operations/file_size.cc: Likewise.
* testsuite/experimental/filesystem/operations/status.cc: Likewise.
* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Likewise.
* testsuite/experimental/filesystem/path/assign/assign.cc: Check for
wchar_t support.
* testsuite/experimental/filesystem/path/concat/strings.cc: Likewise.
* testsuite/experimental/filesystem/path/construct/range.cc: Likewise.

Added:
branches/gcc-5-branch/libstdc++-v3/src/filesystem/cow-dir.cc
  - copied, changed from r228554,
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/exists.cc
branches/gcc-5-branch/libstdc++-v3/src/filesystem/cow-ops.cc
  - copied, changed from r228554,
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/exists.cc
branches/gcc-5-branch/libstdc++-v3/src/filesystem/cow-path.cc
  - copied, changed from r228554,
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/exists.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/filesystem/iterators/
   

[Bug libstdc++/67747] experimental/filesystem/iterators/recursive_directory_iterator.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct  7 21:00:50 2015
New Revision: 228584

URL: https://gcc.gnu.org/viewcvs?rev=228584=gcc=rev
Log:
Backport Filesystem TS fixes from mainline.

PR libstdc++/67173
PR libstdc++/67747
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check _XOPEN_VERSION
and PATH_MAX for _GLIBCXX_USE_REALPATH.  Remove _GLIBCXX_ prefix
from HAVE_STRUCT_DIRENT_D_TYPE.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/bits/locale_conv.h [!_GLIBCXX_USE_WCHAR_T]
(__do_str_codecvt, __str_codecvt_in, __str_codecvt_out): Enable.
* include/experimental/fs_dir.h (operator==, operator==):
Use owner_before instead of pointer equality.
(directory_iterator(std::shared_ptr<_Dir>, error_code*)): Remove.
* include/experimental/fs_path.h (operator==, operator==):
* include/experimental/fs_path.h [!_GLIBCXX_USE_WCHAR_T]
(path::wstring, path::generic_wstring): Disable.
* src/filesystem/path.cc (path::_S_convert_loc)
[!_GLIBCXX_USE_WCHAR_T]: Skip conversion.
* src/filesystem/Makefile.am: Add cxx11_abi_sources.
* src/filesystem/Makefile.in: Regenerate.
* src/filesystem/cow-dir.cc: New.
* src/filesystem/cow-ops.cc: New.
* src/filesystem/cow-path.cc: New.
* src/filesystem/dir.cc: Define macro for new ABI.
(native_readdir): Remove.
(_Dir::advance): Use readdir instead of native_readdir.
(recursive_directory_iterator(const path&, directory_options,
error_code*)): Use swap instead of reset.
(ErrorCode): Remove.
(_Dir::advance): Change ErrorCode parameter to error_code*, add
directory_options parameter and check it on error.
(opendir): Rename to open_dir to avoid clashing with macro. Change
ErrorCode parameter to error_code*.
(make_shared_dir): Remove.
(native_readdir) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Don't set errno.
(directory_iterator(std::shared_ptr<_Dir>, error_code*)): Remove.
(directory_iterator(const path&, directory_options, error_code*)):
Pass options to _Dir::advance and create non-end iterator on error.
(recursive_directory_iterator(const path&, directory_options,
error_code*)): Clear error_code on ignored error, create non-end
iterator otherwise.
(recursive_directory_iterator::increment): Pass _M_options to
_Dir::advance.
(recursive_directory_iterator::pop): Likewise.
* src/filesystem/ops.cc: Define macro for new ABI.
(canonical) [!_GLIBCXX_USE_REALPATH]: Add alternative implementation.
(is_dot, is_dotdot): Define new helpers.
(create_directories): Fix error handling.
* src/filesystem/path.cc: Define macro for new ABI.
(path::_S_convert_loc) [!_GLIBCXX_USE_WCHAR_T]: Skip conversion.
* testsuite/experimental/filesystem/iterators/directory_iterator.cc:
New.
* testsuite/experimental/filesystem/iterators/
recursive_directory_iterator.cc: New.
* testsuite/experimental/filesystem/operations/canonical.cc: New.
* testsuite/experimental/filesystem/operations/create_directories.cc:
New.
* testsuite/experimental/filesystem/operations/exists.cc: Add more
tests.
* testsuite/experimental/filesystem/operations/absolute.cc: Add test
variables.
* testsuite/experimental/filesystem/operations/copy.cc: Likewise.
* testsuite/experimental/filesystem/operations/current_path.cc:
Likewise.
* testsuite/experimental/filesystem/operations/file_size.cc: Likewise.
* testsuite/experimental/filesystem/operations/status.cc: Likewise.
* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Likewise.
* testsuite/experimental/filesystem/path/assign/assign.cc: Check for
wchar_t support.
* testsuite/experimental/filesystem/path/concat/strings.cc: Likewise.
* testsuite/experimental/filesystem/path/construct/range.cc: Likewise.

Added:
branches/gcc-5-branch/libstdc++-v3/src/filesystem/cow-dir.cc
  - copied, changed from r228554,
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/exists.cc
branches/gcc-5-branch/libstdc++-v3/src/filesystem/cow-ops.cc
  - copied, changed from r228554,
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/exists.cc
branches/gcc-5-branch/libstdc++-v3/src/filesystem/cow-path.cc
  - copied, changed from r228554,
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/exists.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/filesystem/iterators/
   

[Bug libstdc++/67747] experimental/filesystem/iterators/recursive_directory_iterator.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|6.0 |5.3

--- Comment #11 from Jonathan Wakely  ---
Fixed for 5.3 too.

[Bug fortran/67885] ICE on using parameter array in block

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #1)
> Deleting this inner block gives another error :
> 
> $ cat z5.f90
> program p
>block
>   real, parameter :: a(2) = 1.0
>   real :: x(2)
>   x = a
>   print *, x
>end block
> end
> 
> 
> $ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z5.f90
> /tmp/cckgiZhq.o: In function `p':
> /home/.../z5.f90:5: undefined reference to `a.3386'
> collect2: error: ld returned 1 exit status
> 

The a(2) appears to be optimized out.  Don't know if the
code is legal because I haven't looked at standard, yet.
Changing your print statement to 

  if (x(1) /= 1.0) call abort

gives

% gfc6 -fdump-tree-original -c g5.f90
% cat g5.f90.003t.original
p ()
{
  {
real(kind=4) x[2];

(void) __builtin_memcpy ((void *) , (void *) , 8);
if (x[0] != 1.0e+0)
  {
_gfortran_abort ();
  }
L.2:;
L.1:;
  }
}

[Bug c/67882] surprising offsetof result on an invalid array member without diagnostic

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Created attachment 36459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36459=edit
/home/remote/msebor/patches/gcc-67882-surprising_offsetof_result.patch

Proposed patch.

[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Created attachment 36458
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36458=edit
Require consistent shared_ptr lock policy

Maybe we should solve this by forcing a linker error when an object doesn't
have the same lock policy as the library.

This patch causes the shared_ptr tests to FAIL when run with -march=i386, with
this error:

include/bits/shared_ptr_base.h:160: undefined reference to `void
std::__check_lock_policy<(__gnu_cxx::_Lock_policy)1>()

Instead of corrupting the heap at run-time the tests fail to link because the
library only has a definition for 

std::__check_lock_policy<(__gnu_cxx::_Lock_policy)2>()

The same thing should work for arm and other targets where the availability of
atomics depends on -march.

[Bug tree-optimization/67886] New: Incomplete optimization for virtual function call into freshly constructed object

[Simon.Richter at hogyros dot de]

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

Bug ID: 67886
   Summary: Incomplete optimization for virtual function call into
freshly constructed object
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Simon.Richter at hogyros dot de
  Target Milestone: ---

This is a bit of a corner/academic case, but came up in a Stack Overflow
discussion:

struct Base {
virtual void func() = 0;
};

struct Derived : Base {
virtual void func() { };
};

void test()
{
Base* base = new Derived;

for (int i = 0; i < 1000; ++i)
{
base->func();
}
}

The generated assembler code on x86_64 with -O3 is

Disassembly of section .text:

 :
   0:   55  push   %rbp
   1:   53  push   %rbx
   2:   bf 08 00 00 00  mov$0x8,%edi
   7:   bb e8 03 00 00  mov$0x3e8,%ebx
   c:   48 83 ec 08 sub$0x8,%rsp
  10:   e8 00 00 00 00  callq  15 
11: R_X86_64_PC32   operator new(unsigned long)-0x4
  15:   ba 00 00 00 00  mov$0x0,%edx
16: R_X86_64_32 vtable for Derived+0x10
  1a:   48 89 c5mov%rax,%rbp
  1d:   48 c7 00 00 00 00 00movq   $0x0,(%rax)
20: R_X86_64_32Svtable for Derived+0x10
  24:   eb 13   jmp39 
  26:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  2d:   00 00 00 
  30:   83 eb 01sub$0x1,%ebx
  33:   74 1a   je 4f 
  35:   48 8b 55 00 mov0x0(%rbp),%rdx
  39:   48 8b 12mov(%rdx),%rdx
  3c:   48 81 fa 00 00 00 00cmp$0x0,%rdx
3f: R_X86_64_32SDerived::func()
  43:   74 eb   je 30 
  45:   48 89 efmov%rbp,%rdi
  48:   ff d2   callq  *%rdx
  4a:   83 eb 01sub$0x1,%ebx
  4d:   75 e6   jne35 
  4f:   48 83 c4 08 add$0x8,%rsp
  53:   5b  pop%rbx
  54:   5d  pop%rbp
  55:   c3  retq   

Disassembly of section .text._ZN7Derived4funcEv:

 :
   0:   f3 c3   repz retq 

This looks like an optimization half-done. The optimizer correctly inlines the
function call to Derived::func() into the loop, and also correctly verifies
that the function pointer found in the vtable is indeed the same function that
was inlined -- otherwise, the inlined function is skipped and the regular
function called.

I presume that the pointer is rechecked on every loop iteration because it is
possible that the function call can destroy the object and create a new one in
its place that still derives from Base, so that is correct.

If you set -fPIC, the actual values for the vtable pointer and the pointer to
Derived::func() are fetched outside of the loop, and rechecked on each loop
iteration, again, correctly.

However: without -fPIC, there is no way to get a different definition of
Derived::func() without invoking UB, so the function pointer check is
tautological and can be optimized out, unraveling the entire fuzzy ball, as the
inlined function does not destroy the object, and inlining it into the loop
should give an empty loop that can be removed.

Also, wouldn't setting -fvisibility=hidden also take Derived's symbols out of
the dynamic symbol table, in which case I wouldn't be able to override them at
runtime with a preload library?

The optimal solution from an assembler programmer's perspective would be to
take the knowledge that the inlined function does not touch the object's
vtable, and create a path that handles the remaining loop iterations after the
object was shown to be a Derived object once -- this would probably be
optimized to a conditional jump to the ret instruction in the RTL pass -- but I
don't have enough knowledge to tell whether that would be easily doable in this
case.

[Bug libstdc++/67173] experimental/filesystem/operations/current_path.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for 5.3 and 6.0

[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
I've just realised this is probably the same issue as PR42734

If you compile for armv5 then shared_ptr uses a mutex internally, because armv5
doesn't support the necessary atomics. The library is compiled for armv7, so
its shared_ptr uses atomics.  When you pass a shared_ptr from an object
compiled with armv5 to a library compiled as armv7 they disagree on the size
and layout of the object, and all hell breaks loose.

[Bug c/67879] New: unnecessary jump in ternary

[marccelani at fb dot com]

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

Bug ID: 67879
   Summary: unnecessary jump in ternary
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marccelani at fb dot com
  Target Milestone: ---

The following functions f and f2 should compile the same, but f includes a jump
whereas f2 properly avoids the jump and adds the result of the comparison.

int f(int a, int b, int* c) {
bool x = a < b;
return x ? *c : *c + 1;
}

int f2(int a, int b, int* c) {
bool x = a < b;
return *c + (x ? 0 :  1);
}


https://goo.gl/OFhXTp

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

--- Comment #19 from Uroš Bizjak  ---
(In reply to Justas L from comment #18)
> Out of curiosity, what could it be that makes -mincoming-stack-boundary=3
> successfully deal with rogue code while -mstackrealign fails at that?
> Shouldn't -mstackrealign do the same job without being told what the outside
> stack alignment is, or am I misunderstanding it?

-mstackrealign conditionally generates realignment prologue, depending on
presence of insns that require 128bit alignment. It looks that heuristics is
not yet fully reliable on x86_64. Bugreports welcome!

-mincoming-stack-boundary=3 and force_align_arg_pointer will always
unconditionally generate realignment prologue

[Bug c/67872] missing -Warray-bounds warning, bogus -Wmaybe-uninitialized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-07
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
> gcc-5 -S t.c -O2 -Warray-bounds
t.c: In function ‘foo’:
t.c:7:14: warning: array subscript is above array bounds [-Warray-bounds]
 return a [4];
  ^

same with current trunk.  -O1 doesn't implement -Warray-bounds, it's
part of value-range analysis.

The uninit warning is a "feature", we optimize b[4] to "undefined"
(and too early to catch -Warray-bounds).

Confirmed for the fact that we miss a frontend based -Warray-bounds warning
that can warn for those simple cases.

[Bug target/67880] New: [ARM] -fno-align-functions does not work for thumb

[chrbr at gcc dot gnu.org]

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

Bug ID: 67880
   Summary: [ARM] -fno-align-functions does not work for thumb
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

void foo()
{
}

compiled with -O2 -mthumb -mno-align-functions

.text
.align  2
.global foo
.syntax unified
.code   16
.thumb_func

is aligned on 4 bytes instead of default required 2 bytes

[Bug tree-optimization/67879] unnecessary jump in ternary

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-07
  Component|c   |tree-optimization
Version|unknown |5.2.0
 Depends on||23286
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
With GCC 5 at -O2 it's

_Z1fiiPi:
.LFB0:
.cfi_startproc
cmpl%esi, %edi
movl(%rdx), %eax
jl  .L5
addl$1, %eax
ret
.p2align 4,,10
.p2align 3
.L5:
rep ret

vs.

_Z2f2iiPi:
.LFB1:
.cfi_startproc
xorl%eax, %eax
cmpl%esi, %edi
setge   %al
addl(%rdx), %eax
ret

where f2 is already in if-converted form on the GIMPLE level:

int f2(int, int, int*) (int a, int b, int * c)
{
  int _6;
  int _7;
  bool _8;
  int _9;

  :
  _6 = *c_5(D);
  _8 = a_2(D) >= b_3(D);
  _9 = (int) _8;
  _7 = _6 + _9;
  return _7;

The reason why we are not if-converting f on the GIMPLE level is
the lack of a code hoisting pass and thus we have

  :
  if (a_2(D) < b_3(D))
goto ;
  else
goto ;

  :
  iftmp.0_6 = *c_5(D);
  goto ;

  :
  _7 = *c_5(D);
  iftmp.0_8 = _7 + 1;

  :
  # iftmp.0_1 = PHI 

which "confuses" phiopt enough.  Only RTL hoists the loads (in 261r.mach?).

PR23286 tracks the lack of code hoisting on GIMPLE.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug 23286] Missed code hoisting optimization

[Bug target/67877] Split stack needs to be support for AARCH64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/67880] [ARM] -fno-align-functions does not work for thumb

[chrbr at gcc dot gnu.org]

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

--- Comment #1 from chrbr at gcc dot gnu.org ---
optimize flags should not be part of the alignment ABI. 

fixed with https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02198.html

[Bug c++/67881] New: type deduced incorrectly in constructor template when binding to const int

[akrzemi1 at gmail dot com]

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

Bug ID: 67881
   Summary: type deduced incorrectly in constructor template when
binding to const int
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrzemi1 at gmail dot com
  Target Milestone: ---

My class has a perfect-forwarding non-explicit constructor. I expect that when
it binds to a constant lvalue of type int, it recognizes the type as lvalue
reference. My expectation is illustrated with the static_assert in the code:

```
#include 

struct any_
{
template  any_(R&&) {
static_assert(std::is_lvalue_reference::value, "expected lvalue
ref");
}
};

int main()
{
const int i = 7;
any_ oi = i;
}
```

This assertion fails in gcc 5.1 and 5.2 (but passes in 4.8 and 4.9).

[Bug c/65345] ICE with _Generic selection on _Atomic int

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #22 from Bernd Edlinger  ---
I still have:

arm-linux-gnueabihf-gcc pr65345-3.c 
pr65345-3.c:8:1: internal compiler error: Segmentation fault
 float a3 = sizeof (i++);
 ^
0xaa349f crash_signal
../../gcc-6-20151004.orig/gcc/toplev.c:353
0x8692c0 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc-6-20151004.orig/gcc/tree.h:2863
0x8692c0 gimple_body(tree_node*)
../../gcc-6-20151004.orig/gcc/gimple-expr.c:312
0x88b8e7 gimple_add_tmp_var(tree_node*)
../../gcc-6-20151004.orig/gcc/gimplify.c:700
0x86999a create_tmp_var(tree_node*, char const*)
../../gcc-6-20151004.orig/gcc/gimple-expr.c:467
0xdd0610 arm_atomic_assign_expand_fenv(tree_node**, tree_node**, tree_node**)
../../gcc-6-20151004.orig/gcc/config/arm/arm-builtins.c:2977
0x5de84f build_atomic_assign
../../gcc-6-20151004.orig/gcc/c/c-typeck.c:3738
0x5dfbf4 build_unary_op(unsigned int, tree_code, tree_node*, int)
../../gcc-6-20151004.orig/gcc/c/c-typeck.c:4131
0x60300d c_parser_postfix_expression_after_primary
../../gcc-6-20151004.orig/gcc/c/c-parser.c:8089
0x5fbcd7 c_parser_postfix_expression
../../gcc-6-20151004.orig/gcc/c/c-parser.c:7806
0x5fe352 c_parser_unary_expression
../../gcc-6-20151004.orig/gcc/c/c-parser.c:6693
0x5fefbf c_parser_cast_expression
../../gcc-6-20151004.orig/gcc/c/c-parser.c:6531
0x5ff1a5 c_parser_binary_expression
../../gcc-6-20151004.orig/gcc/c/c-parser.c:6347
0x5ffdf5 c_parser_conditional_expression
../../gcc-6-20151004.orig/gcc/c/c-parser.c:6123
0x6003e0 c_parser_expr_no_commas
../../gcc-6-20151004.orig/gcc/c/c-parser.c:6041
0x600ab2 c_parser_expression
../../gcc-6-20151004.orig/gcc/c/c-parser.c:8113
0x5fbfc1 c_parser_postfix_expression
../../gcc-6-20151004.orig/gcc/c/c-parser.c:7309
0x5fe352 c_parser_unary_expression
../../gcc-6-20151004.orig/gcc/c/c-parser.c:6693
0x5fe8aa c_parser_sizeof_expression
../../gcc-6-20151004.orig/gcc/c/c-parser.c:6743
0x5fe8aa c_parser_unary_expression
../../gcc-6-20151004.orig/gcc/c/c-parser.c:6664
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/67871] LTO falis for ARM big-endian

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 Target||arm-eabi
  Component|lto |target

--- Comment #1 from Richard Biener  ---
I suppose -mbig-endian doesn't get transfered to lto1 properly.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[ramana at gcc dot gnu.org]

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

--- Comment #23 from Ramana Radhakrishnan  ---
Author: ramana
Date: Wed Oct  7 08:37:35 2015
New Revision: 228562

URL: https://gcc.gnu.org/viewcvs?rev=228562=gcc=rev
Log:
Fix PR c/65345 for arm




2015-10-07  Ramana Radhakrishnan  

PR c/65345
* config/arm/arm-builtins.c (arm_atomic_assign_expand_fenv):
Use create_tmp_var_raw instead of create_tmp_var.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c

[Bug tree-optimization/67683] Missed vectorization: shifts of an induction variable

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Right shifts are divisions so the result isn't an affine evolution.

Yes, you could enhance the vectorizer to not rely on scalar evolutions (only)
for reduction detection.

[Bug c++/67881] type deduced incorrectly in constructor template when binding to const int

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Markus Trippelsdorf  ---
This works fine with current gcc-5 branch and gcc-6.
Closing.

[Bug other/67868] ICE in handling VTV sections for targets with section anchors.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

  Component|middle-end  |other
   Target Milestone|4.9.4   |6.0
Summary|[4.9/5/6 regression] ICE in |ICE in handling VTV
   |named section handling on   |sections for targets with
   |targets with section|section anchors.
   |anchors.|

--- Comment #4 from Ramana Radhakrishnan  ---
Update summary

[Bug other/67868] ICE in handling VTV sections for targets with section anchors.

[ramana at gcc dot gnu.org]

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

--- Comment #5 from Ramana Radhakrishnan  ---
(In reply to Richard Biener from comment #3)
> What GCC version (with VTV enabled) did work for you?

I do not think any version of GCC with VTV enabled has worked for AArch64 or
ARM - I failed to notice the special casing for .vtable_map_vars in
assemble_variable when I filed the bug.

[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> 2015-10-06  Louis Krupp 
>
>   PR fortran/65766
>   * gfortran.dg/substr_alloc_string_comp_1.f90: New.

AFAICT the test has not been committed.

[Bug middle-end/67868] [4.9/5/6 regression] ICE in named section handling on targets with section anchors.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

--- Comment #3 from Richard Biener  ---
What GCC version (with VTV enabled) did work for you?

[Bug c/65345] ICE with _Generic selection on _Atomic int

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

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

[Bug target/67887] FAIL: gcc.dg/pr65345-3.c (internal compiler error)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/ml/gcc-cvs/2015-10/msg00213.html

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

[Bug c++/67888] New: Compiling clang 3.7.0 results in is used but never defined

[rodrigc at gcc dot gnu.org]

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

Bug ID: 67888
   Summary: Compiling clang 3.7.0 results in is used but never
defined
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rodrigc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36460=edit
Module.ii.bz2

Version of GCC:

Using built-in specs.
COLLECT_GCC=/usr/local/bin/x86_64-portbld-freebsd11.0-g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-portbld-freebsd11.0/4.9.2/lto-wrapper
Target: x86_64-portbld-freebsd11.0
Configured with: ./../gcc-4.9.2/configure --target=x86_64-portbld-freebsd11.0
--disable-nls --enable-languages=c,c++ --without-headers --with-gmp=/usr/local
--with-pkgversion='FreeBSD Ports Collection for amd64' --with-system-zlib
--with-as=/usr/local/bin/x86_64-freebsd-as
--with-ld=/usr/local/bin/x86_64-freebsd-ld --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/
--build=x86_64-portbld-freebsd11.0
Thread model: posix
gcc version 4.9.2 (FreeBSD Ports Collection for amd64) 


System:
FreeBSD 11.0-CURRENT #6 r286639

Problem Description:

When clang 3.7.0 is compiled with gcc 4.9.2, using this command:

/usr/local/bin/x86_64-portbld-freebsd11.0-g++ -save-temps -isystem
/usr/obj/opt2/branches/head/tmp/usr/include
-L/usr/obj/opt2/branches/head/tmp/usr/lib
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
-I/usr/obj/opt2/branches/head/tmp/usr/include/c++/v1 -std=gnu++11
-L/usr/obj/opt2/branches/head/tmp/../lib/libc++
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/  -O2
-pipe
-I/opt2/branches/head/lib/clang/libclangbasic/../../../contrib/llvm/include
-I/opt2/branches/head/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include
-I/opt2/branches/head/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic
-I.
-I/opt2/branches/head/lib/clang/libclangbasic/../../../contrib/llvm/../../lib/clang/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
-fstack-protector-strong  -std=c++11 -fno-exceptions -fno-rtti  -c
/opt2/branches/head/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp
-o Module.o


the following error is observed:

In file included from
/opt2/branches/head/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/SourceLocation.h:22:0,
 from
/opt2/branches/head/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Module.h:18,
 from
/opt2/branches/head/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp:15:
/usr/obj/opt2/branches/head/tmp/usr/include/c++/v1/functional:1322:17: error:
'_Rp std::__1::__function::__base<_Rp(_ArgTypes ...)>::operator()(_ArgTypes&&
...) [with _Rp = void; _ArgTypes =
{clang::VisibleModuleSet::setVisible(clang::Module*, clang::SourceLocation,
clang::VisibleModuleSet::VisibleCallback,
clang::VisibleModuleSet::ConflictCallback)::Visiting}]', declared using local
type 'clang::VisibleModuleSet::setVisible(clang::Module*,
clang::SourceLocation, clang::VisibleModuleSet::VisibleCallback,
clang::VisibleModuleSet::ConflictCallback)::Visiting', is used but never
defined [-fpermissive]
 virtual _Rp operator()(_ArgTypes&& ...) = 0;

[Bug tree-optimization/67889] New: ICE on valid code at -O1 and above on x86_64-linux-gnu in VN_INFO, at tree-ssa-sccvn.c:384

[su at cs dot ucdavis.edu]

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

Bug ID: 67889
   Summary: ICE on valid code at -O1 and above on x86_64-linux-gnu
in VN_INFO, at tree-ssa-sccvn.c:384
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151007 (experimental) [trunk revision 228566] (GCC) 
$ 
$ gcc-trunk -O0 -c small.c
$ gcc-5.2 -O1 -c small.c
$ 
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn1’:
small.c:11:1: internal compiler error: in VN_INFO, at tree-ssa-sccvn.c:384
 }
 ^
0xc5710b VN_INFO(tree_node*)
../../gcc-trunk/gcc/tree-ssa-sccvn.c:384
0xc57854 vn_valueize
../../gcc-trunk/gcc/tree-ssa-sccvn.h:236
0xe29afd do_valueize(tree_node* (*)(tree_node*), tree_node*)
../../gcc-trunk/gcc/gimple-match-head.c:802
0xe29afd gimple_simplify_CONVERT_EXPR
/tmp/objdir/gcc/gimple-match.c:8085
0xe05b50 gimple_simplify
/tmp/objdir/gcc/gimple-match.c:12600
0xe08115 gimple_resimplify1
../../gcc-trunk/gcc/gimple-match-head.c:123
0xe2a8ee gimple_simplify_CONVERT_EXPR
/tmp/objdir/gcc/gimple-match.c:8306
0xe05b50 gimple_simplify
/tmp/objdir/gcc/gimple-match.c:12600
0xe08115 gimple_resimplify1
../../gcc-trunk/gcc/gimple-match-head.c:123
0xe2a66f gimple_simplify_CONVERT_EXPR
/tmp/objdir/gcc/gimple-match.c:8355
0xe05b50 gimple_simplify
/tmp/objdir/gcc/gimple-match.c:12600
0xe08115 gimple_resimplify1
../../gcc-trunk/gcc/gimple-match-head.c:123
0xe065b7 gimple_simplify_VIEW_CONVERT_EXPR
/tmp/objdir/gcc/gimple-match.c:8570
0xe065b7 gimple_simplify
/tmp/objdir/gcc/gimple-match.c:12602
0xe07f71 gimple_simplify(tree_code, tree_node*, tree_node*, gimple**,
tree_node* (*)(tree_node*))
../../gcc-trunk/gcc/gimple-match-head.c:400
0xc5f073 visit_reference_op_load
../../gcc-trunk/gcc/tree-ssa-sccvn.c:3049
0xc5f073 visit_use
../../gcc-trunk/gcc/tree-ssa-sccvn.c:3416
0xc617d4 process_scc
../../gcc-trunk/gcc/tree-ssa-sccvn.c:3636
0xc617d4 extract_and_process_scc_for_name
../../gcc-trunk/gcc/tree-ssa-sccvn.c:3723
0xc617d4 DFS
../../gcc-trunk/gcc/tree-ssa-sccvn.c:3775
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 





unsigned int a, *b;
unsigned short c;
int d;

void 
fn1 ()
{
  b = 
  *b = c = a; 
  *b = d;
}

[Bug tree-optimization/67830] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
Whoops.  c#4 was for an unrelated BZ.

[Bug c++/67888] Compiling clang 3.7.0 results in is used but never defined

[rodrigc at gcc dot gnu.org]

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

--- Comment #1 from Craig Rodrigues  ---
I was able to work around this problem in two ways, as I mentioned
on the cfe-dev mailing list for LLVM:
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045336.html

(1)  Patch Module.cpp to move "struct Visitor" outside of
VisibleModuleSet::setVisible()

OR

(2)  Add -fpermissive to command-line


clang can compile this with no problem, so I am filing the bug here.

[Bug c++/67888] Compiling clang 3.7.0 results in is used but never defined

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
Why do you use LLVM's libc++? This is not supported in any way.
So please use gcc's libstdc++ instead.

[Bug rtl-optimization/67477] [6 Regression] ICE in cselib_record_set, at cselib.c:2388

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
(In reply to Ryan Mansfield from comment #0)
> Created attachment 36298 [details]
> reduced preprocessed source
> 
> $ ./xgcc -v
> Using built-in specs.
> COLLECT_GCC=./xgcc
> Target: arm-unknown-linux-gnueabi
> Configured with: ../configure --target=arm-unknown-linux-gnueabi
> --prefix=/home/rmansfield/x-tools/arm-unknown-linux-gnueabi
> --with-sysroot=/home/rmansfield/x-tools/arm-unknown-linux-gnueabi/arm-
> unknown-linux-gnueabi//sys-root --disable-multilib
> --with-local-prefix=/home/rmansfield/x-tools/arm-unknown-linux-gnueabi/arm-
> unknown-linux-gnueabi/sys-root --disable-nls --enable-threads=posix
> --enable-symvers=gnu --enable-c99 --enable-long-long
> --enable-target-optspace target_alias=arm-unknown-linux-gnueabi
> --enable-languages=c++ --disable-libssp --enable-checking
> Thread model: posix
> gcc version 6.0.0 20150907 (experimental) [trunk revision 227519] (GCC) 
> 
> $ ./xgcc -B. ~/ice.i -O3 -fstack-protector-strong -mfpu=neon
> -mfloat-abi=softfp  -march=armv7-a -mfloat-abi=softfp -c
> /home/rmansfield/ice.i: In function 'swblit_1d_NV12_2_B8G8R8X8':
> /home/rmansfield/ice.i:69:1: internal compiler error: in cselib_record_set,
> at cselib.c:2388
>  }
>  ^
> 0x6df43f cselib_record_set
>   ../../gcc/cselib.c:2388
> 0x6df43f cselib_record_sets
>   ../../gcc/cselib.c:2605
> 0x6e0137 cselib_process_insn(rtx_insn*)
>   ../../gcc/cselib.c:2678
> 0x99ef08 reload_cse_regs_1
>   ../../gcc/postreload.c:235
> 0x99f23b reload_cse_regs
>   ../../gcc/postreload.c:81
> 0x99f23b execute
>   ../../gcc/postreload.c:2350
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> Started happening after r227382
> 
> https://gcc.gnu.org/viewcvs/gcc?view=revision=227382

I can not reproduce it anymore.  I guess  it is a duplicate of PR67756 and it
was solved by https://gcc.gnu.org/viewcvs/gcc?view=revision=228396.

[Bug fortran/67885] ICE on using parameter array in block

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-07
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type

[marcin.slusarz at intel dot com]

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

Marcin Ślusarz  changed:

   What|Removed |Added

 CC||marcin.slusarz at intel dot com

--- Comment #28 from Marcin Ślusarz  ---
*** Bug 67764 has been marked as a duplicate of this bug. ***

[Bug c/67764] -Wconversion generates false warnings for bitmask+cast expressions

[marcin.slusarz at intel dot com]

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

Marcin Ślusarz  changed:

   What|Removed |Added

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

--- Comment #5 from Marcin Ślusarz  ---
Heh, I took a closer look and this bug indeed is a duplicate. -Wconversion is
quite useless in its current form.

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

[Bug c/67764] -Wconversion generates false warnings for bitmask+cast expressions

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Marcin Ślusarz from comment #5)
> Heh, I took a closer look and this bug indeed is a duplicate. -Wconversion
> is quite useless in its current form.
> 
> *** This bug has been marked as a duplicate of bug 40752 ***

Being the main author of Wconversion, I do agree with this sentiment. You'll
see there is a patch there to alleviate this issue, but I couldn't manage to
get it approved and now I don't have the time to invest on this issue. If you
want to see this fixed, your best option is to adopt the patch, update it, test
it and try to get it approved. Comparisons with how Clang and other compilers
behave would be useful but they should not be the basis of your argumentation.
When arguing for a change, try to be smart and see the point of view of the
other side and address that convincingly.

[Bug fortran/65889] [6 Regressions] [OOP] ICE with sizeof a polymorphic variable.

[vehre at gcc dot gnu.org]

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

--- Comment #4 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Wed Oct  7 10:58:46 2015
New Revision: 228566

URL: https://gcc.gnu.org/viewcvs?rev=228566=gcc=rev
Log:
gcc/fortran/ChangeLog:

2015-10-07  Andre Vehreschild  

PR fortran/65889
* trans-intrinsic.c (gfc_conv_intrinsic_sizeof): Handle pointer to and
on stack class objects as sizeof parameter.

gcc/testsuite/ChangeLog:

2015-10-07  Andre Vehreschild  

PR fortran/65889
* gfortran.dg/sizeof_5.f90: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/sizeof_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
> Vous avez raison;  j'en suis désolé.  Je viens de le faire.

No problem! Thanks.

[Bug target/67850] Wrong call_used_regs used in aggregate_value_p

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Oct  7 10:30:12 2015
New Revision: 228565

URL: https://gcc.gnu.org/viewcvs?rev=228565=gcc=rev
Log:
Merge ix86_maybe_switch_abi with ix86_set_current_function

ix86_maybe_switch_abi is called to late during RTL expansion and we
use the stale information from compilation of the previous function.
aggregate_value_p uses call_used_regs.  aggregate_value_p is used by
IPA and return value optimization, which are called before
ix86_maybe_switch_abi is called.  This patch merges ix86_maybe_switch_abi
with ix86_set_current_function.

PR target/67850
* config/i386/i386.c (ix86_maybe_switch_abi): Merged with ...
(ix86_set_current_function): This.
(TARGET_EXPAND_TO_RTL_HOOK): Removed.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #20 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #19)
> (In reply to Justas L from comment #18)
> > Out of curiosity, what could it be that makes -mincoming-stack-boundary=3
> > successfully deal with rogue code while -mstackrealign fails at that?
> > Shouldn't -mstackrealign do the same job without being told what the outside
> > stack alignment is, or am I misunderstanding it?
> 
> -mstackrealign conditionally generates realignment prologue, depending on
> presence of insns that require 128bit alignment. It looks that heuristics is
> not yet fully reliable on x86_64. Bugreports welcome!

-mstackrealign works correctly as designed on x86-64.  The
issue is MIN_STACK_BOUNDARY.  When MIN_STACK_BOUNDARY is 128,
you don't need to realign the stack if you only need 128-bit
stack alignment.

[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Running this under valgrind I see 900+ errors, the first 100 seem to be from
the global strings in the libstdc++-v3/testsuite/util/testsuite_fs.h file (I
think).

All the errors are basically nonsense, reporting errors in getpid() and
mkstemp() and things that are very unlikely to be broken, so either that
executable is horribly miscompiled or valgrind is useless with it.

[Bug tree-optimization/67794] [6 regression] internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
   Assignee|aoliva at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #6 from Martin Jambor  ---
(In reply to Alexandre Oliva from comment #5)
> Martin, why doesn't SRA's modify_function use tree_versioning's args_to_skip
> infrastructure to remap the function

Because it does a few more transformations than just plain removal.
In fact, the plan (very long term, apparently) is to replace
args_to_skip with something akin to IPA-SRA's adjustments so that we
can do all this in truly IPA way.

>, including its prototype, and instead
> makes an (incomplete) work itself?  We end up with cloned PARM_DECLs that
> aren't parms at all, which may confuse other parts of the compiler.

Well, it does that, of course, otherwise it would have never passed
the testsuite, it's just that, ehm, the remapping from PARM_DECLS to
VAR_DECLs is not called when processing GIMPLE_ASMs.

I'll prepare a fix.

[Bug tree-optimization/67323] Use non-unit stride loads by preference when applicable

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
I note that the efficiency you gain is only by a reduced number of loads/store
instructions.  vld3 instead of six vldr (huh, appearantly vld3 can load 16
byte vectors but vldr only 8 byte ones?).  I assume vld3 has no penalty
for the lane-split itself so the code-size reduction is always wanted.
Thus we'd want to always use a lane load/store even if the permutation is
pointless as soon as we'd otherwise would issue more than one SLP load, say for

void
t5 (int len, int * __restrict p, int * __restrict q)
{
  for (int i = 0; i < len; i+=8) {
  p[i] = q[i] * 2;
  p[i+1] = q[i+1] * 2;
  p[i+2] = q[i+2] * 2;
  p[i+3] = q[i+3] * 2;
  p[i+4] = q[i+4] * 2;
  p[i+5] = q[i+5] * 2;
  p[i+6] = q[i+6] * 2;
  p[i+7] = q[i+7] * 2;
  }
}

instead of

.L4:
vldrd18, [r2, #-16]
vldrd19, [r2, #-8]
vldrd16, [r2, #-32]
vldrd17, [r2, #-24]
vshl.i32q9, q9, #1
vshl.i32q8, q8, #1
add r3, r3, #1
cmp r0, r3
vstrd18, [r1, #-16]
vstrd19, [r1, #-8]
vstrd16, [r1, #-32]
vstrd17, [r1, #-24]
add r2, r2, #32
add r1, r1, #32
bhi .L4

use vld2.32 / vst2.32?  Generally for SLP the implicit permute performed
by those instructions could be modeled properly (and the SLP chain
permuted accordingly).

[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program

[louis.krupp at zoho dot com]

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

--- Comment #11 from louis.krupp at zoho dot com ---
Dominique,

Vous avez raison;  j'en suis désolé.  Je viens de le faire.

Louis

 On Wed, 07 Oct 2015 00:47:39 -0700 dominiq at lps dot ens.fr  wrote  
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766 
> 
>--- Comment #10 from Dominique d'Humieres  --- 
>> 2015-10-06 Louis Krupp  
>> 
>>PR fortran/65766 
>>* gfortran.dg/substr_alloc_string_comp_1.f90: New. 
> 
>AFAICT the test has not been committed. 
> 
>-- 
>You are receiving this mail because: 
>You are on the CC list for the bug.

[Bug bootstrap/67385] READELF_FOR_TARGET isn't used in gcc configure

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed.

[Bug sanitizer/67867] UBSan bootstrap fails with error: ‘otype’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed in trunk.

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[hjl.tools at gmail dot com]

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

--- Comment #22 from H.J. Lu  ---
(In reply to Justas L from comment #21)
> When is MIN_STACK_BOUNDARY equal to 128? I thought it defaulted to 64 (8*8)
> for x86_64 and 32 (4*8) for x86, no?

i386.h has

* Minimum stack boundary.  */
#define MIN_STACK_BOUNDARY (TARGET_64BIT ? (TARGET_SSE ? 128 : 64) : 32)

[Bug middle-end/67766] [6 Regression]: Bootstrap failure on alpha-linux-gnu: ICE in simplify_subreg, at simplify-rtx.c

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Alexandre Oliva from comment #1)
> Mine.  Moving down the code in function.c that's under the comment:
>  /* If a named return value dumped decl_return to memory, then
> we may need to re-do the PROMOTE_MODE signed/unsigned
> extension.  */
> so that the test:
>  else if (GET_MODE (real_decl_rtl) != GET_MODE (decl_rtl))
> appears after the blocks that deal with PARALLELs and CONCATs fixes it for
> me, without any regressions on x86* regstraps.
> 
> Could you please confirm it fixes bootstrap on alpha?  TIA,

Yes, the patch, based on the above instructions, passes the bootstrap. I'm
currently in the regression tests, but I don't expect any surprises there.

[Bug middle-end/67766] [6 Regression]: Bootstrap failure on alpha-linux-gnu: ICE in simplify_subreg, at simplify-rtx.c

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Created attachment 36456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36456=edit
Patch that fixes bootstrap problem

[Bug sanitizer/67867] UBSan bootstrap fails with error: ‘otype’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Oct  7 14:09:05 2015
New Revision: 228569

URL: https://gcc.gnu.org/viewcvs?rev=228569=gcc=rev
Log:
PR sanitizer/67867
* search.c (accessible_p): Initialize OTYPE to NULL_TREE.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/search.c

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[bucaneer at gmail dot com]

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

--- Comment #24 from Justas L  ---
Oh, OK. I was looking at the patched code and forgot that part was patched.

[Bug bootstrap/67385] READELF_FOR_TARGET isn't used in gcc configure

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Oct  7 13:45:21 2015
New Revision: 228567

URL: https://gcc.gnu.org/viewcvs?rev=228567=gcc=rev
Log:
Check $READELF_FOR_TARGET for readelf in configure

Similar to as, ld, nm and objdump, gcc configure should check
$READELF_FOR_TARGET for readelf.

PR bootstrap/67385
* configure.ac (gcc_cv_readelf): Check $READELF_FOR_TARGET.
* configure: Regenerated.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[bucaneer at gmail dot com]

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

--- Comment #21 from Justas L  ---
(In reply to H.J. Lu from comment #20)
> -mstackrealign works correctly as designed on x86-64.  The
> issue is MIN_STACK_BOUNDARY.  When MIN_STACK_BOUNDARY is 128,
> you don't need to realign the stack if you only need 128-bit
> stack alignment.

When is MIN_STACK_BOUNDARY equal to 128? I thought it defaulted to 64 (8*8) for
x86_64 and 32 (4*8) for x86, no?

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

--- Comment #23 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #22)

> i386.h has
> 
> * Minimum stack boundary.  */
> #define MIN_STACK_BOUNDARY (TARGET_64BIT ? (TARGET_SSE ? 128 : 64) : 32)

But the patch changes this definition to:

 /* Minimum stack boundary.  */
-#define MIN_STACK_BOUNDARY (TARGET_64BIT ? (TARGET_SSE ? 128 : 64) : 32)
+#define MIN_STACK_BOUNDARY BITS_PER_WORD

So, we do have minimum stack boundary set to 64 bits in patched gcc.

[Bug rtl-optimization/67828] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #6 from Zhendong Su  ---
Below is another testcase that I believe exposes the same issue: 


---


int a = 2, b = 1, c = 1;

int
fn1 ()
{
  int d;
  for (; a; a--)
{
  for (d = 0; d < 4; d++)
{
  int k;
  if (c < 1)
if (k)
  c = 0;
  if (b)
continue;
  return 0;
}
  b = !1;
}
  return 0;
}

int
main ()
{
  fn1 ();

  if (a != 1) 
__builtin_abort (); 

  return 0;
}

[Bug rtl-optimization/67828] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #5 from Zhendong Su  ---
> This testcase invokes undefined behavior because of the overflow on the
> iterator, ... 

Just a quick comment that the testcase doesn't have undefined behaviors. As the
variable c is of type short, there shouldn't be signed overflow --- the
operations will be performed on its signed extended integer value and then
truncated back to a short.  

Thanks for looking into and fixing the issue.

[Bug go/67874] fd_unix.go does not build when there is fcntl64 and no fcntl syscall

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
Should be fixed.

[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g

[redflames1003 at gmail dot com]

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

--- Comment #35 from Christopher Torres  ---
(In reply to Alexandre Oliva from comment #33)
> Err, this is only fixed in the trunk so far.  It's approved for 5.2 too,
> after some time, if no issues pop up.  So, reopening.

Hey Alexandre,

I was wondering if it would be possible to get a patch for the 4.9 branch,
specifically 4.9.2. I tried applying the patch you posed here but I was unable
to cleanly compile due to errors. id->call_stmt and id->retbnd are not defined
in the struct.

We want to have this fix but are unable to upgrade to the latest due to the
size of our project.

Thanks,

Chris

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[uros at gcc dot gnu.org]

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

--- Comment #25 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Oct  7 17:42:09 2015
New Revision: 228577

URL: https://gcc.gnu.org/viewcvs?rev=228577=gcc=rev
Log:
PR target/66697
* config/i386/i386.c (ix86_option_override_internal): Always use
8-byte minimum stack boundary in 64-bit mode.
(ix86_compute_frame_layout): Remove assert on INCOMING_STACK_BOUNDARY.
(ix86_emit_save_reg_using_mov): Support unaligned SSE store.
Add a REG_CFA_EXPRESSION note if needed.
(ix86_emit_restore_sse_regs_using_mov): Support unaligned SSE load.
(ix86_handle_force_align_arg_pointer_attribute): New.
(ix86_minimum_incoming_stack_boundary): Remove TARGET_64BIT check.
(ix86_attribute_table): Set ix86_force_align_arg_pointer_string
with ix86_handle_force_align_arg_pointer_attribute.
* config/i386/i386.h (MIN_STACK_BOUNDARY): Set to BITS_PER_WORD.

testsuite/ChangeLog:

PR target/66697
* gcc.target/i386/20060512-1.c: Remove ia32 requirement.
(PUSH, POP): New defines.
(sse2_test): Use PUSH and POP to misalign runtime stack.
* gcc.target/i386/20060512-2.c: Remove ia32 requirement.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/20060512-1.c
trunk/gcc/testsuite/gcc.target/i386/20060512-2.c

[Bug c/67882] New: surprising offsetof result on an invalid array member without diagnostic

[msebor at gcc dot gnu.org]

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

Bug ID: 67882
   Summary: surprising offsetof result on an invalid array member
without diagnostic
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While looking some more at bug 67872, I noticed that the logic in
fold_offsetof_1 responsible for diagnosing past-the-end array element
references isn't quite correct after all.  GCC fails to diagnose cases of
invalid offsetof expressions whose member designator refers to an array element
past the end of the array plus one.  In the following test case, all but the
first offsetof expressions are strictly invalid.  The second one could probably
be considered an extension and accepted without diagnostic since it refers to
an element just past the end of the array, but all the others could and should
be diagnosed.

Diagnosing the invalid expressions seems especially important because
__builtin_offsetof evaluates to the "wrong" values for the invalid members. 
I.e., __builtin_offsetof (struct A, a1_1[0][1]) and __builtin_offsetof (struct
A, a1_1[1][0]) both evaluate to 1, and __builtin_offsetof (struct A,
a1_1[1][1]) evaluates to 2 rather than 3 as it would if the array element did
exist.  This is also why I opened a separate bug  rather than adding this as an
observation to the referenced bug.

struct A {
char a1_1[1][1];
int i;
} a;

void f (int i) {
#define Offset(m)  __builtin_offsetof (struct A, m)

_Static_assert (sizeof a.a1_1 == 1, "sizeof a.a1_1 == 1");

switch (i) {
case Offset (a1_1[0][0]):
case Offset (a1_1[0][1]):
case Offset (a1_1[1][0]):
case Offset (a1_1[1][1]):
break;
}
}
x.c: In function ‘f’:
x.c:14:5: error: duplicate case value
 case Offset (a1_1[1][0]):
 ^
x.c:13:5: error: previously used here
 case Offset (a1_1[0][1]):
 ^

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |5.3

--- Comment #26 from Uroš Bizjak  ---
Implemented on mainline, will backport to gcc-5 branch.

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

--- Comment #27 from Uroš Bizjak  ---
Created attachment 36457
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36457=edit
Backport for gcc-5 branch.

[Bug c++/67557] [4.9/5/6 regression] Calling copy constructor of base class in constructor of derived class produces crashing code

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|Calling copy constructor of |[4.9/5/6 regression]
   |base class in constructor   |Calling copy constructor of
   |of derived class produces   |base class in constructor
   |crashing code   |of derived class produces
   ||crashing code

--- Comment #12 from Jason Merrill  ---
This seems to be a regression from 4.0.

[Bug sanitizer/67865] ASAN crashes on thread creation

[dominik.stras...@onespin-solutions.com]

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

--- Comment #3 from dominik.stras...@onespin-solutions.com ---
I can say that it works with gcc 4.8.

Clang 3.7 could take a while because I suffer from an incompatibility between
gcc and clang so I cannot bind my C++ libs compiled with gcc to a clang
compiled binary.

Is there a separate repo for libsanitize I could drop in ?

glibc 2.12 is the glibc of RHEL 6, which should be quite popular.

Btw. I see different crashes, and ~50% of the times I don't see a crash at all.
Looks like a race.

I'll investigate.

[Bug fortran/67883] New: ICE on empty array constructor of character function

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 67883
   Summary: ICE on empty array constructor of character function
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With an effectively empty (i=m,n and m>n) array constructor :


$ cat z1.f90
program p
   integer i
   print *, [(f(i), i=2,1)]
contains
   function f(n)
  integer :: n
  character(:), allocatable :: f
  character(3) :: c = 'abc'
  f = c(n:n)
   end
end


$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z1.f90
z1.f90:3:25:

print *, [(f(i), i=2,1)]
 1
Warning: DO loop at (1) will be executed zero times [-Wzerotrip]
f951: internal compiler error: in gfc_resolve_character_array_constructor, at
fortran/array.c:1955

[Bug fortran/67884] New: Missing error message on required allocatable attribute

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 67884
   Summary: Missing error message on required allocatable
attribute
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This definition of f is incomplete :

$ cat z2a.f90
program p
   integer i
   print *, [(f(i), i=1,3)]
contains
   function f(n)
  integer :: n
  character(:) :: f
  character(3) :: c = 'abc'
  f = c(n:n)
   end
end

$ gfortran -g -O0 -Wall -fcheck=all z2a.f90
$ a.out


With additional/different options other effects may occur.
Only sometimes. Needs running a.out many times.
For example :

$ gfortran -g -O0 -fcheck=all -fstack-protector z2a.f90
$ a.out
Operating system error: Cannot allocate memory
Memory allocation failed

[Bug fortran/67884] Missing error message on required allocatable attribute

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Whereas, detected with explicit result variable :

$ cat z5a.f90
program p
   integer i
   print *, [(f(i), i=1,3)]
contains
   function f(n) result(z)
  integer :: n
  character(:) :: z
  character(3) :: c = 'abc'
  z = c(n:n)
   end
end

$ gfortran -g -O0 -Wall -fcheck=all z5a.f90
z5a.f90:5:26:

function f(n) result(z)
  1
Error: Entity 'z' at (1) has a deferred type parameter and requires either the
pointer or allocatable attribute

[Bug fortran/67885] New: ICE on using parameter array in block

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 67885
   Summary: ICE on using parameter array in block
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Using a parameter array in a block with an inner block :

$ cat z1.f90
program p
   block
  real, parameter :: a(2) = 1.0
  real :: x(2)
  x = a
  block
  end block
   end block
end


$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z1.f90
internal compiler error: in gfc_process_block_locals, at
fortran/trans-decl.c:6096

Same issue when using other intrinsic types, etc.

---

Compiles without parameter attribute :

$ cat z2.f90
program p
   block
  real :: a(2) = 1.0
  real :: x(2)
  x = a
  block
  end block
   end block
end

[Bug fortran/67885] ICE on using parameter array in block

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Deleting this inner block gives another error :

$ cat z5.f90
program p
   block
  real, parameter :: a(2) = 1.0
  real :: x(2)
  x = a
  print *, x
   end block
end


$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z5.f90
/tmp/cckgiZhq.o: In function `p':
/home/.../z5.f90:5: undefined reference to `a.3386'
collect2: error: ld returned 1 exit status


$ gfortran z5.f90
/tmp/ccwaNc8P.o: In function `MAIN__':
z5.f90:(.text+0xe): undefined reference to `a.3385'
collect2: error: ld returned 1 exit status

[Bug rtl-optimization/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> (In reply to Uroš Bizjak from comment #5)
> > Wrong expansion, adding CC.
> 
> The expand code looks OK to me.  Assigning to one DImode word
> of a TImode isn't supposed to change the other half.
> 
Agree.

GCC internal doc says

"  When used as an lvalue, 'subreg' is a word-based accessor.
  Storing to a 'subreg' modifies all the words of REG that
  overlap the 'subreg', but it leaves the other words of REG
  alone.

  When storing to a normal 'subreg' that is smaller than a word,
  the other bits of the referenced word are usually left in an
  undefined state.  This laxity makes it easier to generate
  efficient code for such instructions.  To represent an
  instruction that preserves all the bits outside of those in
  the 'subreg', use 'strict_low_part' or 'zero_extract' around
  the 'subreg'.
"

As the subreg itself is a word.  The rest of the reg should be saved.

> I think the problem is in LRA.  It tries to reload the low half
> of the TImode as follows:
> 
>   Creating newreg=104, assigning class NO_REGS to secondary r104
>51: r104:DI=r103:DI
> Inserting the sec. move after:
>52: r90:TI#0=r104:DI
> 
> then allocates it as an xmm<-mem move:
> 
>  Choosing alt 14 in insn 52:  (0) *v  (1) m {*movdi_internal}
>


> That isn't right because the move won't preserve the high half
> of the xmm register.  It would need to be a strict_lowpart to do that.

It is the same word subreg movement and the rest of the reg bits should be
saved as you wrote about the expander above.

It is not saved as it is implemented by movq which is zeroing the rest bits.  I
guess using movq is wrong here.

I am in difficult position.  Redefining movdi_internal could have a big
unpredictable effect on a major platform. I could implement using strict_low
for such case but it could also have a big effect on other targets too.

[Bug rtl-optimization/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov  ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> (In reply to Uroš Bizjak from comment #5)
> > Wrong expansion, adding CC.
> 
> The expand code looks OK to me.  Assigning to one DImode word
> of a TImode isn't supposed to change the other half.
> 
Agree.

GCC internal doc says

"  When used as an lvalue, 'subreg' is a word-based accessor.
  Storing to a 'subreg' modifies all the words of REG that
  overlap the 'subreg', but it leaves the other words of REG
  alone.

  When storing to a normal 'subreg' that is smaller than a word,
  the other bits of the referenced word are usually left in an
  undefined state.  This laxity makes it easier to generate
  efficient code for such instructions.  To represent an
  instruction that preserves all the bits outside of those in
  the 'subreg', use 'strict_low_part' or 'zero_extract' around
  the 'subreg'.
"

As the subreg itself is a word.  The rest of the reg should be saved.

> I think the problem is in LRA.  It tries to reload the low half
> of the TImode as follows:
> 
>   Creating newreg=104, assigning class NO_REGS to secondary r104
>51: r104:DI=r103:DI
> Inserting the sec. move after:
>52: r90:TI#0=r104:DI
> 
> then allocates it as an xmm<-mem move:
> 
>  Choosing alt 14 in insn 52:  (0) *v  (1) m {*movdi_internal}
>


> That isn't right because the move won't preserve the high half
> of the xmm register.  It would need to be a strict_lowpart to do that.

It is the same word subreg movement and the rest of the reg bits should be
saved as you wrote about the expander above.

It is not saved as it is implemented by movq which is zeroing the rest bits.  I
guess using movq is wrong here.

I am in difficult position.  Redefining movdi_internal could have a big
unpredictable effect on a major platform. I could implement using strict_low
for such case but it could also have a big effect on other targets too.


 (In reply to Uroš Bizjak from comment #7)
> (In reply to rsand...@gcc.gnu.org from comment #6)
>  
> > The expand code looks OK to me.  Assigning to one DImode word
> > of a TImode isn't supposed to change the other half.
> > 
> > I think the problem is in LRA.  It tries to reload the low half
> > of the TImode as follows:
> 
> Thanks for your analysis!
> 
> Reconfirmed as RA problem, adding another CC.

By the way I've check what reload would do in this case.  It generates the same
(wrong) code as LRA.  So if it is LRA bug, the same bug is present in original
reload.

[Bug go/67874] fd_unix.go does not build when there is fcntl64 and no fcntl syscall

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Oct  7 17:22:08 2015
New Revision: 228576

URL: https://gcc.gnu.org/viewcvs?rev=228576=gcc=rev
Log:
PR go/67874
net, runtime: Call C library fcntl function rather than syscall.Syscall.

Not all systems define a fcntl syscall; some only have fcntl64.

Fixes GCC PR go/67874.

Reviewed-on: https://go-review.googlesource.com/15497

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/net/fd_unix.go
trunk/libgo/runtime/go-varargs.c