[Bug target/88620] ICE in assign_stack_temp_for_type, at function.c:837

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #1 from Arseny Solokha  ---
This is likely a duplicate of PR82564. I had it too on x86_64.

[Bug target/88622] ICE when changing -mpreferred-stack-boundary for different files with LTO

[andi-gcc at firstfloor dot org]

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

--- Comment #4 from Andi Kleen  ---
Ok that means that this code you pasted in ix86_option_override_internal
somehow doesn't get executed correctly for LTO switching between different
options.

Adding Honza.

[Bug target/88622] ICE when changing -mpreferred-stack-boundary for different files with LTO

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Andi Kleen  ---
Ok that means that this code you pasted in ix86_option_override_internal
somehow doesn't get executed correctly for LTO switching between different
options.

Adding Honza.

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[vries at gcc dot gnu.org]

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

--- Comment #14 from Tom de Vries  ---
Author: vries
Date: Fri Dec 28 03:43:26 2018
New Revision: 267443

URL: https://gcc.gnu.org/viewcvs?rev=267443&root=gcc&view=rev
Log:
[libbacktrace] Fix memory leak in loop in build_address_map

When failing in build_address_map, we free the unit that's currently being
handled in the loop, but the ones that already have been allocated are leaked.

Fix this by keeping track of allocated units in a vector, and releasing them
upon failure.

Also, now that we have a vector of allocated units, move the freeing upon
failure of the abbrevs associated with each unit to build_address_map, and
remove the now redundant call to free_unit_addrs_vector.

Bootstrapped and reg-tested on x86_64.

2018-12-28  Ian Lance Taylor  
Tom de Vries  

PR libbacktrace/88063
* dwarf.c (free_unit_addrs_vector): Remove.
(build_address_map): Keep track of allocated units in vector.  Free
allocated units and corresponding abbrevs upon failure.  Remove now
redundant call to free_unit_addrs_vector.  Free addrs vector upon
failure.  Free allocated unit vector.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/dwarf.c

[Bug target/88627] Gcc -N -nostdlib Now includes PT_INTERP Which causes auxv fetching to fail due to out of range PT_PHDR

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Without -static or your own -dynamic-linker option, it will always include the
dynamic linker (loader).

If there is an out of range PT_PHDR, then the bug is in the dynamic linker
rather than GCC.

[Bug c/88627] New: Gcc -N -nostdlib Now includes PT_INTERP Which causes auxv fetching to fail due to out of range PT_PHDR

[ryan at bitlackeys dot org]

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

Bug ID: 88627
   Summary: Gcc -N -nostdlib Now includes PT_INTERP Which causes
auxv fetching to fail due to out of range PT_PHDR
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan at bitlackeys dot org
  Target Milestone: ---

[Bug libstdc++/88607] forward_list.h contains utf-8 charactor

[fudou...@m-japan.co.jp]

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

--- Comment #3 from hirofumi fudoudou  ---
sorry, The words may have been strong

>> just remove or change the char to 'f' and 'I'.

[Bug c++/86648] [9 Regression] ICE on class template argument deduction

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #5 from Alexandre Oliva  ---
Created attachment 45293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45293&action=edit
candidate patch

dwarf2out.c only recognizes auto and declspec(auto) as C++ auto identifiers
possibly mapped to unspecified types.

[Bug libstdc++/88607] forward_list.h contains utf-8 charactor

[fudou...@m-japan.co.jp]

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

--- Comment #2 from hirofumi fudoudou  ---
but this is just a comment.
not a code.

just remove or change the char to 'f' and 'I'.

[Bug target/88614] ICE: output_operand: invalid %z value

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-27
 CC|amodra at gcc dot gnu.org  |
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
 Ever confirmed|0   |1

[Bug fortran/45424] [F08] Add IS_CONTIGUOUS intrinsic

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
Created attachment 45292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45292&action=edit
Update of Tobias' patch to 9-trunk (except for ChangeLog)

I've tried to update Tobias' patch so that it compiles with 9-trunk
and adjusted his testcase so that it uses STOP instead of call abort ().

There's one problem left and one question.

The problem is that I'm getting one failure with the following test:

  implicit none
  real, allocatable :: a(:), b(:,:)
  integer :: k = 0

  allocate(a(5), b(10,10))
  call test (a, .true.)
  call test (b, .true.)
  call test (b(::1,::1), .true.)
  call test (b(::2,::1), .false.)
  call test (b(::1,::2), .false.)  ! This test fails currently
contains
  subroutine test (x, res)
!   type(*), dimension(..), intent(in) :: x  ! Should this be allowed?
real,dimension(..), intent(in) :: x
logical,intent(in) :: res
k = k + 1
if (is_contiguous (x) .eqv. res) return
print *, "Failure of test", k
stop "FAIL"
  end subroutine test
end program

Maybe something else needs to be updated.

Furthermore, should type(*), dimension(..) be allowed?  Opinions?
I tend to think so.  Does this need explicit coding as for e.g. SIZEOF,
or are there better ways?

[Bug ipa/88626] New: __builtin_constant_p should be as cheap as dead code for inlining purposes

[glisse at gcc dot gnu.org]

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

Bug ID: 88626
   Summary: __builtin_constant_p should be as cheap as dead code
for inlining purposes
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

void h(int);
inline void f(int n){
#if 0
  bool b = ((n+2)*5-1)/3==1;
  if(__builtin_constant_p(b)&&b){
h(3);return;
  }
#endif
  h(4);
  h(n);
}
void g(){f(7);}

Compiling with g++ -O2, we early-inline f into g, good. If I change #if 0 to
#if 1, we don't early-inline anymore because of the many instructions needed to
compute b. However, to a human, it is obvious that all this code to compute b
is "dead", it will never be emitted. If anything, the presence of
__builtin_constant_p should make this function a better candidate for inlining.

I don't know if this is a good example, maybe regular inlining is good enough
for such functions, and the analysis required for what I am asking would be
unsuitable for einline. I have a program where I introduced a
__builtin_constant_p shortcut in one function and noticed a 15% slowdown on the
total running time. Differences in inlining behavior are the most likely
explanation (and --param early-inlining-insns does help), so I quickly put a
testcase together. Feel free to close if it doesn't make sense.

[Bug c/88625] c11: GCC Allows enumerator value not representable in type int.

[anders.granlund.0 at gmail dot com]

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

--- Comment #1 from Anders Granlund  ---
Forgot to include the include of a header file in the test case:

  #include 

  enum E { x = UINT_MAX };

  int main()
  {
  }

[Bug c/88625] New: c11: GCC Allows enumerator value not representable in type int.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88625
   Summary: c11: GCC Allows enumerator value not representable in
type int.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  enum E { x = UINT_MAX };

  int main()
  {
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  No error message outputed.

Expected behaviour:

  An error message outputed.

  The value of the integer constant expression UINT_MAX is not representable
  as an int. This is not allowed.

Reference to the c11 standard (the bugfix version of the c11 standard):

  6.7.2.2/2:

"The expression that defines the value of an enumeration constant shall be
 an integer constant expression that has a value representable as an int."

Note:

  Clang gives the expected error.

[Bug fortran/81027] Assumed-shape array reported as deferred.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |9.0

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

[Bug fortran/81027] Assumed-shape array reported as deferred.

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec 27 21:13:53 2018
New Revision: 267437

URL: https://gcc.gnu.org/viewcvs?rev=267437&root=gcc&view=rev
Log:
2018-12-27  Steven G. Kargl  

PR fortran/81027
* expr.c (gfc_check_init_expr): Distinguish assumed-shape versus
deferred-shape dummy arguments in an error message.

2018-12-27  Steven G. Kargl  

PR fortran/81027
* gfortran.dg/pr81027.f90: New test.
* gfortran.dg/initialization_7.f90: Update error message.

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

[Bug fortran/45424] [F08] Add IS_CONTIGUOUS intrinsic

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
Looking at the F2k18 draft, I see some updates and clarifications:

16.9.105 IS_CONTIGUOUS (ARRAY)
Description. Array contiguity test (8.5.7).
Class. Inquiry function.
Argument. ARRAY may be of any type. It shall be assumed-rank or an array. If it
is a pointer it shall be associated.
Result Characteristics. Default logical scalar.
Result Value. The result has the value true if ARRAY has rank zero or is
contiguous, and false otherwise.

[Example elided]

The clarification about rank zero is certainly helpful.

Furthermore:

8.5.7 CONTIGUOUS attribute

NOTE 1
If a derived type has only one component that is not zero-sized, it is
processor dependent whether a structure component of a contiguous array
of that type is contiguous. That is, the derived type might contain padding
on some processors.

This gives some freedom for a "conservative" implementation of the
intrinsic.

[Bug fortran/88624] New: [Coarray] Rejects allocatable coarray passed as a dummy argument

[m.modrzejewski at student dot uw.edu.pl]

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

Bug ID: 88624
   Summary: [Coarray] Rejects allocatable coarray passed as a
dummy argument
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.modrzejewski at student dot uw.edu.pl
  Target Milestone: ---

The compiler rejects a program where an allocatable coarray is passed to a
subroutine as an allocatable dummy argument, and then passed again as an
argument to another subroutine.

Here's a minimum example which doesn't compile with gfortran 8.2.0:

program test 
  implicit none 
  integer, parameter :: F64 = selected_real_kind(p=15, r=307) 
  real(F64), dimension(:), allocatable :: x[:] 
  call g(x) 
  if (this_image()==1) then 
print *, x 
  end if 
contains 
  subroutine g(x) 
real(F64), dimension(:), allocatable :: x[:] 
allocate(x(10)[*]) 
call g2(x) 
  end subroutine g 
  subroutine g2(x) 
real(F64), dimension(:) :: x[*] 
integer :: k 
do k = 1, 10 
  x(k) = 2.0_F64 * this_image() 
end do 
  end subroutine g2 
end program test 

The following error message appears: 

$ gfortran-8 -fcoarray=lib example-gfortran.f90 -lcaf_mpi 
example-gfortran.f90:13:0: 

 call g2(x) 

internal compiler error: in gfc_conv_procedure_call, at
fortran/trans-expr.c:5866 

The compilation completed without any errors when using the flag
-fcoarray=single. The Intel Fortran compiler doesn't see any problem here.

Regards,
Marcin

[Bug target/88622] ICE when changing -mpreferred-stack-boundary for different files with LTO

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
No, the assert is certainly desirable there.  TARGET_STV should not have been
enabled in that case, we have:
  /* Disable STV if -mpreferred-stack-boundary={2,3} or
 -mincoming-stack-boundary={2,3} or -mstackrealign - the needed
 stack realignment will be extra cost the pass doesn't take into
 account and the pass can't realign the stack.  */
  if (ix86_preferred_stack_boundary < 128
  || ix86_incoming_stack_boundary < 128
  || opts->x_ix86_force_align_arg_pointer)
opts->x_target_flags &= ~MASK_STV;

[Bug tree-optimization/88621] [9 Regression] wrong code at -O1 and above on x86_64-linux-gnu in 64-bit mode (not in 32-bit mode)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-27
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |9.0
Summary|wrong code at -O1 and above |[9 Regression] wrong code
   |on x86_64-linux-gnu in  |at -O1 and above on
   |64-bit mode (not in 32-bit  |x86_64-linux-gnu in 64-bit
   |mode)   |mode (not in 32-bit mode)
 Ever confirmed|0   |1

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

[Bug libgcc/88623] New: libgcc build uses CXX_FOR_BUILD but files have .c extension

[andrew at ishiboo dot com]

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

Bug ID: 88623
   Summary: libgcc build uses CXX_FOR_BUILD but files have .c
extension
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at ishiboo dot com
  Target Milestone: ---

Currently, gcc/Makefile.in specifies:

COMPILER_FOR_BUILD = $(CXX_FOR_BUILD)

indicating that the source files in the directory should be compiled with the
C++ compiler, but the source files still retain the .c suffix.

Building in this manner encodes some GCC-specific behavior into the build
process. For example, IBM's XL C++ compiler will not behave the same as GCC
when a file with a .c suffix is passed to the C++ compiler. There exists a
command-line option, `-+` to force treating input as C++ even if the filename
extension is .c, but this appears to have other side effects when it comes to
built-in macros such as __STDC__.

This caused an issue due to include/getopt.h only checking for __STDC__. I was
able to work around it by changing this line:

  #if defined (__STDC__) && __STDC__

to:

  #if (defined (__STDC__) && __STDC__) || defined(__cplusplus)

To ensure maximum compatibility bootstrapping with non-GCC compilers, the
libgcc source code file suffixes should change to reflect whether they are C or
C++ and the correct CC_FOR_BUILD / CXX_FOR_BUILD should be used to compile
them.

[Bug target/88622] ICE when changing -mpreferred-stack-boundary for different files with LTO

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 Target||x86_64-linux
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Andi Kleen  ---
Don't have a small reproducer, but on a large LTO build where a few files are
built with

-mpreferred-stack-boundary=4

with the others using the default

I hit the following ICE in ix86_minimum_alignment

29610   /* Don't do dynamic stack realignment for long long objects with
29611  -mpreferred-stack-boundary=2.  */
29612   if ((mode == DImode || (type && TYPE_MODE (type) == DImode))
29613   && (!type || !TYPE_USER_ALIGN (type))
29614   && (!decl || !DECL_USER_ALIGN (decl)))
29615 {
29616   gcc_checking_assert (!TARGET_STV);
29617   return 32;
29618 }


I suspect the right fix is to just remove the assert?


Adding Jakub who added it originally in:

commit 1f1475a7e758328a59db17aef5d1ccd81232ea95
Author: jakub 
Date:   Thu Feb 4 09:02:01 2016 +

PR target/69454
* config/i386/i386.c (convert_scalars_to_vector): Remove
stack alignment fixes.
(ix86_option_override_internal): Disable TARGET_STV if stack
might not be aligned enough.
(ix86_minimum_alignment): Assert that TARGET_STV is false.

* gcc.target/i386/pr69454-1.c: New test.
* gcc.target/i386/pr69454-2.c: New test.

[Bug target/88622] New: ICE when changing -mpreferred-stack-boundary for different files with LTO

[andi-gcc at firstfloor dot org]

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

Bug ID: 88622
   Summary: ICE when changing -mpreferred-stack-boundary for
different files with LTO
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

[Bug fortran/82995] Segmentation fault passing optional argument to intrinsic sum function

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

  Attachment #44790|0   |1
is obsolete||

--- Comment #11 from Thomas Koenig  ---
Created attachment 45291
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45291&action=edit
Next attempt

This patch handles the library side correctly, as far as cursory testing
reveals.

However, there still is something in there that I do not understand.

For the test case

module y 
implicit none 
contains 

  function my_sum(input,mask) 
logical, intent(in), optional :: mask(:) 
integer, intent(in) :: input(:) 
integer :: my_sum 
my_sum = sum(input,mask) 
  end function my_sum
end module y

program test_my_sum 
  use y
  implicit none 
  integer :: input(3) = [1,2,3] 
  integer :: res
  res = my_sum(input) 
  print *,res

end program test_my_sum

I get, on the caller's side

  {
struct array01_integer(kind=4) parm.10;

parm.10.span = 4;
parm.10.dtype = {.elem_len=4, .rank=1, .type=1};
parm.10.dim[0].lbound = 1;
parm.10.dim[0].ubound = 3;
parm.10.dim[0].stride = 1;
parm.10.data = (void *) &input[0];
parm.10.offset = -1;
res = my_sum (&parm.10, 0B);
  }

which looks good - there is a NULL pointer being passed to my_sum.

In my_sum, I get

  {
integer(kind=4) val.8;
integer(kind=8) D.3900;
integer(kind=8) D.3901;
integer(kind=8) D.3902;
integer(kind=8) D.3903;

val.8 = 0;
D.3900 = offset.6;
D.3901 = ubound.4;
D.3902 = offset.2;
D.3903 = ubound.0;
{
  integer(kind=8) S.9;
  integer(kind=8) D.3905;
  integer(kind=8) D.3906;

  D.3905 = stride.5;
  D.3906 = stride.1;
  S.9 = 1;
  while (1)
{
  if (S.9 > D.3901) goto L.1;
  if ((mask == 0B || (logical(kind=4)[0:] * restrict) mask->data == 0B)
|| (*mask.0)[S.9 * D.3905 + D.3900])
{
  val.8 = (*input.0)[S.9 * D.3906 + D.3902] + val.8;
}
  S.9 = S.9 + 1;
}
  L.1:;
}
__result_my_sum = val.8;
  }
  return __result_my_sum;
}

which looks quite OK.

Still, I get zero as a result.

Something to do with arguments being passed wrong, maybe?

[Bug target/88617] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11238 since r248029

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||daniel.santos at pobox dot com
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Confirmed, CC added.

[Bug lto/88081] [7/8/9 Regression] ICE in lto_varpool_replace_node, at lto/lto-symtab.c:109

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Hmm, then it is probably just masking the real problem.  I will take a look

[Bug tree-optimization/88605] vector extensions: Widening or conversion generates inefficient or scalar code.

[husseydevin at gmail dot com]

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

--- Comment #2 from Devin Hussey  ---
While __builtin_convertvector would improve the situation, the main issue here
is the blindness to some obvious patterns.

If I write this code, I want either pmovzdq or vmovl. I don't want to waste
time with scalar on the stack.

U64x2 pmovzdq(U32x2 v)
{
return (U64x2) { v[0], v[1] };
}

If I write this code, I want pmuludq or vmull if it can be optimized to it. I
don't want to mask it and do an entire 64-bit multiply.

U64x2 pmuludq(U64x2 v1, U64x2 v2)
{
return (v1 & 0x) * (v2 & 0x);
}

If I do this, I don't want scalar code on NEON. I want vshl + vsri, or at the
very least, vshl + vshr + vorr.

U64x2 vrol64(U64x2 v, int N)
{
return (v << N) | (v >> (64 - N));
}

Having a generic SIMD overload library built-in is awesome, but only if it
saves time.

If I can write one block of code that looks like normal C code but it actually
optimized vector code that runs at even 80% the speed of specialized intrinsics
regardless of the platform (or even if the platform supports SIMD), that saves
a lot of time especially when trying to remember the difference between
_mm_mullo and _mm_mul.

If you can write your code so you can do this

#ifdef __GNUC__
typedef unsigned U32x4 __attribute__((vector_size(16)));
#else
typedef unsigned U32x4[4];
#endif

and use them interchangeably with ANSI C arrays without worrying about GCC
scalarizing the code, that saves even more time.

If you have to write your code like asm.js or mix intrinsics with normal code
just to get code that runs at half the speed of intrinsics, that is not
beneficial.

[Bug tree-optimization/88621] New: wrong code at -O1 and above on x86_64-linux-gnu in 64-bit mode (not in 32-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 88621
   Summary: wrong code at -O1 and above on x86_64-linux-gnu in
64-bit mode (not in 32-bit mode)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to be a recent regression. 

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20181226 (experimental) [trunk revision 267421] (GCC) 
$ 
$ gcctk -O0 small.c; ./a.out
$ 
$ gcctk -O1 small.c
$ timeout -s 9 5 ./a.out
Killed
$ 


---


struct S
{
  int b:4;
  int c; 
} e = { -1, 0 };

int d, f;

int main ()
{
  while (f)
{
  struct S g = { 0, 0 };
  e = g;
}
L:
  while (e.b > 0)
;
  e.b = 0;
  if (d)
goto L;
  return 0;
}

[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
*** Bug 88618 has been marked as a duplicate of this bug. ***

[Bug target/88618] ICE in extract_insn, at recog.c:2305

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
Dup.

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

[Bug target/88620] New: ICE in assign_stack_temp_for_type, at function.c:837

[marxin at gcc dot gnu.org]

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

Bug ID: 88620
   Summary: ICE in assign_stack_temp_for_type, at function.c:837
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org, ramana at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

Following is causing ICE:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/nested-func-9.c -Ofast
--param ipa-cp-eval-threshold=0 -fno-guess-branch-probability
-fno-inline-small-functions
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/nested-func-9.c: In function
‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/nested-func-9.c:26:3:
internal compiler error: in assign_stack_temp_for_type, at function.c:837
   26 |   fn ();
  |   ^~
0x827dd4 assign_stack_temp_for_type(machine_mode, poly_int<2u, long>,
tree_node*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/function.c:837
0x827ea8 assign_temp(tree_node*, int, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/function.c:1057
0x6ccf2a expand_call(tree_node*, rtx_def*, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/calls.c:3459
0x7d108e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:10992
0x7df653 expand_normal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.h:285
0x7df653 store_field
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:6981
0x7dc7b8 expand_assignment(tree_node*, tree_node*, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:5276
0x6d9030 expand_call_stmt
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:2720
0x6d9030 expand_gimple_stmt_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:3685
0x6d9030 expand_gimple_stmt
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:3844
0x6db0ef expand_gimple_basic_block
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:5880
0x6e0546 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:6502

[Bug sanitizer/88619] New: [9 Regression] ICE in asan_emit_stack_protection, at asan.c:1574 since r266664

[marxin at gcc dot gnu.org]

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

Bug ID: 88619
   Summary: [9 Regression] ICE in asan_emit_stack_protection, at
asan.c:1574 since r24
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
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: ---

Following is causing ICE:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/stackalign/vararg-2.c
-fsanitize=address -fstack-protector
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/stackalign/vararg-2.c:
In function ‘test’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/stackalign/vararg-2.c:23:1:
internal compiler error: in asan_emit_stack_protection, at asan.c:1574
   23 | test (va_list arg)
  | ^~~~
0x696226 asan_emit_stack_protection(rtx_def*, rtx_def*, unsigned int, long*,
tree_node**, int)
/home/marxin/Programming/gcc/gcc/asan.c:1574
0x8e72bd expand_used_vars
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2282
0x8e8aab execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6369
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/88619] [9 Regression] ICE in asan_emit_stack_protection, at asan.c:1574 since r266664

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-27
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine.

[Bug rtl-optimization/88423] [9 Regression] ICE in begin_move_insn, at sched-ebb.c:175

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r262649 which is not culprit.

[Bug target/88618] New: ICE in extract_insn, at recog.c:2305

[marxin at gcc dot gnu.org]

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

Bug ID: 88618
   Summary: ICE in extract_insn, at recog.c:2305
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: ppc64-linux-gnu

Following is causing ICE:

$ cat ice.i
int a(int b) {
  __builtin_exp(b);
  __builtin_exp2(b);
  __builtin_expm1(b);
}

$ ppc64-linux-gnu-gcc -ffinite-math-only -fno-tree-forwprop -O2 ice.i -c
ice.i: In function ‘a’:
ice.i:5:1: error: unrecognizable insn:
5 | }
  | ^
(insn 12 11 13 2 (set (reg:DI 133)
(unlt:DI (reg:CCFP 132)
(const_int 0 [0]))) -1
 (nil))
during RTL pass: vregs
ice.i:5:1: internal compiler error: in extract_insn, at recog.c:2305
0x577c95 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/rtl-error.c:108
0x577cb1 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/rtl-error.c:116
0x57719e extract_insn(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/recog.c:2305
0x7cb57f instantiate_virtual_regs_in_insn
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/function.c:1650
0x7cb57f instantiate_virtual_regs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/function.c:2020
0x7cb57f execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/function.c:2069

[Bug target/88617] New: ICE in ix86_compute_frame_layout, at config/i386/i386.c:11238 since r248029

[marxin at gcc dot gnu.org]

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

Bug ID: 88617
   Summary: ICE in ix86_compute_frame_layout, at
config/i386/i386.c:11238 since r248029
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: uros at gcc dot gnu.org
  Target Milestone: ---

Started when -mcall-ms2sysv-xlogues was introduced:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80969-4.c
-mcall-ms2sysv-xlogues -fsanitize=thread -mavx512er
during RTL pass: reload
In file included from
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80969-4.c:9:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80969-4.h: In
function ‘bar’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80969-4.h:70:1:
internal compiler error: in ix86_compute_frame_layout, at
config/i386/i386.c:11238
   70 | }
  | ^
0x719b48 ix86_compute_frame_layout
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:11238
0xbade18 update_reg_eliminate
/home/marxin/Programming/gcc/gcc/lra-eliminations.c:1207
0xbb01b6 lra_eliminate(bool, bool)
/home/marxin/Programming/gcc/gcc/lra-eliminations.c:1460
0xba8c1a lra_constraints(bool)
/home/marxin/Programming/gcc/gcc/lra-constraints.c:4759
0xb9680c lra(_IO_FILE*)
/home/marxin/Programming/gcc/gcc/lra.c:2458
0xb4d151 do_reload
/home/marxin/Programming/gcc/gcc/ira.c:5475
0xb4d151 execute
/home/marxin/Programming/gcc/gcc/ira.c:5659

[Bug tree-optimization/88598] simplification of multiplication by 1 or 0 fails

[vincenzo.innocente at cern dot ch]

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

--- Comment #3 from vincenzo Innocente  ---
what I am interested in is NOT a constant array, more a small-size
"sparse"-matrix that I can build explicitly at run time from other sources.
I have examples using Eigen if of any interest ( https://godbolt.org/z/2L9OBU )
Clang is excellent in optimizing out zeros and ones, gcc in vectorization.
I hope to get the best of the two!

[Bug target/88616] New: ICE in gimplify_expr at gcc/gimplify.c:13363

[marxin at gcc dot gnu.org]

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

Bug ID: 88616
   Summary: ICE in gimplify_expr at gcc/gimplify.c:13363
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org, ramana at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: arm-linux-gnueabihf

Following is causing an ICE:

$ cat ice.ii
struct a {
  constexpr a() {}
} b;

$ arm-linux-gnueabi-gcc -Ofast ice.ii -c
ice.ii: In function ‘void __static_initialization_and_destruction_0(int, int)’:
ice.ii:3:3: internal compiler error: in gimplify_expr, at gimplify.c:13363
3 | } b;
  |   ^
0x5ab3ad gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:13363
0x940cf3 gimplify_modify_expr
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:5651
0x942d1b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:12402
0x9451b6 gimplify_stmt(tree_node**, gimple**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6685
0x94352a gimplify_cleanup_point_expr
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6428
0x94352a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:12779
0x9451b6 gimplify_stmt(tree_node**, gimple**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6685
0x942b2b gimplify_statement_list
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:1788
0x942b2b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:12831
0x9451b6 gimplify_stmt(tree_node**, gimple**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6685
0x9477a7 gimplify_cond_expr
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:4130
0x942ca0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:12359
0x9451b6 gimplify_stmt(tree_node**, gimple**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6685
0x9477a7 gimplify_cond_expr
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:4130
0x942ca0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:12359
0x9451b6 gimplify_stmt(tree_node**, gimple**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6685
0x9464b4 gimplify_body(tree_node*, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:13611
0x946735 gimplify_function_tree(tree_node*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:13755
0x7fceff cgraph_node::analyze()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cgraphunit.c:667
0x7ff527 analyze_functions
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cgraphunit.c:1126

[Bug target/88615] New: ICE in change_address_1, at emit-rtl.c:2286

[marxin at gcc dot gnu.org]

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

Bug ID: 88615
   Summary: ICE in change_address_1, at emit-rtl.c:2286
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: s390x-linux-gnu

Following is causing ICE:

$ s390x-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c -O2
-march=zEC12
during RTL pass: early_mach
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c: In function
‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c:12:1:
internal compiler error: in change_address_1, at emit-rtl.c:2286
   12 | }
  | ^
0x5532b9 change_address_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/emit-rtl.c:2286
0xcb27f1 annotate_constant_pool_refs_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8180
0xcb2655 annotate_constant_pool_refs_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8223
0xcb2655 annotate_constant_pool_refs_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8223
0xcc9d44 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:10653

[Bug target/88614] New: ICE: output_operand: invalid %z value

[marxin at gcc dot gnu.org]

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

Bug ID: 88614
   Summary: ICE: output_operand: invalid %z value
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: ppc64-linux-gnu

Caused by:

$ ppc64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/tls/run-ld.c -fno-plt
-mno-tls-markers
during RTL pass: final
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/tls/run-ld.c: In
function ‘get_ld’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/tls/run-ld.c:13:1:
internal compiler error: output_operand: invalid %z value
   13 | }
  | ^
0x79a8a3 output_operand_lossage(char const*, ...)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/final.c:3610
0x79abd1 output_operand(rtx_def*, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/final.c:4052
0x79b64b output_asm_insn(char const*, rtx_def**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/final.c:3945
0x79cc8c final_scan_insn_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/final.c:3107
0x79d138 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/final.c:3153
0x79d3fc final_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/final.c:2021
0x79de24 rest_of_handle_final
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/final.c:4659
0x79de24 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/final.c:4737

[Bug c++/88613] New: [9 Regression] ICE in size_binop_loc at fold-const.c:1900 since r267272

[marxin at gcc dot gnu.org]

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

Bug ID: 88613
   Summary: [9 Regression] ICE in size_binop_loc at
fold-const.c:1900 since r267272
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Starting from the revision I see:

$ cat ice.ii
void a() {
  const int b = 5;
  [=] {
if (b != 5)
  ;
  }();
}

$ g++ -Werror -fmax-errors=1 ice.ii -Wtautological-compare -c
ice.ii: In lambda function:
ice.ii:4:11: internal compiler error: Segmentation fault
4 | if (b != 5)
  | ~~^~~~
0xf30cdf crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:326
0x76bc310f ???
   
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xc55b68 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3289
0xc55b68 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
/home/marxin/Programming/gcc/gcc/fold-const.c:1900
0xcd21fc gimplify_compound_lval
/home/marxin/Programming/gcc/gcc/gimplify.c:2945
0xcc5f26 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:12354
0xcc5e8f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13133
0xcd255c gimplify_cond_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:4067
0xcc80c2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:12359
0xccebb6 gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:6685
0xcc7b53 gimplify_statement_list
/home/marxin/Programming/gcc/gcc/gimplify.c:1788
0xcc7b53 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:12831
0xccebb6 gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:6685
0xccf8fc gimplify_bind_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:1356
0xcc6e34 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:12603
0xccebb6 gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:6685
0xcd053f gimplify_body(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/gimplify.c:13611
0xcd0994 gimplify_function_tree(tree_node*)
/home/marxin/Programming/gcc/gcc/gimplify.c:13755
0xb406c7 cgraph_node::analyze()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:667
0xb43253 analyze_functions
/home/marxin/Programming/gcc/gcc/cgraphunit.c:1126

[Bug c++/88612] New: [9 Regression] Internal compiler error: Error reporting routines re-entered.

[marxin at gcc dot gnu.org]

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

Bug ID: 88612
   Summary: [9 Regression] Internal compiler error: Error
reporting routines re-entered.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

Following cross-compiler is causing a problem:

$ aarch64-linux-gnu-g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/decltype45.C
-fpack-struct -c
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/decltype45.C: In
substitution of ‘template decltype
(indirect_call(((VariadicBind*)this)->VariadicBind::f, ((VariadicBind*)this)->VariadicBind::t,
VariadicBind::operator()::a ...)) VariadicBind::operator()(A ...) [with A = {int}]’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/decltype45.C:5:46:  
required by substitution of ‘template decltype
(f(indirect_call::t ...)) indirect_call(F, T ...) [with F = VariadicBind; T = {int}]’
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/decltype45.C:17:52:  
required by substitution of ‘template decltype
(indirect_call(((VariadicBind,
int>*)this)->VariadicBind, int>::f,
((VariadicBind,
int>*)this)->VariadicBind, int>::t,
VariadicBind::operator()::a ...)) VariadicBind, int>::operator()(A ...) [with A = {}]’
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/decltype45.C:32:8:  
recursively required from ‘void apply(F, V1, V ...) [with F = VariadicBind; V1 = int; V = {}]’
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/decltype45.C:32:8:  
required from ‘void apply(F, V1, V ...) [with F = void (*)(int, int); V1 = int;
V = {int}]’
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/decltype45.C:39:19:  
required from here
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/decltype45.C:17:53:
warning: taking address of packed member of ‘VariadicBind’ may result in an unaligned pointer value [-Waddress-of-packed-member]
   17 |   auto operator()(A... a) -> decltype(indirect_call(f, t, a...))
  | ^
‘
Internal compiler error: Error reporting routines re-entered.
0x5fd3c6 convert_for_arg_passing(tree_node*, tree_node*, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/call.c:7633
0x6091a8 build_over_call
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/call.c:8215
0x60adb7 build_new_function_call(tree_node*, vec**, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/call.c:4407
0x71d298 finish_call_expr(tree_node*, vec**, bool,
bool, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/semantics.c:2568
0x6ff874 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/pt.c:18851
0x6f8887 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/pt.c:14991
0x6f8887 tsubst(tree_node*, tree_node*, int, tree_node*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/pt.c:14991
0x66ab2d dump_template_bindings
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/error.c:407
0x66ab2d dump_substitution
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/error.c:1538
0x66b00b dump_substitution
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/error.c:1531
0x66b00b dump_function_decl
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/error.c:1694
0x670a61 dump_decl
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/error.c:1094
0x670a61 decl_to_string
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/error.c:3070
0x670a61 cp_printer
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cp/error.c:4084
0x12bd07a pp_format(pretty_printer*, text_info*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/pretty-print.c:1390
0x12bd549 pp_format_verbatim(pretty_printer*, text_info*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/pretty-print.c:1452
0x12bd614 pp_verbatim(pretty_printer*, char const*, ...)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/pretty-print.c:1671
0x66992d print_instantiation_full_context
   
/home/ma

[Bug tree-optimization/88611] New: [9 Regression] ICE in eliminate_stmt, at tree-ssa-sccvn.c:5011

[marxin at gcc dot gnu.org]

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

Bug ID: 88611
   Summary: [9 Regression] ICE in eliminate_stmt, at
tree-ssa-sccvn.c:5011
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from r266742 I see:

$ gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/logical_temp_io_kind8.f90
-fno-tree-forwprop -O3 -fno-tree-ccp
during GIMPLE pass: fre
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/logical_temp_io_kind8.f90:6:0:

6 | program pr82869_8
  | 
internal compiler error: in eliminate_stmt, at tree-ssa-sccvn.c:5011
0xf31ebd eliminate_dom_walker::eliminate_stmt(basic_block_def*,
gimple_stmt_iterator*)
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:5011
0xf32197 eliminate_dom_walker::before_dom_children(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:5387
0xf32197 eliminate_dom_walker::before_dom_children(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:5320
0x155fb37 dom_walker::walk(basic_block_def*)
/home/marxin/Programming/gcc/gcc/domwalk.c:353
0xf29f3a eliminate_with_rpo_vn(bitmap_head*)
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:5565
0xf39a25 do_rpo_vn
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:6720
0xf3a69c execute
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:6789
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ada/88610] New: ICE with new ACATS test c452003

[simon at pushface dot org]

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

Bug ID: 88610
   Summary: ICE with new ACATS test c452003
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---
  Host: x86_64-apple-darwin15
Target: x86_64-apple-darwin15
 Build: x86_64-apple-darwin15

Created attachment 45290
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45290&action=edit
Demonstrator - to be gnatchopped

This test is new in ACATS 4.1K. It "checks that memberships of general 
access-to-object types work as defined when applied to anonymous 
access-to-tagged types".

With GCC 8.2.0 & GNAT CE 2018 the compilation gets stuck with no output.

GNAT CE 2018 on Debian is the same.

$ gnatmake c452003_root-child.adb
gcc -c c452003_root-child.adb
+===GNAT BUG DETECTED==+
| 9.0.0 20181103 (experimental) (x86_64-apple-darwin15) Assert_Failure
exp_util.adb:6824|
| Error detected at c452003_root-child.adb:32:14   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

c452003_root-child.adb
c452003_root-child.ads
c452003_root.ads

compilation abandoned

[Bug ipa/88561] [8/9 Regression] PGO devirtualization miscompilation of firefox

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Dec 27 12:33:00 2018
New Revision: 267433

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

2018-12-27  Martin Liska  

Backport from mainline
2018-12-15  Jan Hubicka  

PR ipa/88561
* ipa-polymorphic-call.c
(ipa_polymorphic_call_context::ipa_polymorphic_call_context): Handle
arguments of thunks correctly.
(ipa_polymorphic_call_context::get_dynamic_context): Be ready for
NULL instance pinter.
* lto-cgraph.c (lto_output_node): Always stream thunk info.
2018-12-27  Martin Liska  

Backport from mainline
2018-12-15  Jan Hubicka  

PR ipa/88561
* g++.dg/tree-prof/devirt.C: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-prof/devirt.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/ipa-polymorphic-call.c
branches/gcc-8-branch/gcc/lto-cgraph.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug ipa/88561] [8/9 Regression] PGO devirtualization miscompilation of firefox

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed on all active branches.

[Bug lto/88516] Internal LTO error when linking against static libSFML

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-12-27
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Note that LTO is invoked also for .a files, that I don't have.
Please send a link to git repo and steps how to reproduce the build.

[Bug gcov-profile/88608] error: corrupted profile info: profile data is not flow-consistent for unrar sources

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I bet it's dup, please use -fprofile-update=atomic.

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

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

--- Comment #47 from Martin Liška  ---
*** Bug 88608 has been marked as a duplicate of this bug. ***

[Bug ipa/88586] ICE: Segmentation fault (in free_lang_data_in_decl)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Just for the record, it started with r265930.

[Bug ipa/88585] [9 Regression] ICE in fld_incomplete_type_of, at tree.c:5295

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-27
  Known to work||8.2.0
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Started with r265870, Honza can you please take a look?

[Bug tree-optimization/88598] simplification of multiplication by 1 or 0 fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I think I had a patch for that kind of thing, see
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01559.html , but Richi wanted to
do it differently if I remember well.  In any case, the patch didn't handle
RANGE_EXPRs efficiently, and it would be nice if we canonicalized ctors like {
1, 1, 1, 1, 1, 1, 1 } into { [0..6] = 1 }.

[Bug lto/88550] A compiler error when use lto: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:155

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
> And I also got the .cgraph file, it too large(more than 141MB), and I've
> found these lines in the end of file:
> 

Please upload the file to some location like Google Drive, or a file sharing
server.

[Bug libstdc++/88607] forward_list.h contains utf-8 charactor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
If we want to guarantee the headers are ASCII only, then there are various
other issues:
for i in `find include libsupc++ -type f`; do iconv -f ASCII// -t ASCII// $i >
/dev/null || echo $i; done
iconv: illegal input sequence at position 11055
include/debug/forward_list
iconv: illegal input sequence at position 1518
include/experimental/tuple
iconv: illegal input sequence at position 1563
include/experimental/ratio
iconv: illegal input sequence at position 1587
include/experimental/chrono
iconv: illegal input sequence at position 1662
include/experimental/type_traits
iconv: illegal input sequence at position 2063
include/experimental/memory
iconv: illegal input sequence at position 5193
include/experimental/bits/shared_ptr.h
iconv: illegal input sequence at position 1736
include/experimental/functional
iconv: illegal input sequence at position 1598
include/experimental/system_error
iconv: illegal input sequence at position 46508
include/std/future
iconv: illegal input sequence at position 25042
include/bits/forward_list.h
iconv: illegal input sequence at position 1448
include/tr2/bool_set
iconv: illegal input sequence at position 1357
include/parallel/workstealing.h
iconv: illegal input sequence at position 1491
include/parallel/multiseq_selection.h

[Bug lto/88081] [7/8/9 Regression] ICE in lto_varpool_replace_node, at lto/lto-symtab.c:109

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Ah, sorry, I misunderstood. Got fixed on trunk in your r266315.

[Bug lto/88081] [7/8/9 Regression] ICE in lto_varpool_replace_node, at lto/lto-symtab.c:109

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
For me it works in trunk, so it would be nice to know when it went away.

[Bug lto/88081] [7/8/9 Regression] ICE in lto_varpool_replace_node, at lto/lto-symtab.c:109

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
I see the bug as old one:

  4.9.4 (d3191480f376c780)(03 Aug 2016 05:07): [took: 1.910s] result: FAILED
(1)
2.ii:9:7: warning: type of ‘_ZTVN10__cxxabiv117__class_type_infoE’ does not
match original declaration
 class __class_type_info : a {};
   ^
1.ii:10:7: note: previously declared here
 class __class_type_info : a {};
   ^
/usr/bin/ld: /usr/lib/../lib64/crt1.o: in function `_start':
/home/abuild/rpmbuild/BUILD/glibc-2.27/csu/../sysdeps/x86_64/start.S:104:
undefined reference to `main'
collect2: error: ld returned 1 exit status
  5.1.0 (d5ad84b309d0d97d)(22 Apr 2015 08:43): [took: 2.113s] result: FAILED
(1)
lto1: internal compiler error: in lto_varpool_replace_node, at
lto/lto-symtab.c:143
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

What do you want to bisect precisely Honza?

[Bug web/86315] Bugzilla: add "cc count" and "duplicate count" columns

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
If needed I can also help with maintaining of that for the future..

[Bug target/88609] New: [avr] ice: insn does not satisfy its constraints while building libgcc

[dinuxbg at gmail dot com]

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

Bug ID: 88609
   Summary: [avr] ice: insn does not satisfy its constraints while
building libgcc
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dinuxbg at gmail dot com
CC: avr at gjlay dot de, chertykov at gmail dot com
  Target Milestone: ---
  Host: x86_64
Target: avr
 Build: x86_64

I noticed that libgcc for avr in current master (r267421) cannot be built due
to internal compiler error.

$ /home/dinux/projects/avr/testbot-workspace/gcc-build/./gcc/xgcc
-B/home/dinux/projects/avr/testbot-workspace/gcc-build/./gcc/
-B/home/dinux/projects/avr/testbot-workspace/opt/avr/bin/
-B/home/dinux/projects/avr/testbot-workspace/opt/avr/lib/ -isystem
/home/dinux/projects/avr/testbot-workspace/opt/avr/include -isystem
/home/dinux/projects/avr/testbot-workspace/opt/avr/sys-include-g -O2
-mmcu=avr25 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -DDF=SF
-Dinhibit_libc -mcall-prologues -Os -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -DDF=SF -Dinhibit_libc -mcall-prologues
-Os -I. -I. -I../../.././gcc
-I/home/dinux/projects/avr/testbot-workspace/gcc/libgcc
-I/home/dinux/projects/avr/testbot-workspace/gcc/libgcc/.
-I/home/dinux/projects/avr/testbot-workspace/gcc/libgcc/../gcc
-I/home/dinux/projects/avr/testbot-workspace/gcc/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o _divsc3.o -MT _divsc3.o -MD -MP -MF _divsc3.dep
-DL_divsc3 -c /home/dinux/projects/avr/testbot-workspace/gcc/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
/home/dinux/projects/avr/testbot-workspace/gcc/libgcc/libgcc2.c: In function
'__divsc3':
/home/dinux/projects/avr/testbot-workspace/gcc/libgcc/libgcc2.c:2089:1: error:
insn does not satisfy its constraints:
 2089 | }
  | ^
(jump_insn 1579 17 23 2 (set (pc)
(if_then_else (eq (zero_extract:HI (reg:QI 24 r24 [205])
(const_int 1 [0x1])
(const_int 7 [0x7]))
(const_int 0 [0]))
(label_ref 675)
(pc)))
"/home/dinux/projects/avr/testbot-workspace/gcc/libgcc/libgcc2.c":2046:6 154
{*addsi3.lt0}
 (nil)
 -> 675)
during RTL pass: cprop_hardreg
/home/dinux/projects/avr/testbot-workspace/gcc/libgcc/libgcc2.c:2089:1:
internal compiler error: in extract_constrain_insn, at recog.c:2206
0x5f31ab _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/dinux/projects/avr/testbot-workspace/gcc/gcc/rtl-error.c:108
0x5f31d1 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/dinux/projects/avr/testbot-workspace/gcc/gcc/rtl-error.c:118
0x5f18db extract_constrain_insn(rtx_insn*)
/home/dinux/projects/avr/testbot-workspace/gcc/gcc/recog.c:2206
0xbb6000 copyprop_hardreg_forward_1
/home/dinux/projects/avr/testbot-workspace/gcc/gcc/regcprop.c:801
0xbb6d4c execute
/home/dinux/projects/avr/testbot-workspace/gcc/gcc/regcprop.c:1307


Here is the script I'm using to build the avr toolchain:
https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-avr.sh

The gcc config line I've used: 
   --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp
--with-dwarf2

[Bug gcov-profile/88608] New: error: corrupted profile info: profile data is not flow-consistent for unrar sources

[aros at gmx dot com]

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

Bug ID: 88608
   Summary: error: corrupted profile info: profile data is not
flow-consistent for unrar sources
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aros at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

I'm trying to compile unrar sources (
https://rarlab.com/rar/unrarsrc-5.6.8.tar.gz ) using -flto and
-fprofile-generate/use.

Here's what I get:

threadpool.cpp: In member function
‘ThreadPool::GetQueuedTask(ThreadPool::QueueEntry*)’:
threadpool.cpp:213:1: error: corrupted profile info: profile data is not
flow-consistent
 }
 ^
threadpool.cpp:213:1: error: corrupted profile info: number of executions for
edge 7-11 thought to be -4
threadpool.cpp:213:1: error: corrupted profile info: number of executions for
edge 7-8 thought to be 8272
threadpool.cpp: At top level:

make: *** [makefile:132: threadpool.o] Error 1
make: *** Waiting for unfinished jobs
unpack.cpp: In member function ‘Unpack::MakeDecodeTables(unsigned char*,
DecodeTable*, unsigned int)’:
unpack.cpp:354:1: error: corrupted profile info: profile data is not
flow-consistent
 }
 ^
unpack.cpp:354:1: error: corrupted profile info: number of executions for edge
14-16 thought to be -9
unpack.cpp:354:1: error: corrupted profile info: number of executions for edge
14-15 thought to be 17391
unpack.cpp: At top level:

make: *** [makefile:132: unpack.o] Error 1

Run make to see the errors.

GCC: gcc-8.2.1-6.fc29.x86_64.
CPU: Intel Core i5 2500.
Linux: Fedora 29 64.

[Bug sanitizer/86229] ASAN Reports "alloc-dealloc mismatch" intsead of "attempted delete without new"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed on trunk, not planning to backport.

[Bug sanitizer/86229] ASAN Reports "alloc-dealloc mismatch" intsead of "attempted delete without new"

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Dec 27 09:47:20 2018
New Revision: 267432

URL: https://gcc.gnu.org/viewcvs?rev=267432&root=gcc&view=rev
Log:
Cherry pick libsanitizer patch (https://reviews.llvm.org/D54856).

2018-12-27  Martin Liska  

  PR sanitizer/86229
* asan/asan_errors.cc (ErrorAllocTypeMismatch::Print): Cherry
pick rL350085.
* asan/asan_errors.h (struct ErrorAllocTypeMismatch): Likewise.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/asan/asan_errors.cc
trunk/libsanitizer/asan/asan_errors.h

[Bug driver/81519] Enhancement: Add --help=target-distcc or similar to dump clean, optimal CFLAGS without using -march=native

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX
   Severity|normal  |enhancement

--- Comment #12 from Martin Liška  ---
Let me close that as won't fix.

[Bug sanitizer/88260] c++ code instrumented with address sanitizer crashes

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Martin Liška  ---
As there's no reply I'm closing as that as invalid. Feel free to reopen if
really present.

[Bug gcov-profile/88225] Slowness in gcov

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Dec 27 08:59:35 2018
New Revision: 267431

URL: https://gcc.gnu.org/viewcvs?rev=267431&root=gcc&view=rev
Log:
Fix slowness in gcov (PR gcov-profile/88225).

2018-12-27  Martin Liska  

PR gcov-profile/88225
* gcov.c(source_info::get_functions_at_location):
Use newly added line_to_function_map.
(source_info::add_function): New.
(output_json_intermediate_file): Use a pointer return
type for get_functions_at_location.
(process_all_functions): Use add_function instead
of direct push to a s->functions container.
(release_structures): Release ident_to_fn.
(read_graph_file): Register function into ident_to_fn.
(read_count_file): Use the map.
(output_lines): Handle pointer return type of
get_functions_at_location.

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

[Bug gcov-profile/88225] Slowness in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug c++/88263] ICE in coverage_begin_function

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug c++/88263] ICE in coverage_begin_function

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Thu Dec 27 08:46:13 2018
New Revision: 267429

URL: https://gcc.gnu.org/viewcvs?rev=267429&root=gcc&view=rev
Log:
Use proper location for tls_init function (PR c++/88263).

2018-12-27  Martin Liska  

PR c++/88263
* decl2.c (get_local_tls_init_fn): Add location_t argument and
use it.
(get_tls_init_fn): Call it with location of variable for which
we'll need to create tls_init function.
(handle_tls_init): Likewise.
2018-12-27  Martin Liska  

PR c++/88263
* g++.dg/gcov/pr88263.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/gcov/pr88263.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88607] New: forward_list.h contains utf-8 charactor

[fudou...@m-japan.co.jp]

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

Bug ID: 88607
   Summary: forward_list.h contains utf-8 charactor
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fudou...@m-japan.co.jp
  Target Milestone: ---

in forward_list.h line 783 
// 23.3.4.5 modifiers:

the "fi" is actually a UTF-8 charactor
therefore compile with -finput-charset fails

[Bug tree-optimization/88440] size optimization of memcpy-like code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/88440] size optimization of memcpy-like code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Sure, I can help with measurements during next stage1. Can you please Richi
attach a patch that will enable the optimization for -O[2s]?