[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 42567 [details]
> gcc8-pr82916.patch
> 
> Untested fix.

As you figured ref_maybe_used_by_stmt and stmt_clobbers_ref_p are supposed
to be read-write dependence checks.

Note you may not use stmt_clobbers_ref_p to ask whether to re-order

  ... = read;
  write = ...;

you'd have to use refs_anti_dependent_p.

The fix looks correct but as noted above you might want to audit the checks
for the possibility of the case anti-dependence checks lurking (which wouldn't
be handled correctly either).

[Bug tree-optimization/82929] [8 regression] r254579 causes ICE: tree check: expected ssa_name, have array_ref in has_single_use, at ssa-iterators.h:400

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/82930] New: [C++17/AArch64] ICE: in is_normal_capture_proxy, at cp/lambda.c:288 with structured binding in a lambda function with auto typed arguments

[p...@gcc-bugzilla.mail.kapsi.fi]

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

Bug ID: 82930
   Summary: [C++17/AArch64] ICE: in is_normal_capture_proxy, at
cp/lambda.c:288 with structured binding in a lambda
function with auto typed arguments
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---

Created attachment 42572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42572=edit
The test case that triggers `internal compiler error: in
is_normal_capture_proxy, at cp/lambda.c:288'

Hi.

This could be related to others ICEs with structured bindings, but the thrown
internal compiler error is at a different location and couldn't find anyone
else having hit this particular spot.

Attached a test case. Running it with (pretty much) the latest trunk
(2017-11-09) currently gives:

$ aarch64-none-elf-g++.exe -Wall -Wextra -c --std=gnu++17
ice_is_normal_capture_proxy.cpp
ice_is_normal_capture_proxy.cpp: In lambda function:
ice_is_normal_capture_proxy.cpp:17:8: internal compiler error: in
is_normal_capture_proxy, at cp/lambda.c:288
eat(left);


Any lambda (capturing or not) with an auto typed parameter will fail, if any of
the structured binding result is used. It doesn't matter if the auto typed
argument is actually used or, or whether or not the the code at lambda call
site would actually compile, e.g. trying to call the lambda without any
arguments.

The test case compiles just fine, if the auto type is replaced with some other
type, say an int (-DNO_AUTO_ARG).

[Bug c++/70528] [5 Regression] bogus error: constructor required before non-static data member

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
No.

[Bug tree-optimization/82929] New: [8 regression] r254579 causes ICE: tree check: expected ssa_name, have array_ref in has_single_use, at ssa-iterators.h:400

[trippels at gcc dot gnu.org]

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

Bug ID: 82929
   Summary: [8 regression] r254579 causes ICE: tree check:
expected ssa_name, have array_ref in has_single_use,
at ssa-iterators.h:400
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r254579:

trippels@gcc2-power8 llvm_build % cat SubtargetFeature.ii
template  struct A {
  long _M_w[_Nw];
  void m_fn1(A p1) {
for (int a = 0;; a++)
  _M_w[a] &= p1._M_w[a];
  }
  void m_fn2() {
for (int b = 0; b < _Nw; b++)
  _M_w[b] = ~_M_w[b];
  }
};
template  struct C : A<_Nb / (8 * 8)> {
  void operator&=(C p1) { this->m_fn1(p1); }
  C m_fn3() {
this->m_fn2();
return *this;
  }
  C operator~() { return C(*this).m_fn3(); }
};
struct B {
  C<192> Value;
};
void fn1(C<192> ) {
  B c;
  p1 &= ~c.Value;
}


trippels@gcc2-power8 llvm_build % g++ -O2 -c SubtargetFeature.ii
during GIMPLE pass: store-merging
SubtargetFeature.ii: In function ‘void fn1(C<192>&)’:
SubtargetFeature.ii:23:6: internal compiler error: tree check: expected
ssa_name, have mem_ref in has_single_use, at ssa-iterators.h:400
 void fn1(C<192> ) {
  ^~~
0x1019870b tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9096
0x101ba5a3 tree_check(tree_node const*, char const*, int, char const*,
tree_code)
../../gcc/gcc/tree.h:3344
0x101ba5a3 has_single_use
../../gcc/gcc/ssa-iterators.h:400
0x1151ff1b has_single_use
../../gcc/gcc/gimple-ssa-store-merging.c:1445
0x1151ff1b count_multiple_uses
../../gcc/gcc/gimple-ssa-store-merging.c:1435
0x1152011f split_group
../../gcc/gcc/gimple-ssa-store-merging.c:1509
0x11520ac7 output_merged_store
../../gcc/gcc/gimple-ssa-store-merging.c:1719
0x11523707 output_merged_stores
../../gcc/gcc/gimple-ssa-store-merging.c:2055
0x11523707 terminate_and_process_chain
../../gcc/gcc/gimple-ssa-store-merging.c:2093
0x11523707 terminate_and_release_chain
../../gcc/gcc/gimple-ssa-store-merging.c:991
0x11523f47 terminate_and_process_all_chains
../../gcc/gcc/gimple-ssa-store-merging.c:928
0x1152451f execute
../../gcc/gcc/gimple-ssa-store-merging.c:2504

[Bug middle-end/82928] New: glibc test-tgmath3 ICE on powerpc64le

[amodra at gmail dot com]

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

Bug ID: 82928
   Summary: glibc test-tgmath3 ICE on powerpc64le
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

Created attachment 42571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42571=edit
somewhat reduced testcase

Seen with current glibc "make check", gcc 20171109 

during RTL pass: expand
/home/amodra/build/glibc/math/test-tgmath3.c: In function 'test_log10_17':
/home/amodra/build/glibc/math/test-tgmath3.c:150331:23: internal compiler
error: in as_a, at machmode.h:345
   vol_var___CFLOAT128 = log10 (vol_var___CFLOAT128);
0x1050cc0f scalar_mode as_a(machine_mode)
/home/amodra/src/gcc/gcc/machmode.h:345
0x1050cc0f convert_mode_scalar
/home/amodra/src/gcc/gcc/expr.c:280
0x1050cc0f convert_move(rtx_def*, rtx_def*, int)
/home/amodra/src/gcc/gcc/expr.c:271
0x105156c7 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/home/amodra/src/gcc/gcc/expr.c:5631
0x105172c3 expand_assignment(tree_node*, tree_node*, bool)
/home/amodra/src/gcc/gcc/expr.c:5322
0x103879af expand_gimple_stmt_1
/home/amodra/src/gcc/gcc/cfgexpand.c:3675
0x103879af expand_gimple_stmt
/home/amodra/src/gcc/gcc/cfgexpand.c:3773
0x1038ba83 expand_gimple_basic_block
/home/amodra/src/gcc/gcc/cfgexpand.c:5774
0x10391b67 execute
/home/amodra/src/gcc/gcc/cfgexpand.c:6375

gcc -c -O1 -mcpu=power8 to reproduce with attached testcase

[Bug c++/70528] [5 Regression] bogus error: constructor required before non-static data member

[EoD at xmw dot de]

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

EoD  changed:

   What|Removed |Added

 CC||EoD at xmw dot de

--- Comment #20 from EoD  ---
(In reply to Jakub Jelinek from comment #19)
> GCC 5 branch has been closed, should be fixed in GCC 6 and later.

Is this part of GCC 5.5.0?

[Bug target/82927] New: [8 Regression] ICE in verify_flow_info building SH glibc

[jsm28 at gcc dot gnu.org]

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

Bug ID: 82927
   Summary: [8 Regression] ICE in verify_flow_info building SH
glibc
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---
Target: sh4-linux-gnu

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

Given the fix for bug 82863 (checked in although that bug isn't yet closed),
GCC completes the libgcc build but then ICEs building glibc for sh4-linux-gnu. 
My expectation is that this ICE was also introduced by r254379, though I
haven't tested to verify this.  Compile the attached test (not reduced) with
-O2.

gconv_builtin.c: In function '__gconv_get_builtin_trans':
gconv_builtin.c:86:1: error: verify_flow_info: Wrong probability of edge 10->12
gconv_builtin.c:86:1: error: verify_flow_info: Wrong probability of edge 10->11
gconv_builtin.c:86:1: error: verify_flow_info: Wrong probability of edge 6->9
gconv_builtin.c:86:1: error: verify_flow_info: Wrong probability of edge 6->7
during RTL pass: expand
gconv_builtin.c:86:1: internal compiler error: verify_flow_info failed
0x71ba23 verify_flow_info()
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfghooks.c:265
0x10a9ef2 checking_verify_flow_info
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfghooks.h:198
0x10a9ef2 try_optimize_cfg
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfgcleanup.c:3015
0x10aa1fd cleanup_cfg(int)
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfgcleanup.c:3179
0x718815 execute
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfgexpand.c:6511
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/82913] [8 Regression] ICE: Segmentation fault in try_merge_compare

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/82913] [8 Regression] ICE: Segmentation fault in try_merge_compare

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov  9 23:58:51 2017
New Revision: 254614

URL: https://gcc.gnu.org/viewcvs?rev=254614=gcc=rev
Log:
PR rtl-optimization/82913
* compare-elim.c (try_merge_compare): Punt if def_insn is not
single set.

* gcc.c-torture/compile/pr82913.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr82913.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/compare-elim.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/81351] [8 regression] Many LTO testcases FAIL

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
Fixing.

[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute

[eggert at gnu dot org]

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

--- Comment #4 from Paul Eggert  ---
(In reply to Richard Biener from comment #2)

> You are not using aligned on a 'struct or struct member' but on the variable
> in all but (b).

If that's the intent, then GCC is mishandling the first example I gave in
comment #0:

  struct s { char mem; };
  __attribute__ ((aligned (8))) struct s a;
  struct __attribute__ ((aligned (8))) s b;
  struct s __attribute__ ((aligned (8))) c;
  struct s d __attribute__ ((aligned (8)));

Here, GCC says the alignment of 'b' is 1, not 8. What happened to the
attribute?

Later discussion in https://bugs.gnu.org/29183 has revealed that this first
example is also relevant to Emacs, and that Emacs crashes due to problems in
this area as well.

In summary there seems to be no straightforward way in GNU C to get what Emacs
wants, which is to say, "I want V's address to be a multiple of max(8, (natural
alignment for V))." I think I'll look into fixing Emacs to use unions instead.

Could you please fix the GCC documentation to clarify what's going on here? I
don't understand it myself, so I'm afraid any doc patch that I propose wouldc
be wrong.

[Bug target/82926] x86_64 inline assembly with push/pop produces buggy code

[EoD at xmw dot de]

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

--- Comment #3 from EoD  ---
(In reply to Uroš Bizjak from comment #1)
> The testcase violates redzone.
> 
> Either add rsp to the list of clobbered registers, or compile with
> -fno-red-zone.
> 
> OTOH, you should just include  and use __cpuid.

(In reply to Jakub Jelinek from comment #2)
> If it is __x86_64__ only, then the push/pop is totally useless, %rbx is like
> any other reg (for __i386__ too if not pic or when using a recent gcc).
> So just asm ("cpuid" : "=a" (*a), "=b" (*b), "=c" (*c), "=d" (*d) : "0"
> (op));
> Or you could e.g. xchg %%ebx, %%esi and back for __i386__ instead of the
> push/pop, or, if for whatever weird reason you don't want to clobber %rbx
> for __x86_64__, you could e.g. subtract the red zone size from %rsp first,
> then push and after poping add back.

Thanks for your fast replies! I have forwarded the issues to the pulseaudio
team: https://bugs.freedesktop.org/show_bug.cgi?id=103656

[Bug target/82926] x86_64 inline assembly with push/pop produces buggy code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
If it is __x86_64__ only, then the push/pop is totally useless, %rbx is like
any other reg (for __i386__ too if not pic or when using a recent gcc).
So just asm ("cpuid" : "=a" (*a), "=b" (*b), "=c" (*c), "=d" (*d) : "0" (op));
Or you could e.g. xchg %%ebx, %%esi and back for __i386__ instead of the
push/pop, or, if for whatever weird reason you don't want to clobber %rbx for
__x86_64__, you could e.g. subtract the red zone size from %rsp first, then
push and after poping add back.

[Bug fortran/82895] An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
(In reply to Arjen Markus from comment #4)
> It was precisely this sort of issues that led me to write this small sample
> program. And I realised this morning, that indeed the host variables need to
> be avoided.

The OpenMP standard says that host or use associated variables are
shared.  For q, this means that different threads would access this
variable, i.e. you get a data race.

> But does:
> - loop_body accesses the host-associated, non-threadprivate variables q,
>   x, and id, and you get data races
> 
> mean that it is utterly unsafe to access even the shared variables (x and id
> in this case)? That would defy the intentions of using a(n internal) routine
> altogether. I need to have access to the entire array and the pattern of
> iterations avoids data collisions.

For your code and for your iteration pattern (different threads will use
different j ranges), you could declare q in the main as threadprivate,
(now gfortran-7 complains that it should be save'd), and you should pass
the private variables i and j to your worker subroutine.
Try the following (checked with valgrind):

! chkloop_internal.f90 --
! I want to know:
! - OpenMP-enabled outer loops with a small number of iterations (but a
large body with long loops)
! - Combination with internal routines
!
program chkloop_internal
use omp_lib
implicit none

integer, parameter   :: noelems = 10
real, dimension(:), allocatable  :: x, y, z
integer, dimension(:), allocatable   :: id
integer  :: i, j, noperlayer, nolayers
!$omp threadprivate(q)
real, save   :: q

allocate( x(noelems), y(noelems), z(noelems), id(noelems) )

id = 0
call random_number( x )
call random_number( y )
call random_number( z )

nolayers   = 10
noperlayer = noelems / nolayers

!$omp parallel private(i, j)
!$omp do schedule(dynamic)
do i = 1,nolayers
do j = noperlayer * (i - 1) + 1, noperlayer * i
   call loop_body (i,j)
enddo
enddo
!$omp end do
!$omp end parallel

do i = 1,omp_get_max_threads()
write(*,*) i, count( id == i-1 )
enddo

contains
  subroutine loop_body (i,j)
integer :: i, j
!   real:: q! use local variables if possible
q = z(j)
x(j)  = x(j) + q * y(j)
id(j) = omp_get_thread_num()
write(80+id(j),*) i,j,x(j),y(j),q
  end subroutine loop_body
end program chkloop_internal

[Bug target/82926] x86_64 inline assembly with push/pop produces buggy code

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
The testcase violates redzone.

Either add rsp to the list of clobbered registers, or compile with
-fno-red-zone.

OTOH, you should just include  and use __cpuid.

[Bug middle-end/82333] [8 Regression] powerpc64le _Float128 ICE in as_a, at machmode.h:345

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Note the checkin message in note 2 was for a private branch, that included
other patches that have been submitted.

[Bug middle-end/82333] [8 Regression] powerpc64le _Float128 ICE in as_a, at machmode.h:345

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|target  |middle-end

--- Comment #3 from Michael Meissner  ---
The bug is due to compare_constant thinking two floating point constants are
the same if the floating point size and the internal value are the same.  On
the PowerPC, long double and _Float128 both are 128-bits, but they have
different internal representations.

The bug shows up when you try to inline two functions, one that returns 0
converted to long double _Complex and the other that returns 0 converted to
_Float128 _Complex.

The function compare_constant in varasm.c thinks that these two constants are
the same, and assigns them to the same hash.  When inliner tries to replace the
inline function (that returns 0) with the constant, it does moves of the real
part and the imaginary part.  In the second function, the real/imaginary parts
have type KFmode, while the first function (that has the saved constant) the
real/imaginary parts have type TFmode.

The fix is to consider the type along with the precision when doing hash of the
constants.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[clyon at gcc dot gnu.org]

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

--- Comment #11 from Christophe Lyon  ---
I confirm that charlen_15 now compiles & executes OK for me.

charlen_03 and charlen_10 have been removed, so they no longer fail :-)

[Bug other/82925] New: [8 regression] gcc.dg/tree-ssa/vrp101.c fails starting with r254379

[seurer at gcc dot gnu.org]

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

Bug ID: 82925
   Summary: [8 regression] gcc.dg/tree-ssa/vrp101.c fails starting
with r254379
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am seeing this on both LE and BE powerpc64.

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-ssa/vrp101.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-optimized
-S -o vrp101.s
PASS: gcc.dg/tree-ssa/vrp101.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/vrp101.c scan-tree-dump optimized " \\[[0-9.]+%\\]
\\[count: [0-9INV]*\\]:[\n\r ]*return 0;"
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp
completed in 0 seconds

=== gcc Summary ===

# of expected passes1
# of unexpected failures1

[Bug inline-asm/82926] New: x86_64 inline assembly with push/pop produces buggy code

[EoD at xmw dot de]

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

Bug ID: 82926
   Summary: x86_64 inline assembly with push/pop produces buggy
code
   Product: gcc
   Version: unknown
   URL: https://bugs.freedesktop.org/show_bug.cgi?id=99066
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: EoD at xmw dot de
  Target Milestone: ---

Created attachment 42569
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42569=edit
C++ program showing the issue

Currently, pulseaudio fails compiling with "-O0" due to a crash in its
get_cpuid() function (see URL above for further details).

I attached a simple C++ program to show the issue.


When compiling the program with "-O0" a segfault is caused
  g++ -mx32 -O0 get_cpuid_crash.cpp


When compiling the program with either "-O1" or "-m64", the program does not
segfault:
  g++ -mx32 -O1 get_cpuid_crash.cpp
  g++ -m64 -O0 get_cpuid_crash.cpp

Also using clang does not cause a segfault
  clang++ -mx32 -O0 get_cpuid_crash.cpp


I would also like to quote tanuk from
https://bugs.freedesktop.org/show_bug.cgi?id=99066#c14
> I was asked for more information about the cpuid crash, so here we go:
> 
> This is the code that GCC generates for get_cpuid() on x32:
> 
> 0xf7b6a270   push   %rbp
> 0xf7b6a271 mov%esp,%ebp
> 0xf7b6a273 mov%edi,-0x4(%ebp)
> 0xf7b6a277 mov%rcx,%rax
> 0xf7b6a27a    mov%r8,%rcx
> 0xf7b6a27d    mov%esi,-0x8(%ebp)
> 0xf7b6a281    mov%edx,-0xc(%ebp)
> 0xf7b6a285    mov%eax,-0x10(%ebp)
> 0xf7b6a289    mov%ecx,-0x14(%ebp)
> 0xf7b6a28d    mov-0x4(%ebp),%eax  [breakpoint]
> 0xf7b6a291    push   %rbx
> 0xf7b6a292    cpuid
> 0xf7b6a294    mov%ebx,%esi
> 0xf7b6a296    pop%rbx
> 0xf7b6a297    mov-0x8(%ebp),%edi
> 0xf7b6a29b    mov%eax,(%edi)  [segfault]
> 0xf7b6a29e    mov-0xc(%ebp),%eax
> 0xf7b6a2a2    mov%esi,(%eax)
> 0xf7b6a2a5    mov-0x10(%ebp),%eax
> 0xf7b6a2a9    mov%ecx,(%eax)
> 0xf7b6a2ac    mov-0x14(%ebp),%eax
> 
> "[breakpoint]" marks the place where the execution stops if you set a
> breakpoint with "break get_cpuid". "[segfault]" marks the place where the
> crash happens.
> 
> Before the breakpoint there's the code that copies the function parameters
> to the stack as follows:
> 
> %edi is the "op" parameter. It's saved to -0x4(%ebp).
> %rcx is the "c" parameter. It's moved to %rax and from %rax to -0x10(%ebp).
> %r8 is the "d" parameter. It's moved to %rcx and from %rcx to -0x14(%ebp).
> %esi is the "a" parameter. It's saved to -0x8(%ebp).
> %edx is the "b" parameter. It's saved to -0xc(%ebp).
> 
> The stack pointer is not updated when the parameters are saved to the stack.
> Since the stack pointer points to the beginning of the frame, the push
> instruction overwrites 8 bytes from the beginning of the frame, overwriting
> the "op" and "a" parameters.
> 
> I think the push is done, because the %rbx register is special in that it
> must always have the same value when returning from a function as it had
> when the function started. The cpuid instruction modifies the %rbx register,
> so that's why we need to save and restore the %rbx register.
> 
> After the pop, this happens:
> 
> 0xf7b6a297    mov-0x8(%ebp),%edi
> 
> This reads the stack from the position where the "a" parameter was saved.
> The compiler seems to assume that it has the same value that was written
> there in the beginning of the function, but the push instruction has written
> some random garbage there.
> 
> 0xf7b6a29b    mov%eax,(%edi)  [segfault]
> 
> This is supposed to save the return value (well, one part of the return
> value) of the cpuid instruction to the address stored in %edi, but we just
> wrote garbage to %edi, so we end up dereferencing using garbage as the
> pointer (in my tests the value in %edi was 1).

[Bug c/82919] Docs don't mention -Wimplicit-int is enabled in C99 mode

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-09
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed with the top of trunk (GCC 8.0) back through to GCC 5.4.

$ cat c.c && gcc -S c.c
f (void)
{
  g ();
}
c.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
 f (void)
 ^
c.c: In function ‘f’:
c.c:3:3: warning: implicit declaration of function ‘g’
[-Wimplicit-function-declaration]
   g ();
   ^

[Bug c++/82924] New: gcc gives no warning for comparing unsigned integer < 0 even with -Wextra enabled

[jure.slak at ijs dot si]

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

Bug ID: 82924
   Summary: gcc gives no warning for comparing unsigned integer <
0 even with -Wextra enabled
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jure.slak at ijs dot si
  Target Milestone: ---

Created attachment 42568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42568=edit
Compiling this file with -Wtype-limits should give a warning, but does not.

Take the following code

#include 

template
T f(T x, unsigned y) {
if (y < 0) return x;
return static_cast(0);
}

using namespace std;

int main() {

int a = f(2, 3);
std::cout << a << std::endl;

return 0;
}

where function f clearly always returns 0. Compiling it with g++-7.2.0 -Wall
-Wextra gives no hint about pointless comparison. However, clang warns us
nicely:

a.cpp:7:11: warning: comparison of unsigned expression < 0 is always false
[-Wtautological-compare]
if (y < 0) return x;
~ ^ ~
1 warning generated.

I believe that using -Wtype-limits (part of -Wextra) should warn about this
case, as it does in the non-template version.

[Bug target/82333] [8 Regression] powerpc64le _Float128 ICE in as_a, at machmode.h:345

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Thu Nov  9 20:01:29 2017
New Revision: 254607

URL: https://gcc.gnu.org/viewcvs?rev=254607=gcc=rev
Log:
fix pr 82333

Added:
branches/ibm/ieee/gcc/testsuite/gcc.target/powerpc/pr82333.c
Modified:
branches/ibm/ieee/gcc/ChangeLog.meissner
branches/ibm/ieee/gcc/builtins.c
branches/ibm/ieee/gcc/builtins.def
branches/ibm/ieee/gcc/c/c-decl.c
branches/ibm/ieee/gcc/config/rs6000/rs6000.md
branches/ibm/ieee/gcc/convert.c
branches/ibm/ieee/gcc/fold-const-call.c
branches/ibm/ieee/gcc/fold-const.c
branches/ibm/ieee/gcc/internal-fn.def
branches/ibm/ieee/gcc/testsuite/ChangeLog.meissner
branches/ibm/ieee/gcc/testsuite/gcc.target/powerpc/float128-hw2.c
branches/ibm/ieee/gcc/varasm.c

[Bug fortran/78686] ICE in gfc_apply_init, at fortran/expr.c:4124

[kargl at gcc dot gnu.org]

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

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 #0)
> With invalid code, down to at least 4.8 :
> 
> 
> $ cat z1.f90
> program p
>type t
>   character :: c(1) = [t()]
>end type
> end
> 
> 
> $ gfortran-7-20161204 z1.f90
> f951: internal compiler error: in gfc_apply_init, at fortran/expr.c:4124
> 0x6911be gfc_apply_init(gfc_typespec*, symbol_attribute*, gfc_expr*)
> ../../gcc/fortran/expr.c:4124
> 0x684d98 build_struct
> ../../gcc/fortran/decl.c:1942
> 0x684d98 variable_decl
> ../../gcc/fortran/decl.c:2437
> 0x684d98 gfc_match_data_decl()
> ../../gcc/fortran/decl.c:4892
> 0x6dca79 match_word_omp_simd
> ../../gcc/fortran/parse.c:93
> 0x6e002e match_word
> ../../gcc/fortran/parse.c:377
> 0x6e002e decode_statement
> ../../gcc/fortran/parse.c:377
> 0x6e1e34 next_free
> ../../gcc/fortran/parse.c:1180
> 0x6e1e34 next_statement
> ../../gcc/fortran/parse.c:1413
> 0x6e337a parse_derived
> ../../gcc/fortran/parse.c:3233
> 0x6e337a parse_spec
> ../../gcc/fortran/parse.c:3773
> 0x6e5bb3 parse_progunit
> ../../gcc/fortran/parse.c:5615
> 0x6e71a4 gfc_parse_file()
> ../../gcc/fortran/parse.c:6124
> 0x72b182 gfc_be_parse_file
> ../../gcc/fortran/f95-lang.c:202


With up to date trunk (GNU Fortran (GCC) 8.0.0 20171109),
I see

% gfcx -c a.f90
a.f90:3:31:

   character :: c(1) = [t()]
   1
Error: Derived type 't' at (1) is being used before it is defined

I see the same error for the code in comment #2.  I'll prepare
testcases and commit those later today or tomorrow.

[Bug fortran/78619] [6/7/8 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:889

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Thu Nov  9 19:12:41 2017
New Revision: 254605

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

PR fortran/78619
* check.c (same_type_check): Introduce a new argument 'assoc'
with default value false. If this is true, use the symbol type
spec of BT_PROCEDURE expressions.
(gfc_check_associated): Set 'assoc' true in the call to
'same_type_check'.

2017-11-09  Paul Thomas  

PR fortran/78619
* gfortran.dg/pr78619.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr78619.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails

[andrey.y.guskov at intel dot com]

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

--- Comment #3 from Andrey Guskov  ---
No, the patch you mentioned does not fix the issue.
The output I get is listed here:

.file   "fake.c"
.text
.Ltext0:
.p2align 4,,15
.globl  test_aligned_reading_s2
.type   test_aligned_reading_s2, @function
test_aligned_reading_s2:
.LFB0:
.cfi_startproc
.LVL0:
movb(%rdi), %al
mulb2(%rdi)
ret
.cfi_endproc
.LFE0:
.size   test_aligned_reading_s2, .-test_aligned_reading_s2
.p2align 4,,15
.globl  test_aligned_writing_s2
.type   test_aligned_writing_s2, @function
test_aligned_writing_s2:
.LFB1:
.cfi_startproc
.LVL1:
movb$5, (%rdi)
movb$7, 2(%rdi)
jmp test_aligned_reading_s2@PLT
.LVL2:
.cfi_endproc
.LFE1:
.size   test_aligned_writing_s2, .-test_aligned_writing_s2
.p2align 4,,15
.globl  test_aligned_reading_s4
.type   test_aligned_reading_s4, @function

[Bug fortran/78814] ICE in symbol_rank, at fortran/interface.c:1265

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Nov  9 18:45:29 2017
New Revision: 254604

URL: https://gcc.gnu.org/viewcvs?rev=254604=gcc=rev
Log:
2017-11-09  Steven G. Kargl  

PR fortran/78814
* interface.c (symbol_rank): Check for NULL pointer.

2017-11-09  Steven G. Kargl  

PR fortran/78814
* gfortran.dg/interface_40.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/interface_40.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81685] FAIL: g++.dg/debug/dwarf2/inline-ns-2.C -std=gnu++* (internal compiler error) on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Still present at revision r254598.

[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

[Bug fortran/82923] Automatic allocation of deferred length character using function result

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (8.0). Note that if the compiler is configured
with --enable-checking=yes, I get

pr82923.f90:11:0:

 program testca

Error: Local declaration from a different function
..__result
pr82923.f90:27:0:

 mine = getchars(2,4)

note: in statement
.mine = ..__result;
pr82923.f90:11:0:

 program testca

Error: Local declaration from a different function
..__result
pr82923.f90:27:0:

 mine = getchars(2,4)

note: in statement
_101 = (integer(kind=8)) ..__result;
pr82923.f90:11:0:

 program testca

Error: Local declaration from a different function
..__result
pr82923.f90:27:0:

 mine = getchars(2,4)

note: in statement
D.3753 = (sizetype) ..__result;
during GIMPLE pass: cfg
pr82923.f90:11:0:

 program testca

internal compiler error: verify_gimple failed

instead of

during RTL pass: expand
pr82923.f90:27:0:

 mine = getchars(2,4)

internal compiler error: in expand_expr_real_1, at expr.c:9865

for 5.5.0 to 8.0 and

pr82923.f90:27:0: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:1741
 mine = getchars(2,4)
 ^
for 4.8 and 4.9.

No duplicate in store.

[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dominiq at lps dot ens.fr

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

[Bug sanitizer/82921] libsanitizer build failure on darwin10 (Snow Leopard) due to missing VM_MEMORY_OS_ALLOC_ONCE

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
dup.

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

[Bug ipa/82903] [8 regression] gcc.dg/tree-prof/20050826-2.c fail

[sudi.das at arm dot com]

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

--- Comment #3 from Sudakshina Das  ---
Confirmed on aarch64-none-linux-gnu and arm-none-linux-gnueabihf

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to Uroš Bizjak from comment #12)
> 
> > --cut here--
> > struct s { char a; char b; char c; char d; };
> > 
> > void foo (struct s *__restrict a, struct s *__restrict b)
> > {
> >   a->a = b->a;
> >   a->b = b->b;
> >   a->c = ~b->c;
> >   a->d = b->d;
> > }
> > --cut here--
> > 
> > This testcase can be optimized by inserting xorl mask between load and
> > store, as suggested above.
> 
> Also,
> 
> a->a = 0;
> a->b = 0;
> a->c = b->c;
> a->d = 0;
> 
> could use andl mask, and similar
> 
> a->a = 0xff;
> a->b = 0xff;
> a->c = b->c;
> a->d = 0xff;
> 
> could use orl mask.

I'm not entirely sure if we can do this last thing, because the original just
reads from b->c, if b->d or b->{a,b} could trap while b->c doesn't (such as for
the 32-bit load not being aligned).  At least for the BIT_NOT_EXPR vs. missing
BIT_NOT_EXPR cases with some effort supporting it wouldn't be that difficult,
we'd need to replace the optional BIT_NOT_EXPR with BIT_XOR_EXPR computed
bitmasks based on what stores have them and what don't (in any of the 3 spots
with bit_not_p).
Trying to support something else, like
a->a = b->a | 123;
a->b = b->b & 12;
a->c = b->c ^ 14;
would be harder, but in theory possible.
In any case, none of this needs the bswap infrastructure, while some of the
earlier testcases do need.

[Bug fortran/82923] New: Automatic allocation of deferred length character using function result

[werner.blokbuster at gmail dot com]

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

Bug ID: 82923
   Summary: Automatic allocation of deferred length character
using function result
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: werner.blokbuster at gmail dot com
  Target Milestone: ---

I can't believe that this isn't a duplicate although I can't find it. The
following code gives an ICE for me on gfortran 7.2, if the line
mine=getchars(2,4) is included:


module m
implicit none
contains
function getchars(my_len,my_size)
integer, intent(in) :: my_len, my_size
character(my_len) :: getchars(my_size)
getchars = 'A-'
end function getchars
end module m

program testca

use m, only: getchars
implicit none
character(:), allocatable :: mine(:)

! this works:
write(*,*) getchars(2,4)
write(*,*) len(getchars(2,4))
write(*,*) size(getchars(2,4))

! this works:
mine = [character(2) :: 'A-','A-']
write(*,*) mine

! ICE occurs if this line is included:
mine = getchars(2,4)

end program testca

WB

[Bug c/82922] New: Request: add -Wstrict-prototypes to -Wextra as K style is obsolescent

[antox at ml dot lv]

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

Bug ID: 82922
   Summary: Request: add -Wstrict-prototypes to -Wextra as K
style is obsolescent
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antox at ml dot lv
  Target Milestone: ---

K style function declarations and definitions are marked obsolescent (C89
3.9.4,5, C99 6.11.6,7, C11 6.11.6,7). Maybe it is reasonable to include
-Wstrict-prototypes in -Wextra (before it becomes appropriate in -Wall)?

K style still can be encountered in the wild and, to someone uninitiated, may
appear like a less cluttered alternative. gcc-5.3.0 -Wall -Wextra compiles the
following code without warning about missing prototype and unchecked arguments:

double f(t, x, y)
double t, x, y;
{ }
int main(void) {
//f(0.0, 1.0, 1.0);
f(0, 1, 1);  // UB
}

Unprototyped functions can be diagnosed by combining
-Wimplicit-function-declaration and -Wstrict-prototypes. The former is in -Wall
and imposed since C99.

-Wold-style-definition cases are covered by -Wstrict-prototypes too.

-Wold-style-declaration (obsolescent: C89 3.9.3, C99 6.11.5, C11 6.11.5) is
included in -Wextra.

There has been a bit of discussion on gcc-help:
https://gcc.gnu.org/ml/gcc-help/2017-11/msg1.html

[Bug sanitizer/82921] New: libsanitizer build failure on darwin10 (Snow Leopard) due to missing VM_MEMORY_OS_ALLOC_ONCE

[dominiq at lps dot ens.fr]

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

Bug ID: 82921
   Summary: libsanitizer build failure on darwin10 (Snow Leopard)
due to missing VM_MEMORY_OS_ALLOC_ONCE
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Bootstrapping gcc on darwin10 fails with

libtool: compile:  /opt/gcc/build_w/./gcc/xgcc -shared-libgcc
-B/opt/gcc/build_w/./gcc -nostdinc++
-L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/gcc8w/x86_64-apple-darwin10.8.0/bin/
-B/opt/gcc/gcc8w/x86_64-apple-darwin10.8.0/lib/ -isystem
/opt/gcc/gcc8w/x86_64-apple-darwin10.8.0/include -isystem
/opt/gcc/gcc8w/x86_64-apple-darwin10.8.0/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.
-I../../../../work/libsanitizer/lsan -I.. -I
../../../../work/libsanitizer/include -I ../../../../work/libsanitizer -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I../../../../work/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O2
-MT lsan_common_mac.lo -MD -MP -MF .deps/lsan_common_mac.Tpo -c
../../../../work/libsanitizer/lsan/lsan_common_mac.cc  -fno-common -DPIC -o
.libs/lsan_common_mac.o
In file included from
../../../../work/libsanitizer/sanitizer_common/sanitizer_allocator.h:15:0,
 from ../../../../work/libsanitizer/lsan/lsan_common.h:16,
 from ../../../../work/libsanitizer/lsan/lsan_common_mac.cc:14:
../../../../work/libsanitizer/lsan/lsan_common_mac.cc: In function 'void
__lsan::ProcessGlobalRegions(__lsan::Frontier*)':
../../../../work/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:307:33:
warning: division 'sizeof (const char*) / sizeof (const char)' does not compute
the number of array elements [-Wsizeof-pointer-div]
 #define ARRAY_SIZE(a) (sizeof(a)/sizeof((a)[0]))
~^~~
../../../../work/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:264:46:
note: in definition of macro 'CHECK_IMPL'
 __sanitizer::u64 v1 = (__sanitizer::u64)(c1); \
  ^~
../../../../work/libsanitizer/lsan/lsan_common_mac.cc:110:38: note: in
expansion of macro 'CHECK'
   for (auto name : kSkippedSecNames) CHECK(ARRAY_SIZE(name) < kMaxSegName);
  ^
../../../../work/libsanitizer/lsan/lsan_common_mac.cc:110:44: note: in
expansion of macro 'ARRAY_SIZE'
   for (auto name : kSkippedSecNames) CHECK(ARRAY_SIZE(name) < kMaxSegName);
^~
../../../../work/libsanitizer/lsan/lsan_common_mac.cc:110:13: note: first
'sizeof' operand was declared here
   for (auto name : kSkippedSecNames) CHECK(ARRAY_SIZE(name) < kMaxSegName);
 ^~~~
../../../../work/libsanitizer/lsan/lsan_common_mac.cc: In function 'void
__lsan::ProcessPlatformSpecificAllocations(__lsan::Frontier*)':
../../../../work/libsanitizer/lsan/lsan_common_mac.cc:158:26: error:
'VM_MEMORY_OS_ALLOC_ONCE' was not declared in this scope
 if (info.user_tag == VM_MEMORY_OS_ALLOC_ONCE) {
  ^~~
../../../../work/libsanitizer/lsan/lsan_common_mac.cc:158:26: note: suggested
alternative: 'VM_MEMORY_MALLOC_HUGE'
 if (info.user_tag == VM_MEMORY_OS_ALLOC_ONCE) {
  ^~~
  VM_MEMORY_MALLOC_HUGE
make[4]: *** [lsan_common_mac.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libsanitizer] Error 2
make: *** [all] Error 2

Last revision bootstrapped is r253320, r254168 failed.

This could be a duplicate of/related to pr82829.

[Bug testsuite/82920] New: cet test failures on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 82920
   Summary: cet test failures on darwin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: hjl at gcc dot gnu.org, iains at gcc dot gnu.org
  Target Milestone: ---

The following tests are failing on x86_64-apple-darwin16 with both -m32 and
-m64:

FAIL: g++.dg/cet-notrack-1.C  -std=gnu++11  scan-assembler-times \\tcall[
\\t]+puts 2 (found 0 times)
FAIL: g++.dg/cet-notrack-1.C  -std=gnu++14  scan-assembler-times \\tcall[
\\t]+puts 2 (found 0 times)
FAIL: g++.dg/cet-notrack-1.C  -std=gnu++98  scan-assembler-times \\tcall[
\\t]+puts 2 (found 0 times)
FAIL: gcc.target/i386/cet-notrack-icf-1.c scan-assembler set[ \\t]+fn2,fn1
FAIL: gcc.target/i386/cet-notrack-icf-1.c scan-assembler set[ \\t]+fn3,fn1
FAIL: gcc.target/i386/cet-notrack-icf-2.c scan-assembler set[ \\t]+fn2,fn1
FAIL: gcc.target/i386/cet-notrack-icf-3.c scan-assembler set[ \\t]+fn2,fn1
FAIL: gcc.target/i386/cet-notrack-icf-3.c scan-assembler set[ \\t]+fn3,fn1
FAIL: gcc.target/i386/cet-notrack-icf-4.c scan-assembler set[ \\t]+fn3,fn1
FAIL: gcc.target/i386/cet-sjlj-3.c scan-assembler-times call\\tlongjmp 1 (found
0 times)
FAIL: gcc.target/i386/cet-sjlj-5.c scan-assembler-times call\\tlongjmp 1 (found
0 times)

In addition the following tests fail with -m32:

FAIL: gcc.target/i386/cet-notrack-5a.c scan-assembler-not \\tcall[ \\t]+
FAIL: gcc.target/i386/cet-notrack-5b.c scan-assembler-times \\tcall[ \\t]+ 1
(found 2 times)
FAIL: gcc.target/i386/cet-notrack-6b.c scan-assembler-not \\tcall[ \\t]+

The following patch fixes the corresponding tests, but I have no idea about
what to do with the others:

--- ../_clean/gcc/testsuite/g++.dg/cet-notrack-1.C  2017-10-26
07:16:20.0 +0200
+++ gcc/testsuite/g++.dg/cet-notrack-1.C2017-11-08 23:51:55.0
+0100
@@ -1,7 +1,7 @@
 /* { dg-do compile { target i?86-*-* x86_64-*-* } } */
 /* { dg-options "-fcf-protection -mcet" } */
 /* { dg-final { scan-assembler "endbr32|endbr64" } } */
-/* { dg-final { scan-assembler-times "\tcall\[ \t]+puts" 2 } } */
+/* { dg-final { scan-assembler-times "\tcall\[ \t]+_?puts" 2 } } */
 /* { dg-final { scan-assembler-times "notrack call\[ \t]+" 1 } } */
 #include 
--- ../_clean/gcc/testsuite/gcc.target/i386/cet-sjlj-3.c2017-10-26
07:16:18.0 +0200
+++ gcc/testsuite/gcc.target/i386/cet-sjlj-3.c  2017-11-08 23:55:15.0
+0100
@@ -3,7 +3,7 @@
 /* { dg-final { scan-assembler-times "endbr32" 4 { target ia32 } } } */
 /* { dg-final { scan-assembler-times "endbr64" 4 { target { ! ia32 } } } } */
 /* { dg-final { scan-assembler-times "call _?setjmp" 1 } } */
-/* { dg-final { scan-assembler-times "call longjmp" 1 } } */
+/* { dg-final { scan-assembler-times "call _?longjmp" 1 } } */

 #include 
 #include 
--- ../_clean/gcc/testsuite/gcc.target/i386/cet-sjlj-5.c2017-10-26
07:16:18.0 +0200
+++ gcc/testsuite/gcc.target/i386/cet-sjlj-5.c  2017-11-08 23:55:30.0
+0100
@@ -3,7 +3,7 @@
 /* { dg-final { scan-assembler-times "endbr32" 2 { target ia32 } } } */
 /* { dg-final { scan-assembler-times "endbr64" 2 { target { ! ia32 } } } } */
 /* { dg-final { scan-assembler-times "call _?setjmp" 1 } } */
-/* { dg-final { scan-assembler-times "call longjmp" 1 } } */
+/* { dg-final { scan-assembler-times "call _?longjmp" 1 } } */

 #include 
 #include 

[Bug c/82919] New: Docs don't mention -Wimplicit-int is enabled in C99 mode

[antox at ml dot lv]

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

Bug ID: 82919
   Summary: Docs don't mention -Wimplicit-int is enabled in C99
mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antox at ml dot lv
  Target Milestone: ---

-Wimplicit-int is enabled by default in C99 mode (or later) just like
-Wimplicit-function-declaration. This is not documented (e.g.
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Warning-Options.html):


-Wimplicit-int (C and Objective-C only)

Warn when a declaration does not specify a type. This warning is enabled by
-Wall.

-Wimplicit-function-declaration (C and Objective-C only)

Give a warning whenever a function is used before being declared. In C99
mode (-std=c99 or -std=gnu99), this warning is enabled by default and it is
made into an error by -pedantic-errors. This warning is also enabled by -Wall.

-Wimplicit (C and Objective-C only)
Same as -Wimplicit-int and -Wimplicit-function-declaration.  This warning
is enabled by -Wall.

[Bug middle-end/82918] New: No aliasing is possible on non equal pointers

[antoshkka at gmail dot com]

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

Bug ID: 82918
   Summary: No aliasing is possible on non equal pointers
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: alias, missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Following code 

struct array {
int data[3];
};

void foo2(array& value, const array& value2) {
if ( == ) return;
value.data[0] = value2.data[0];
value.data[1] = value2.data[0];
value.data[2] = value2.data[0];
}

produces the following assembly:

foo2(array&, array const&):
cmp rdi, rsi
je  .L1
mov eax, DWORD PTR [rsi]
mov DWORD PTR [rdi], eax
mov eax, DWORD PTR [rsi]   <=== This is not required
mov DWORD PTR [rdi+4], eax
mov DWORD PTR [rdi+8], eax
.L1:
rep ret

GCC already understands that value.data[1] and value.data[2] do not alias with
value2.data[0].

However GCC assumes that value1.data[0] may alias value2.data[0], which is not
possible, because of `if ( == ) return;`

Please add the optimization, as it affects many cases, especially C++ assign
and move assign operators, where checking for `this == ` is a common
pattern.

[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
What the code does is when seeing the MEM[(struct et_occ *)p_3].of = node_5(D);
store, we go through all current chains (there is exactly one at that point)
and for each chain through all their stmts and do:
961   if (ref_maybe_used_by_stmt_p (stmt, gimple_assign_lhs
(info->stmt))
962   || stmt_may_clobber_ref_p (stmt, gimple_assign_lhs
(info->stmt)))

stmt here is MEM[(struct et_occ *)p_3].of = node_5(D); and info->stmt is
p_3->next = 0B;
And because both of these functions return false, we think there can't be any
aliasing.
We want to make sure that if there are any (valid) uses of the memory set by
the info->stmt store, or if we are overwriting any part of the info->stmt lhs
memory in stmt that we terminate the chain.

Are these functions not the right alias functions to call?

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #12)

> --cut here--
> struct s { char a; char b; char c; char d; };
> 
> void foo (struct s *__restrict a, struct s *__restrict b)
> {
>   a->a = b->a;
>   a->b = b->b;
>   a->c = ~b->c;
>   a->d = b->d;
> }
> --cut here--
> 
> This testcase can be optimized by inserting xorl mask between load and
> store, as suggested above.

Also,

a->a = 0;
a->b = 0;
a->c = b->c;
a->d = 0;

could use andl mask, and similar

a->a = 0xff;
a->b = 0xff;
a->c = b->c;
a->d = 0xff;

could use orl mask.

[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
So, reduced testcase for -O2 -fno-tree-dse is like:
struct allocation_pool_list
{
  struct allocation_pool_list *next;
};
struct et_node;
struct et_occ
{
  struct et_node *of;
  struct et_occ *parent, *prev, *next;
  int depth;
  int min;
  struct et_occ *min_occ;
};

struct et_occ *
et_new_occ (struct et_node *node)
{
  struct allocation_pool_list *p = __builtin_malloc (sizeof (struct et_occ));
  p->next = 0;
  struct et_occ *nw = (struct et_occ *)(void *)p;
  nw->of = node;
  nw->parent = 0;
  nw->prev = 0;
  nw->next = 0;
  nw->depth = 0;
  nw->min_occ = nw;
  nw->min = 0;
  return nw;
}

(the original has some inlined functions and operator new).
And the problem is that r254536 aliasing changes for some reason allow this to
be optimized as:
   p_3 = __builtin_malloc (48);
-  p_3->next = 0B;
   MEM[(struct et_occ *)p_3].of = node_5(D);
+  MEM[(struct et_occ *)p_3].min_occ = p_3;
+  p_3->next = 0B;
   MEM[(struct et_occ *)p_3].parent = 0B;
   MEM[(struct et_occ *)p_3].prev = 0B;
   MEM[(struct et_occ *)p_3].next = 0B;
-  MEM[(struct et_occ *)p_3].depth = 0;
-  MEM[(struct et_occ *)p_3].min_occ = p_3;
-  MEM[(struct et_occ *)p_3].min = 0;
+  MEM[(int *)p_3 + 32B] = 0;
which is wrong, because the p_3->next store is at the same offset/size (i.e.
must alias) as MEM[(struct et_occ *)p_3].of and by moving p_3->next = 0B;
after it the of field will not be whatever has been passed, but NULL instead.

[Bug libstdc++/82917] [8 regression] 27_io/basic_{f,if,of}stream/open/char/path.cc fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-09
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

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

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[felipe at expertisesolutions dot com.br]

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

--- Comment #8 from Felipe Magno de Almeida  ---
With GCC 7.2.0 I'm still not seeing the same results as you are. The following
is the assembly result, using the same .cpp file and the same command line:

.section.text._Z3abcv,"ax",@progbits
.global _Z3abcv
.type   _Z3abcv, @function
_Z3abcv:
push r28 ;   ;  52  pushqi1/1   [length = 1]
push r29 ;   ;  53  pushqi1/1   [length = 1]
in r28,__SP_L__  ;   ;  54  *movhi/8[length = 2]
in r29,__SP_H__  ; 
sbiw r28,15  ; , ;  55  *addhi3/3   [length = 1]
in __tmp_reg__,__SREG__  ;  56  movhi_sp_r/3[length = 5]
cli
out __SP_H__,r29 ; ,
out __SREG__,__tmp_reg__
out __SP_L__,r28 ; ,
/* prologue: function */
/* frame size = 15 */
/* stack size = 17 */
.L__stack_usage = 17
ldi r24,lo8(32)  ;  D.1843,  ;  6   movqi_insn/2[length = 1]
 ;  test.cpp:19:   seq(L l, R r) : l(l), r(r) {}
std Y+7,__zero_reg__ ;  D.2011.l,;  37  movqi_insn/3[length
= 1]
ldi r25,lo8(97)  ;  D.1843,  ;  42  movqi_insn/2[length = 1]
std Y+8,r25  ;  D.2011.l, D.1843 ;  38  movqi_insn/3[length
= 1]
std Y+9,r24  ;  D.2011.l, D.1843 ;  39  movqi_insn/3[length
= 1]
 ;  test.cpp:25:   return { l, r};
std Y+10,r24 ;  MEM[(struct seq *) + 4B], D.1843  ;  14 
movqi_insn/3[length = 1]
ldi r24,lo8(5)   ;  tmp47,   ;  15  movqi_insn/2[length = 1]
movw r30,r28 ; , ;  45  *movhi/1[length = 1]
adiw r30,6   ; , ;  16  *addhi3/3   [length = 1]
movw r26,r28 ; , ;  46  *movhi/1[length = 1]
adiw r26,1   ; , ;  17  *addhi3/3   [length = 1]
0:   ;  18  movmem_qi   [length = 4]
ld r0,Z+ ; 
st X+,r0 ; 
dec r24  ;  tmp47
brne 0b
ldi r24,lo8(5)   ;  tmp48,   ;  19  movqi_insn/2[length = 1]
movw r30,r28 ; , ;  47  *movhi/1[length = 1]
adiw r30,1   ; , ;  20  *addhi3/3   [length = 1]
movw r26,r28 ; , ;  48  *movhi/1[length = 1]
adiw r26,6   ; , ;  21  *addhi3/3   [length = 1]
0:   ;  22  movmem_qi   [length = 4]
ld r0,Z+ ; 
st X+,r0 ; 
dec r24  ;  tmp48
brne 0b
 ;  test.cpp:35:  )
ldi r24,lo8(5)   ;  tmp49,   ;  23  movqi_insn/2[length = 1]
movw r30,r28 ; , ;  49  *movhi/1[length = 1]
adiw r30,6   ; , ;  24  *addhi3/3   [length = 1]
movw r26,r28 ; , ;  50  *movhi/1[length = 1]
adiw r26,11  ; , ;  25  *addhi3/3   [length = 1]
0:   ;  26  movmem_qi   [length = 4]
ld r0,Z+ ; 
st X+,r0 ; 
dec r24  ;  tmp49
brne 0b
 ;  test.cpp:37:foo(rule);
movw r24,r28 ; , ;  51  *movhi/1[length = 1]
adiw r24,11  ; , ;  28  addhi3_clobber/1[length = 1]
call _Z3fooI3seqIS0_I1AS1_ES1_EEvRT_ ;   ;  29  call_insn/2
[length = 2]
/* epilogue start */
 ;  test.cpp:38: }
adiw r28,15  ; , ;  59  *addhi3/3   [length = 1]
in __tmp_reg__,__SREG__  ;  60  movhi_sp_r/3[length = 5]
cli
out __SP_H__,r29 ; ,
out __SREG__,__tmp_reg__
out __SP_L__,r28 ; ,
pop r29  ;   ;  61  popqi   [length = 1]
pop r28  ;   ;  62  popqi   [length = 1]
ret  ;  63  return_from_epilogue[length = 1]
.size   _Z3abcv, .-_Z3abcv
.ident  "GCC: (GNU) 7.2.0"

And this is the result if seq no longer inherits from seq_base (which is an
empty class):

.section.text._Z3abcv,"ax",@progbits
.global _Z3abcv
.type   _Z3abcv, @function
_Z3abcv:
push r28 ;   ;  19  pushqi1/1   [length = 1]
push r29 ;   ;  20  pushqi1/1   [length = 1]
 ; SP -= 3   ;   ;  24  *addhi3_sp  [length = 1]
rcall .
in r28,__SP_L__  ;   ;  25  *movhi/8[length = 2]
in r29,__SP_H__  ; 
/* prologue: function */
/* frame size = 3 */
/* stack size = 5 */
.L__stack_usage = 5
 ;  test.cpp:35:  )
ldi r24,lo8(97)  ;  tmp42,   ;  5   movqi_insn/2[length = 1]
std Y+1,r24  ;  MEM[(struct seq *)], tmp42  ;  6  
movqi_insn/3[length = 1]
ldi r24,lo8(32)  ;  tmp43,   ;  7   movqi_insn/2[length = 1]
std Y+2,r24  ;  MEM[(struct seq *) + 1B], tmp43 ;  8  
movqi_insn/3[length = 1]
std Y+3,r24  ;  MEM[(struct seq *) + 2B], tmp43 ;  10 
movqi_insn/3[length = 1]
 ;  

[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Seems it is et-forest.o that matters, and compiling it with -fno-store-merging
makes the ICE go away.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

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

--- Comment #12 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to rguent...@suse.de from comment #6)
> 
> > > In addition to a merge opportunity, there is a redundant move [*], that 
> > > results
> > > in redundant operation [**]. The whole function could be just:
> > > 
> > > movw%dx, -4(%rdi,%rsi)
> > > notl%edx
> > > movw%dx, -2(%rdi,%rsi)
> > 
> > or
> > 
> >   xorl$0x, %edx
> >   movl%edx, -4(%rdi,%rsi)
> > 
> > ?
> 
> Yes, even this. It looks that store merging opens many optimization
> opportunities.

Actually, the testcase stores the same word (one inverted) to two different
locations. But following testcase:

--cut here--
struct s { char a; char b; char c; char d; };

void foo (struct s *__restrict a, struct s *__restrict b)
{
  a->a = b->a;
  a->b = b->b;
  a->c = ~b->c;
  a->d = b->d;
}
--cut here--

This testcase can be optimized by inserting xorl mask between load and store,
as suggested above.

[Bug ipa/82879] [8 regression] ICE in max, at profile-count.h:889

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||hubicka at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jan Hubicka  ---
Fixed.

[Bug ipa/82879] [8 regression] ICE in max, at profile-count.h:889

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Author: hubicka
Date: Thu Nov  9 14:05:14 2017
New Revision: 254582

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

PR ipa/82879
* ipa-inline-transform.c (update_noncloned_frequencies): Use
profile_count::adjust_for_ipa_scaling.
* tree-inline.c (copy_bb, copy_cfg_body): Likewise.
* profile-count.c (profile_count::adjust_for_ipa_scaling): New member
function.
* profile-count.h (profile_count::adjust_for_ipa_scaling): Declare.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr82879.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-transform.c
trunk/gcc/profile-count.c
trunk/gcc/profile-count.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug libstdc++/82917] New: [8 regression] 27_io/basic_{f,if,of}stream/open/char/path.cc fails

[andrey.y.guskov at intel dot com]

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

Bug ID: 82917
   Summary: [8 regression]
27_io/basic_{f,if,of}stream/open/char/path.cc fails
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r254437 triggers these 3 fails:

spawn -ignore SIGHUP /work/./gcc/xg++ -shared-libgcc -B/work/./gcc -nostdinc++
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/install/x86_64-pc-linux-gnu/bin/ -B/install/x86_64-pc-linux-gnu/lib/
-isystem /install/x86_64-pc-linux-gnu/include -isystem
/install/x86_64-pc-linux-gnu/sys-include
-B/work/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0
-fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE
-DLOCALEDIR="." -nostdinc++
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/source/libstdc++-v3/libsupc++ -I/source/libstdc++-v3/include/backward
-I/source/libstdc++-v3/testsuite/util
/source/libstdc++-v3/testsuite/27_io/basic_fstream/open/char/path.cc
-std=gnu++17 -lstdc++fs -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a -Wl,--gc-sections
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o ./path.exe
PASS: 27_io/basic_fstream/open/char/path.cc (test for excess errors)
FAIL: 27_io/basic_fstream/open/char/path.cc execution test

---
spawn -ignore SIGHUP /work/./gcc/xg++ -shared-libgcc -B/work/./gcc -nostdinc++
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/install/x86_64-pc-linux-gnu/bin/ -B/install/x86_64-pc-linux-gnu/lib/
-isystem /install/x86_64-pc-linux-gnu/include -isystem
/install/x86_64-pc-linux-gnu/sys-include
-B/work/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0
-fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE
-DLOCALEDIR="." -nostdinc++
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/source/libstdc++-v3/libsupc++ -I/source/libstdc++-v3/include/backward
-I/source/libstdc++-v3/testsuite/util
/source/libstdc++-v3/testsuite/27_io/basic_ifstream/open/char/path.cc
-std=gnu++17 -lstdc++fs -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a -Wl,--gc-sections
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o ./path.exe
PASS: 27_io/basic_ifstream/open/char/path.cc (test for excess errors)
FAIL: 27_io/basic_ifstream/open/char/path.cc execution test

---
spawn -ignore SIGHUP /work/./gcc/xg++ -shared-libgcc -B/work/./gcc -nostdinc++
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/install/x86_64-pc-linux-gnu/bin/ -B/install/x86_64-pc-linux-gnu/lib/
-isystem /install/x86_64-pc-linux-gnu/include -isystem
/install/x86_64-pc-linux-gnu/sys-include
-B/work/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0
-fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE
-DLOCALEDIR="." -nostdinc++
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/source/libstdc++-v3/libsupc++ -I/source/libstdc++-v3/include/backward
-I/source/libstdc++-v3/testsuite/util
/source/libstdc++-v3/testsuite/27_io/basic_ofstream/open/char/path.cc
-std=gnu++17 -lstdc++fs -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a -Wl,--gc-sections
-L/work/x86_64-pc-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o ./path.exe
PASS: 27_io/basic_ofstream/open/char/path.cc (test for excess errors)
FAIL: 27_io/basic_ofstream/open/char/path.cc execution test


Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm

[Bug ada/82844] [8 Regression] Many ada tests time out on x32

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Pierre-Marie de Rodat from comment #9)
> I’ve setup an Ubuntu VM, installed libx32 runtime libraries and built with
> “--with-multilib-list=m32,m64,mx32” + ran the testsuite (“make -C gcc -j8 -k
> check-ada”), without reproducing the issues you describe. Is there something
> obvious missing?

I used

CC="gcc -mx32 -fno-lto" CXX="g++ -mx32 -fno-lto"
RUNTESTFLAGS="--target_board='unix{-m64,-m32,}'"
/export/gnu/import/git/sources/gcc/configure --with-demangler-in-ld
--enable-languages=c,c++,fortran,lto,objc,ada,obj-c++,go 
--prefix=/usr/gcc-8.0.0-mx32 --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib
--enable-checking=yes,rtl --enable-libmpx --with-multilib-list=m32,m64,mx32
--enable-linker-build-id --enable-gnu-unique-object --with-abi=mx32
--with-fpmath=sse

--with-abi=mx32 will bootstrap GCC in x32.  You need to make sure that
linker in x32 is your PATH.  I have

[hjl@gnu-4 kernel]$ file /usr/localx32/bin/ld
/usr/localx32/bin/ld: ELF 32-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0,
BuildID[sha1]=bd1d06d57ab8d91756c97b170430590bac9253ea, with debug_info, not
stripped
[hjl@gnu-4 kernel]$

[Bug tree-optimization/82902] [7 Regression] ICE verify_ssa failed during GIMPLE pass: phiprop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||8.0
   Target Milestone|8.0 |7.3
Summary|[8 Regression] ICE  |[7 Regression] ICE
   |verify_ssa failed during|verify_ssa failed during
   |GIMPLE pass: phiprop|GIMPLE pass: phiprop

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar - the issue is latent I think, so I'll backport.

[Bug tree-optimization/82902] [8 Regression] ICE verify_ssa failed during GIMPLE pass: phiprop

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Nov  9 12:22:32 2017
New Revision: 254575

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

PR tree-optimization/82902
* tree-ssa-phiprop.c (propagate_with_phi): Test proper type.

* g++.dg/torture/pr82902.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr82902.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiprop.c

[Bug target/82863] [8 Regression] ICE in verify_flow_info building SH libgcc

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Nov  9 12:19:02 2017
New Revision: 254574

URL: https://gcc.gnu.org/viewcvs?rev=254574=gcc=rev
Log:
Initialize split_branch_probability (PR target/82863).

2017-11-09  Martin Liska  

PR target/82863
* emit-rtl.c (init_emit_regs): Initialize split_branch_probability to
uninitialized.
2017-11-09  Martin Liska  

PR target/82863
* gcc.dg/pr82863.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr82863.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
../gcc/configure --disable-libstdcxx-pch --disable-libvtv --disable-libitm
--disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror
--disable-multilib --enable-languages=c,c++,fortran --enable-checking=release

make -j8 BOOT_CFLAGS="-Wno-error=coverage-mismatch -march=native -O3 -pipe"
STAGE1_CFLAGS="-Wno-error=coverage-mismatch -march=native -O3 -pipe"
CFLAGS_FOR_TARGET="-Wno-error=coverage-mismatch -march=native -O3 -pipe"
CXXFLAGS_FOR_TARGET="-Wno-error=coverage-mismatch -march=native -O3 -pipe"
profiledbootstrap

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

[rguenther at suse dot de]

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

--- Comment #30 from rguenther at suse dot de  ---
On Thu, 9 Nov 2017, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
> 
> --- Comment #29 from Eric Botcazou  ---
> > It does by removing the SHT_NULL sections.  The patch should work - you 
> > can double-check - it just doesn't handle the "corner case" of more
> > than 32000 input sections correctly when rewriting the symbol table.
> 
> There is one nit with -g3 on x86-64/Linux:
> 
> FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 (test for excess errors)
> FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O (test for excess errors)
> FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O3 (test for excess errors)
> 
> /home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
> group info for section .debug_macro
> /home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
> group info for section .debug_macro
> /home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
> group info for section .debug_macro
> /home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
> group info for section .debug_macro
> /home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
> group info for section .debug_macro
> /home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
> group info for section .debug_macro
> /tmp/ccyqoYHFdebugobjtem: file not recognized: Bad value
> collect2: error: ld returned 1 exit status
> lto-wrapper: fatal error: gcc/xgcc returned 1 exit status
> compilation terminated.
> /home/eric/install/gcc/x86_64-suse-linux/bin/ld: error: lto-wrapper failed

Not sure what this is about.  Ah, I guess I need to remap GROUP
section indices as well (the GROUP SH_TYPE data).

[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Richard Biener from comment #2)
> (In reply to Paul Eggert from comment #1)
> > (In reply to Paul Eggert from comment #0)
> > 
> > Sorry, but my example in comment #0 (although it illustrates a bug) doesn't
> > illustrate the bug that crashed GCC. Here's a better example:
> > 
> >   struct t { long mem; };
> >   __attribute__ ((aligned (2))) struct t a;
> >   struct __attribute__ ((aligned (2))) t b;
> >   struct t __attribute__ ((aligned (2))) c;
> >   struct t d __attribute__ ((aligned (2)));
> > 
> > This compiles into:
> > 
> > .comm   a,8,2
> > .comm   b,8,8
> > .comm   c,8,2
> > .comm   d,8,2
> > 
> > Here, only 'b' is aligned correctly. The variables a, c, and d have an
> > alignment of only 2, but they should have an alignment of 8 because
> > __attribute__ ((aligned (8))) is documented to never decrease the alignment
> > of a structure, only to increase it. The GCC 7.2 documentation
> >  > html> says, "When used on a struct, or struct member, the 'aligned'
> > attribute can only increase the alignment; in order to decrease it, the
> > 'packed' attribute must be specified as well."
> 
> I think this applies to types but not to variables.  IIRC there's no packed
> attribute for variables:
> 
> int a __attribute__((aligned(2),packed));
> > gcc-7 -S t.c
> t.c:1:1: warning: ‘packed’ attribute ignored [-Wattributes]
>  int a __attribute__((aligned(2),packed));
>  ^~~
> 
> so yes, for type definitions you should need packed to decrease alignment
> but for variable declarations aligned is taken literally.
> 
> You are not using aligned on a 'struct or struct member' but on the variable
> in all but (b).

You'd still think there'd be a diagnostic from -Wattributes for the aligned
attribute, too, not just the packed one...

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #29 from Eric Botcazou  ---
> It does by removing the SHT_NULL sections.  The patch should work - you 
> can double-check - it just doesn't handle the "corner case" of more
> than 32000 input sections correctly when rewriting the symbol table.

There is one nit with -g3 on x86-64/Linux:

FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O3 (test for excess errors)

/home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
group info for section .debug_macro
/home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
group info for section .debug_macro
/home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
group info for section .debug_macro
/home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
group info for section .debug_macro
/home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
group info for section .debug_macro
/home/eric/install/gcc/x86_64-suse-linux/bin/ld: /tmp/ccyqoYHFdebugobjtem: no
group info for section .debug_macro
/tmp/ccyqoYHFdebugobjtem: file not recognized: Bad value
collect2: error: ld returned 1 exit status
lto-wrapper: fatal error: gcc/xgcc returned 1 exit status
compilation terminated.
/home/eric/install/gcc/x86_64-suse-linux/bin/ld: error: lto-wrapper failed

[Bug preprocessor/53404] warning column reported on comment in warning during bootstrap

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||build, diagnostic
 Status|WAITING |NEW

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Eric Gallager from comment #3)
> > (In reply to Manuel López-Ibáñez from comment #2)
> > > I don't see this any longer.
> > 
> > I think I might've seen this before, but I'll have to double-check the next
> > time I bootstrap to make sure
> 
> The warnings I get from gengtype-lex.c when bootstrapping are now:
> 
> ../../gcc/gengtype-lex.l: In function ‘int yylex(const char**)’:
> gengtype-lex.c:287:13: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
>   *yy_cp = '\0'; \
>   ~~~^~~
> ../../gcc/gengtype-lex.l:116:1: note: in expansion of macro
> ‘YY_DO_BEFORE_ACTION’
>  *yylval = XDUPVAR (const char, yytext, yyleng, yyleng + 1);
>  ^   ~~~
> ../../gcc/gengtype-lex.l:113:1: note: here
>  "~" |
>  ^~~~
> gengtype-lex.c:287:13: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
>   *yy_cp = '\0'; \
>   ~~~^~~
> ../../gcc/gengtype-lex.l:133:1: note: in expansion of macro
> ‘YY_DO_BEFORE_ACTION’
>  
>  ^  
> ../../gcc/gengtype-lex.l:131:1: note: here
>  "ENUM_BITFIELD"{WS}?"("{WS}?{ID}{WS}?")" {
>  ^~~~
> 
> ...which is no longer in a comment, but it still seems like there's some
> wrong location information involved. Separate issue or the same thing?

I'm gonna assume it's the same thing and confirm this.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> Both of the remaining testcases now compile for me.
> Probably can close this PR.

With my instrumented gfortran compiler I still see failures similar to the one
reported in comment 2:

pr78746.f90:5:39:

   character(:), allocatable :: x(n) ! { dg-error "must have a deferred
shape" }
   1
Error: Allocatable component of structure at (1) must have a deferred shape
=
==80385==ERROR: AddressSanitizer: heap-use-after-free on address 0x604010e8
at pc 0x0001003b3627 bp 0x7fff5fbfe530 sp 0x7fff5fbfe528
READ of size 8 at 0x604010e8 thread T0
#0 0x1003b3626 in gfc_resolve_expr(gfc_expr*) resolve.c:6736
#1 0x100015279 in resolve_array_bound(gfc_expr*, int) array.c:327
#2 0x10001bd19 in gfc_resolve_array_spec(gfc_array_spec*, int) array.c:368
#3 0x1003a7bdd in resolve_component(gfc_component*, gfc_symbol*)
resolve.c:13920
#4 0x1003abfa1 in resolve_fl_derived0(gfc_symbol*) resolve.c:14039
#5 0x1003acbdb in resolve_fl_derived(gfc_symbol*) resolve.c:14134
#6 0x10039a977 in resolve_symbol(gfc_symbol*) resolve.c:14479
#7 0x10046c576 in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*),
void (*)(gfc_symbol*)) symbol.c:4157
#8 0x10048a3a5 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
symbol.c:4182
#9 0x1004002ed in resolve_types(gfc_namespace*) resolve.c:16358
#10 0x100395fc9 in gfc_resolve(gfc_namespace*) resolve.c:16472
#11 0x1002feb25 in resolve_all_program_units(gfc_namespace*) parse.c:6030
#12 0x10031dc5f in gfc_parse_file() parse.c:6280
#13 0x1004d36b3 in gfc_be_parse_file() f95-lang.c:204
#14 0x1052de1b0 in compile_file() toplev.c:454
#15 0x1052e857d in do_compile() toplev.c:2059
#16 0x1075dd23b in toplev::main(int, char**) toplev.c:2194
#17 0x1075e2a87 in main main.c:39
#18 0x7fffcb057234 in start (libdyld.dylib:x86_64+0x5234)

0x604010e8 is located 24 bytes inside of 48-byte region
[0x604010d0,0x60401100)
freed by thread T0 here:
#0 0x1562efe10 in wrap_free.part.0 sanitizer_malloc_mac.inc:142
#1 0x100480732 in gfc_delete_symtree(gfc_symtree**, char const*)
symbol.c:2927
#2 0x10049a7d4 in gfc_restore_last_undo_checkpoint() symbol.c:3694
#3 0x10049aa2c in gfc_undo_symbols() symbol.c:3727
#4 0x1002fefd5 in reject_statement() parse.c:2546
#5 0x1002ff11d in match_word(char const*, match (*)(), locus*) parse.c:70
#6 0x10030ba38 in decode_statement() parse.c:376
#7 0x10030e091 in next_free() parse.c:1225
#8 0x10030ea5e in next_statement() parse.c:1457
#9 0x100313af2 in parse_derived() parse.c:3255
#10 0x1003154d7 in parse_spec(gfc_statement) parse.c:3795
#11 0x10031b954 in parse_progunit(gfc_statement) parse.c:5637
#12 0x10031dc21 in gfc_parse_file() parse.c:6177
#13 0x1004d36b3 in gfc_be_parse_file() f95-lang.c:204
#14 0x1052de1b0 in compile_file() toplev.c:454
#15 0x1052e857d in do_compile() toplev.c:2059
#16 0x1075dd23b in toplev::main(int, char**) toplev.c:2194
#17 0x1075e2a87 in main main.c:39
#18 0x7fffcb057234 in start (libdyld.dylib:x86_64+0x5234)

previously allocated by thread T0 here:
#0 0x1562ef46c in wrap_calloc sanitizer_malloc_mac.inc:153
#1 0x10746b354 in xcalloc xmalloc.c:162
#2 0x1004803dd in gfc_new_symtree(gfc_symtree**, char const*) symbol.c:2897
#3 0x1004843d2 in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3356
#4 0x100490128 in gfc_get_ha_sym_tree(char const*, gfc_symtree**)
symbol.c:3441
#5 0x100341f22 in gfc_match_rvalue(gfc_expr**) primary.c:3141
#6 0x100226505 in match_primary(gfc_expr**) matchexp.c:157
#7 0x100226794 in match_level_1(gfc_expr**) matchexp.c:211
#8 0x100226b09 in match_mult_operand(gfc_expr**) matchexp.c:267
#9 0x100227313 in match_add_operand(gfc_expr**) matchexp.c:356
#10 0x100227d00 in match_level_2(gfc_expr**) matchexp.c:480
#11 0x100228210 in match_level_3(gfc_expr**) matchexp.c:551
#12 0x100228689 in match_level_4(gfc_expr**) matchexp.c:599
#13 0x1002294bd in match_and_operand(gfc_expr**) matchexp.c:693
#14 0x10022978c in match_or_operand(gfc_expr**) matchexp.c:722
#15 0x100229bf1 in match_equiv_operand(gfc_expr**) matchexp.c:765
#16 0x10022a060 in match_level_5(gfc_expr**) matchexp.c:811
#17 0x100226029 in gfc_match_expr(gfc_expr**) matchexp.c:870
#18 0x1000192cc in match_array_element_spec(gfc_array_spec*) array.c:433
#19 0x10001ca3d in gfc_match_array_spec(gfc_array_spec**, bool, bool)
array.c:528
#20 0x1000cf09c in variable_decl(int) decl.c:2256
#21 0x1000d2ab8 in gfc_match_data_decl() decl.c:5679
#22 0x1002ff09b in match_word(char const*, match (*)(), locus*) parse.c:65
#23 0x10030ba38 in decode_statement() parse.c:376
#24 0x10030e091 in next_free() 

[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference

[TonyELewis at hotmail dot com]

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

--- Comment #4 from Tony E Lewis  ---
Thanks very much for your quick work on this.

I agree that changing the standard is a reasonable approach but I also think
that changing the library implementations is a reasonable approach too. Please
may I ask what reasons make you go straight down the spec-changing route rather
than making the libraries comply?

I tried putting the argument on the libc++ issue (here:
https://bugs.llvm.org/show_bug.cgi?id=35235 ) that changing the libraries is
do-able and helps make more reasonable code "just work". It also removes one
more corner case from generic-programming. This seems to all work in the right
direction of making C++ simpler. Are these arguments unpersuasive?

[Bug rtl-optimization/82913] [8 Regression] ICE: Segmentation fault in try_merge_compare

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.
The problem is that we have:
(insn 9 59 10 2 (parallel [
(set (reg:DI 0 ax)
(zero_extend:DI (plus:SI (reg:SI 0 ax [107])
(const_int 1 [0x1]
(clobber (reg:CC 17 flags))
]) "pr82913.c":7 219 {addsi_1_zext}
 (nil))
...
(insn 14 13 23 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 0 ax [orig:90 _8 ] [90])
(const_int 0 [0]))) "pr82913.c":14 3 {*cmpsi_ccno_1}
 (nil))
(insn 23 14 24 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:DI 0 ax [orig:95  ] [95])
(const_int 0 [0]))) "pr82913.c":16 4 {*cmpdi_ccno_1}
 (nil))
and we record insn 9 as cmp 23's in_a_setter when it is single_set.  But then
try_eliminate_compare on the cmp 14 turns it into a cmp+zext plus and suddenly
when processing cmp 23 it is no longer a single_set.  By readding this guard we
end up with what we used to do, in this particular case it would need further
analysis to do something better (find out that because the comparison consumer
is a NZ test that we could just reuse the SImode comparison, as the zero
extension doesn't affect it; if the comparison was e.g. DImode and we'd test
the sign bit, that wouldn't be true).

[Bug ada/82844] [8 Regression] Many ada tests time out on x32

[derodat at adacore dot com]

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

--- Comment #9 from Pierre-Marie de Rodat  ---
I’ve setup an Ubuntu VM, installed libx32 runtime libraries and built with
“--with-multilib-list=m32,m64,mx32” + ran the testsuite (“make -C gcc -j8 -k
check-ada”), without reproducing the issues you describe. Is there something
obvious missing?

[I’ve since resumed porting GNAT patches, so hopefully the issue will disappear
on your side]

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška  ---
(In reply to Nathan Sidwell from comment #19)
> I can take a look at the trunk crash, but not till next week.  You could try
> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00384.html, which I've yet to
> commit.

Don't hurry. However the mentioned patch does not help with this ICE.

[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Started with r254536.

[Bug tree-optimization/82669] ICE at -Os on valid code on x86_64-linux-gnu: in bitmap_check_index, at sbitmap.h:105

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug tree-optimization/82669] ICE at -Os on valid code on x86_64-linux-gnu: in bitmap_check_index, at sbitmap.h:105

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Thu Nov  9 10:27:21 2017
New Revision: 254567

URL: https://gcc.gnu.org/viewcvs?rev=254567=gcc=rev
Log:
Remove non needed check in bmp_iter_set_init (PR tree-optimization/82669).

2017-11-09  Martin Liska  

PR tree-optimization/82669
* sbitmap.h (bmp_iter_set_init): Remove non needed check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/sbitmap.h

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #21 from Segher Boessenkool  ---
Fixed on all open branches.

[Bug rtl-optimization/69737] [5 Regression] FAIL: gcc.c-torture/execute/pr64682.c -O2 execution test

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Author: segher
Date: Thu Nov  9 10:23:30 2017
New Revision: 254565

URL: https://gcc.gnu.org/viewcvs?rev=254565=gcc=rev
Log:
Backport from mainline
2017-11-01  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/combine.c

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[segher at gcc dot gnu.org]

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

--- Comment #20 from Segher Boessenkool  ---
Author: segher
Date: Thu Nov  9 10:23:30 2017
New Revision: 254565

URL: https://gcc.gnu.org/viewcvs?rev=254565=gcc=rev
Log:
Backport from mainline
2017-11-01  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/combine.c

[Bug rtl-optimization/64682] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
Author: segher
Date: Thu Nov  9 10:23:30 2017
New Revision: 254565

URL: https://gcc.gnu.org/viewcvs?rev=254565=gcc=rev
Log:
Backport from mainline
2017-11-01  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/combine.c

[Bug rtl-optimization/69567] PowerPC64: cstore optimisation produces bad code

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
Author: segher
Date: Thu Nov  9 10:23:30 2017
New Revision: 254565

URL: https://gcc.gnu.org/viewcvs?rev=254565=gcc=rev
Log:
Backport from mainline
2017-11-01  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/combine.c

[Bug rtl-optimization/64682] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
Author: segher
Date: Thu Nov  9 10:21:06 2017
New Revision: 254564

URL: https://gcc.gnu.org/viewcvs?rev=254564=gcc=rev
Log:
Backport from mainline
2017-11-01  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/combine.c

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[segher at gcc dot gnu.org]

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

--- Comment #19 from Segher Boessenkool  ---
Author: segher
Date: Thu Nov  9 10:21:06 2017
New Revision: 254564

URL: https://gcc.gnu.org/viewcvs?rev=254564=gcc=rev
Log:
Backport from mainline
2017-11-01  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/combine.c

[Bug rtl-optimization/69567] PowerPC64: cstore optimisation produces bad code

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
Author: segher
Date: Thu Nov  9 10:21:06 2017
New Revision: 254564

URL: https://gcc.gnu.org/viewcvs?rev=254564=gcc=rev
Log:
Backport from mainline
2017-11-01  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/combine.c

[Bug rtl-optimization/69737] [5 Regression] FAIL: gcc.c-torture/execute/pr64682.c -O2 execution test

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Author: segher
Date: Thu Nov  9 10:21:06 2017
New Revision: 254564

URL: https://gcc.gnu.org/viewcvs?rev=254564=gcc=rev
Log:
Backport from mainline
2017-11-01  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/combine.c

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 9 Nov 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821
> 
> --- Comment #10 from Jakub Jelinek  ---
> All the store merging changes so far were for the same operations on all the
> loads/constant values.
> In order to handle something like this, we'd need to best hook in the bswap
> machinery, probably start with moving over the bswap pass from
> tree-ssa-math-opts.c to gimple-ssa-store-merging.c.

Moving the pass was on my list of thoughts as well.

>  Then for stores that are
> 8/16/32 bits wide, try/remember find_bswap_or_nop_1 (stmt as well as
> symbolic_number).
> Then, if the stores are really all adjacent and form a power of two bitsize 
> and
> their symbolic numbers combined are cmpnop or cmpxchg consider that as 
> identity
> or bswap operation and use bswap_replace to prepare the argument for the group
> store.
> Now, it would be somewhat different in the way it needs to be handled, the
> alignment needs to be taken into account already at coalesce_immediate_stores
> time and split_group would for such a group need to result in store of
> everything together.

I think bswap doesn't currently track operations like ~ ontop of the
individual bytes so that would need to be added as well.  It would
become more and more a "mini vectorization" pass thus even operations
like + constant would be interesting (but more difficult if the
individual pieces are not bytes).

Note that to avoid exponential issues we should remember the
bswap state for each SSA def we ever processed (still starting only
from stores for the purpose of store merging).  I think the current
bswap pass doesn't do that (but restricts itself to single-uses)

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
All the store merging changes so far were for the same operations on all the
loads/constant values.
In order to handle something like this, we'd need to best hook in the bswap
machinery, probably start with moving over the bswap pass from
tree-ssa-math-opts.c to gimple-ssa-store-merging.c.  Then for stores that are
8/16/32 bits wide, try/remember find_bswap_or_nop_1 (stmt as well as
symbolic_number).
Then, if the stores are really all adjacent and form a power of two bitsize and
their symbolic numbers combined are cmpnop or cmpxchg consider that as identity
or bswap operation and use bswap_replace to prepare the argument for the group
store.
Now, it would be somewhat different in the way it needs to be handled, the
alignment needs to be taken into account already at coalesce_immediate_stores
time and split_group would for such a group need to result in store of
everything together.

[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target|powerpc64le-*-* |powerpc64le-*-*, x86_64-*-*

--- Comment #1 from Markus Trippelsdorf  ---
Also happens on X86_64, so I guess the issue is target independent.

[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc64le-*-*
   Target Milestone|--- |8.0

[Bug bootstrap/82916] New: [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[trippels at gcc dot gnu.org]

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

Bug ID: 82916
   Summary: [8 regression] gcc miscompiled during stagefeedback
(PGO bootstrap)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

During stagefeedback (PGO bootstrap) gcc gets miscompiled.
It segfaults when building libgcc, e.g.:

trippels@gcc2-power8 libgcc % gdb --args
/home/trippels/gcc_build_dir_/./gcc/xgcc -B/home/trippels/gcc_build_dir_/./gcc/
-B/usr/local/powerpc64le-unknown-linux-gnu/bin/
-B/usr/local/powerpc64le-unknown-linux-gnu/lib/ -isystem
/usr/local/powerpc64le-unknown-linux-gnu/include -isystem
/usr/local/powerpc64le-unknown-linux-gnu/sys-include -mcpu=power8
-Wno-error=coverage-mismatch -O3 -pipe -O2 -mcpu=power8
-Wno-error=coverage-mismatch -O3 -pipe -DIN_GCC -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC
-mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I../../../gcc/libgcc
-I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include -I../../../gcc/libgcc/../libdecnumber/dpd
-I../../../gcc/libgcc/../libdecnumber -DHAVE_CC_TLS -o _gcov_merge_add.o -MT
_gcov_merge_add.o -MD -MP -MF _gcov_merge_add.dep -DL_gcov_merge_add -c
../../../gcc/libgcc/libgcov-merge.c

Thread 2.1 "cc1" received signal SIGSEGV, Segmentation fault.
[Switching to process 9861]
0x10317914 in nearest_common_dominator_for_set(cdi_direction,
bitmap_head*) ()
(gdb) bt
#0  0x10317914 in nearest_common_dominator_for_set(cdi_direction,
bitmap_head*) ()
#1  0x10610f70 in update_ssa(unsigned int) ()
#2  0x107a36ac in (anonymous namespace)::pass_vrp::execute(function*)
()
#3  0x1051b39c in execute_one_pass(opt_pass*) ()
#4  0x1051ec40 in execute_pass_list(function*, opt_pass*) ()
#5  0x102c1f84 in cgraph_node::expand() ()
#6  0x10af4620 in symbol_table::compile() ()
#7  0x102be550 in symbol_table::finalize_compilation_unit() ()
#8  0x10d220dc in compile_file() ()
#9  0x101b36ec in toplev::main(int, char**) ()
#10 0x101b5928 in main ()

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Thu, 9 Nov 2017, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821
> 
> --- Comment #8 from Uroš Bizjak  ---
> (In reply to rguent...@suse.de from comment #6)
> 
> > > In addition to a merge opportunity, there is a redundant move [*], that 
> > > results
> > > in redundant operation [**]. The whole function could be just:
> > > 
> > > movw%dx, -4(%rdi,%rsi)
> > > notl%edx
> > > movw%dx, -2(%rdi,%rsi)
> > 
> > or
> > 
> >   xorl$0x, %edx
> >   movl%edx, -4(%rdi,%rsi)
> > 
> > ?
> 
> Yes, even this. It looks that store merging opens many optimization
> opportunities.

I believe we should aggressively merge stores as this helps STLF
(as opposed to merging loads which can introduce STLF issues)

[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #16 from Martin Liška  ---
I see any feedback, leaving the PR then ...

[Bug gcov-profile/48463] gcov does not handle C++ clones (deleting ctors, template instantiations)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Fixed.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #6)

> > In addition to a merge opportunity, there is a redundant move [*], that 
> > results
> > in redundant operation [**]. The whole function could be just:
> > 
> > movw%dx, -4(%rdi,%rsi)
> > notl%edx
> > movw%dx, -2(%rdi,%rsi)
> 
> or
> 
>   xorl$0x, %edx
>   movl%edx, -4(%rdi,%rsi)
> 
> ?

Yes, even this. It looks that store merging opens many optimization
opportunities.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Uroš Bizjak  ---
On a related note, following testcase:

--cut here--
typedef __SIZE_TYPE__ size_t;

void baz (char *buf, unsigned int data)
{
  buf[0] = data;
  buf[1] = data >> 8;

  buf[2] = ~data >> 8;
  buf[3] = ~data;
}
--cut here--

could be optimized with -march=haswell to:

movw%si, (%rdi)
notl%eax
movbew  %si, 2(%rdi)

[Bug gcov-profile/48463] gcov does not handle C++ clones (deleting ctors, template instantiations)

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Thu Nov  9 09:11:17 2017
New Revision: 254562

URL: https://gcc.gnu.org/viewcvs?rev=254562=gcc=rev
Log:
GCOV: support multiple functions per a line (PR gcov-profile/48463)

2017-11-09  Martin Liska  

PR gcov-profile/48463
* coverage.c (coverage_begin_function): Output also end locus
of a function and information whether the function is
artificial.
* gcov-dump.c (tag_function): Parse and print the information.
* gcov.c (INCLUDE_MAP): Add include.
(INCLUDE_SET): Likewise.
(struct line_info): Move earlier in the source file because
of vector in function_info structure.
(line_info::line_info): Likewise.
(line_info::has_block): Likewise.
(struct source_info): Add new member index.
(source_info::get_functions_at_location): New function.
(function_info::group_line_p): New function.
(output_intermediate_line): New function.
(output_intermediate_file): Use the mentioned function.
(struct function_start): New.
(struct function_start_pair_hash): Likewise.
(process_file): Add code that identifies group functions.
Assign lines either to global or function scope.
(generate_results): Skip artificial functions.
(find_source): Assign index for each source file.
(read_graph_file): Read new flag artificial and end_line.
(add_line_counts): Assign it either to global of function scope.
(accumulate_line_counts): Isolate core of the function to
accumulate_line_info and call it for both function and global
scope lines.
(accumulate_line_info): New function.
(output_line_beginning): Fix GNU coding style.
(print_source_line): New function.
(output_line_details): Likewise.
(output_function_details): Likewise.
(output_lines): Iterate both source (global) scope and function
scope.
(struct function_line_start_cmp): New class.
* doc/gcov.texi: Reflect changes in documentation.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c
trunk/gcc/doc/gcov.texi
trunk/gcc/gcov-dump.c
trunk/gcc/gcov.c

[Bug debug/82837] [8 Regression] ICE in output_operand: invalid expression as operand

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Thu, 9 Nov 2017, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821
> 
> --- Comment #5 from Uroš Bizjak  ---
> The cc1 gem from comment #2 actually comes from libz's deflate.c, function
> deflate_stores:
> 
> /* Replace the lengths in the dummy stored block with len. */
> s->pending_buf[s->pending - 4] = len;
> s->pending_buf[s->pending - 3] = len >> 8;
> s->pending_buf[s->pending - 2] = ~len;
> s->pending_buf[s->pending - 1] = ~len >> 8;
> 
> The compiler, patched with both patches, does not merge stores there.
> 
> Please consider following testcase:
> 
> --cut here--
> typedef __SIZE_TYPE__ size_t;
> 
> struct s
> {
>   char *buf;
>   size_t cnt;
> };
> 
> void foo (struct s *state, unsigned int data)
> {
>   state->buf[state->cnt - 4] = data;
>   state->buf[state->cnt - 3] = data >> 8;
>   state->buf[state->cnt - 2] = ~data;
>   state->buf[state->cnt - 1] = ~data >> 8;
> }
> 
> void bar (char *buf, size_t *cnt, unsigned int data)
> {
>   buf[*cnt - 4] = data;
>   buf[*cnt - 3] = data >> 8;
>   buf[*cnt - 2] = ~data;
>   buf[*cnt - 1] = ~data >> 8;
> }
> 
> void baz (char *buf, size_t cnt, unsigned int data)
> {
>   buf[cnt - 4] = data;
>   buf[cnt - 3] = data >> 8;
>   buf[cnt - 2] = ~data;
>   buf[cnt - 1] = ~data >> 8;
> }
> --cut here--
> 
> None of the stores in the above functions are merged.
> 
> The simplest function (baz) results in:
> 
> [*] movl%edx, %eax
> movb%dl, -4(%rdi,%rsi)
> movb%dh, -3(%rdi,%rsi)
> notl%eax
> [**]notl%edx
> movb%al, -2(%rdi,%rsi)
> movb%dh, -1(%rdi,%rsi)
> 
> In addition to a merge opportunity, there is a redundant move [*], that 
> results
> in redundant operation [**]. The whole function could be just:
> 
> movw%dx, -4(%rdi,%rsi)
> notl%edx
> movw%dx, -2(%rdi,%rsi)

or

  xorl$0x, %edx
  movl%edx, -4(%rdi,%rsi)

?

[Bug debug/82837] [8 Regression] ICE in output_operand: invalid expression as operand

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov  9 08:54:19 2017
New Revision: 254561

URL: https://gcc.gnu.org/viewcvs?rev=254561=gcc=rev
Log:
PR debug/82837
* dwarf2out.c (const_ok_for_output_1): Reject NEG in addition to NOT.
(mem_loc_descriptor): Handle (const (neg (...))) as (neg (const (...)))
and similarly for not instead of neg.

* gcc.dg/debug/dwarf2/pr82837.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr82837.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
The cc1 gem from comment #2 actually comes from libz's deflate.c, function
deflate_stores:

/* Replace the lengths in the dummy stored block with len. */
s->pending_buf[s->pending - 4] = len;
s->pending_buf[s->pending - 3] = len >> 8;
s->pending_buf[s->pending - 2] = ~len;
s->pending_buf[s->pending - 1] = ~len >> 8;

The compiler, patched with both patches, does not merge stores there.

Please consider following testcase:

--cut here--
typedef __SIZE_TYPE__ size_t;

struct s
{
  char *buf;
  size_t cnt;
};

void foo (struct s *state, unsigned int data)
{
  state->buf[state->cnt - 4] = data;
  state->buf[state->cnt - 3] = data >> 8;
  state->buf[state->cnt - 2] = ~data;
  state->buf[state->cnt - 1] = ~data >> 8;
}

void bar (char *buf, size_t *cnt, unsigned int data)
{
  buf[*cnt - 4] = data;
  buf[*cnt - 3] = data >> 8;
  buf[*cnt - 2] = ~data;
  buf[*cnt - 1] = ~data >> 8;
}

void baz (char *buf, size_t cnt, unsigned int data)
{
  buf[cnt - 4] = data;
  buf[cnt - 3] = data >> 8;
  buf[cnt - 2] = ~data;
  buf[cnt - 1] = ~data >> 8;
}
--cut here--

None of the stores in the above functions are merged.

The simplest function (baz) results in:

[*] movl%edx, %eax
movb%dl, -4(%rdi,%rsi)
movb%dh, -3(%rdi,%rsi)
notl%eax
[**]notl%edx
movb%al, -2(%rdi,%rsi)
movb%dh, -1(%rdi,%rsi)

In addition to a merge opportunity, there is a redundant move [*], that results
in redundant operation [**]. The whole function could be just:

movw%dx, -4(%rdi,%rsi)
notl%edx
movw%dx, -2(%rdi,%rsi)

[Bug rtl-optimization/82913] [8 Regression] ICE: Segmentation fault in try_merge_compare

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed, started with r254328.

[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
(In reply to Paul Eggert from comment #1)
> (In reply to Paul Eggert from comment #0)
> 
> Sorry, but my example in comment #0 (although it illustrates a bug) doesn't
> illustrate the bug that crashed GCC. Here's a better example:
> 
>   struct t { long mem; };
>   __attribute__ ((aligned (2))) struct t a;
>   struct __attribute__ ((aligned (2))) t b;
>   struct t __attribute__ ((aligned (2))) c;
>   struct t d __attribute__ ((aligned (2)));
> 
> This compiles into:
> 
>   .comm   a,8,2
>   .comm   b,8,8
>   .comm   c,8,2
>   .comm   d,8,2
> 
> Here, only 'b' is aligned correctly. The variables a, c, and d have an
> alignment of only 2, but they should have an alignment of 8 because
> __attribute__ ((aligned (8))) is documented to never decrease the alignment
> of a structure, only to increase it. The GCC 7.2 documentation
>  html> says, "When used on a struct, or struct member, the 'aligned'
> attribute can only increase the alignment; in order to decrease it, the
> 'packed' attribute must be specified as well."

I think this applies to types but not to variables.  IIRC there's no packed
attribute for variables:

int a __attribute__((aligned(2),packed));
> gcc-7 -S t.c
t.c:1:1: warning: ‘packed’ attribute ignored [-Wattributes]
 int a __attribute__((aligned(2),packed));
 ^~~

so yes, for type definitions you should need packed to decrease alignment
but for variable declarations aligned is taken literally.

You are not using aligned on a 'struct or struct member' but on the variable
in all but (b).

[Bug target/82915] Please mark intrinsics as constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  Note this trivially applies to all open-coded intrinsics not using
__builtin_ia32_* calls, marking those constexpr would require significant work
(work that might be useful anyways for optimization, of course).

[Bug rtl-optimization/82913] [8 Regression] ICE: Segmentation fault in try_merge_compare

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/82910] marking data members private affects code generation of copying

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-09
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
With public members the C++ FE emits

;; Function pair my::get(const other&) (null)
;; enabled by -tree-original


 = *(struct pair &)
_EXPR ) >;
< = TARGET_EXPR current>>>;

while with private members we end up with

] =
MEM[(struct pair *)(struct pair &) _EXPR ];, <<< Unknown tree: void_cst >>> >;
< = TARGET_EXPR current>>>;

that is, the only difference is we use a different type.  That's enough to
trigger
gimplification differences - with private members we emit

pair my::get(const other&) (struct my * const this, const struct other & other)
{
  struct pair D.2301;
  struct pair D.2343;

  D.2301 = other::get (other);
  try
{
  _1 = this->target;
  MEM[(struct pair *)_1] = MEM[(struct pair *)];
}
  finally
{
  D.2301 = {CLOBBER};
}
  D.2343 = this->current;
  return D.2343;
}

while with public:

pair my::get(const other&) (struct my * const this, const struct other & other)
{
  struct pair D.2339;

  _1 = this->target;
  *_1 = other::get (other);
  D.2339 = this->current;
  return D.2339;
}

so we have an extra temporary forced upon us.  Not sure if middle-end
gimplification is confused by the different GENERIC or FE gimplification.

[Bug target/82907] [8 regression] gcc.target/powerpc/p9-xxbr-1.c fails after r254464

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug ipa/82908] [8 regression] gcc.dg/tree-prof/cmpsf-1.c and gcc.dg/tree-prof/20050826-2.c fail starting with r254452

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0