[Bug middle-end/69526] ivopts candidate strangeness

[rdapp at linux dot vnet.ibm.com]

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

rdapp at linux dot vnet.ibm.com changed:

   What|Removed |Added

Version|6.0 |unknown

--- Comment #21 from rdapp at linux dot vnet.ibm.com ---
(In reply to amker from comment #20)
> IIUC we can simply handle signed/unsigned type differently.  Given a has
> int/uint type. 
> For unsigned case: (unsigned long long)(a + cst1) + cst2  and a is unsigned
> int.
> It can be simplified into (unsigned long long)a + cst3 iff a + cst1 doesn't
> overflow/wrap.  Since unsigned type can wrap, simplify (unsigned long
> long)cst1 + cst2 into cst3 is always safe.
> For signed case: (long long)(a + cst) + cst2  and a is signed int.
> It can be simplified into (long long)a + cst3 iff (long long)cst1 + cst2
> doesn't overflow.  We don't need to prove (a+cst) doesn't overflow.

ok, the stipulation seems to be assume no signed overflow if the operation was
already present but don't provoke a potentially new overflow by combining
constants that previously would not have been. Makes sense. Your cases can be
improved a little as Richard also pointed out: When abs(cst3) < abs(cst1) the
combined operation can be done in the inner type (and the signs match so the
overflow proof still holds).

[Bug c++/71639] [5.2.0] c++11 list initializer and std::transform - error?

[frank67x at gmail dot com]

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

--- Comment #5 from Frank Bergemann  ---
I also tested on HP-UX with gcc-4.7.2.

HP-UX ### B.11.31 U ia64 4035416745 unlimited-user license

And it's also ok on HP-UX:

hpux03 506> ./test

using push_back():
==
1, 2, 3, 4, 5, 
1, 2, 3, 4, 5, 2, 4, 6, 8, 10, 

using initializer list:
===
1, 2, 3, 4, 5, 
1, 2, 3, 4, 5, 2, 4, 6, 8, 10,

[Bug c++/71639] [5.2.0] c++11 list initializer and std::transform - error?

[frank67x at gmail dot com]

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

--- Comment #4 from Frank Bergemann  ---
The problem is on Linux

Linux ### 2.6.32-358.55.1.el6.x86_64 #1 SMP Tue Dec 16 06:57:07 EST 2014 x86_64
x86_64 x86_64 GNU/Linux

\Frank

[Bug c++/71639] [5.2.0] c++11 list initializer and std::transform - error?

[frank67x at gmail dot com]

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

--- Comment #3 from Frank Bergemann  ---
But on solaris i only had gcc-4.7.2 yet

\Frank

[Bug c++/71639] [5.2.0] c++11 list initializer and std::transform - error?

[frank67x at gmail dot com]

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

--- Comment #2 from Frank Bergemann  ---
it works on Solaris 5.10

SunOS ### 5.10 Generic_142900-05 sun4u sparc SUNW,Sun-Fire-V890

\Frank

[Bug c++/71639] [5.2.0] c++11 list initializer and std::transform - error?

[frank67x at gmail dot com]

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

--- Comment #1 from Frank Bergemann  ---
Created attachment 38754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38754=edit
test program main.cpp

[Bug c++/71639] New: [5.2.0] c++11 list initializer and std::transform - error?

[frank67x at gmail dot com]

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

Bug ID: 71639
   Summary: [5.2.0] c++11 list initializer and std::transform -
error?
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frank67x at gmail dot com
  Target Milestone: ---

i have a strange result, when i apply std::transform with std::back_inserter to
a std::vector, that was initialized with c++11 list initializer.

main.cpp test program will be attached next.
Output for me is:
--
padps08 1249> ./test

using push_back():
==
1, 2, 3, 4, 5, 
1, 2, 3, 4, 5, 2, 4, 6, 8, 10, 

using initializer list:
===
1, 2, 3, 4, 5, 
1, 2, 3, 4, 5, 2, 0, 6, 8, 10, 
--

i compiled this way:

> g++ -o test main.cpp -std=c++11

I have the same problem with 5.4.0.

best regards,
Frank

[Bug libfortran/48925] Code cleanup in write_float.def

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #7 from Jerry DeLisle  ---
Fixed, closing, see commit for pr48852

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852
Bug 48852 depends on bug 48925, which changed state.

Bug 48925 Summary: Code cleanup in write_float.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48925

   What|Removed |Added

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

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #18 from Jerry DeLisle  ---
fixed, closing

[Bug c++/71638] New: ICE on x86_64-linux-gnu with -Wall (internal compiler error: non-constant element in constant CONSTRUCTOR)

[chengniansun at gmail dot com]

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

Bug ID: 71638
   Summary: ICE on x86_64-linux-gnu with -Wall (internal compiler
error: non-constant element in constant CONSTRUCTOR)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$: g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160623 (experimental) [trunk revision 237733] (GCC) 
$: 
$: g++-trunk -Wall small.C
small.C:3:13: error: invalid conversion from ‘A::*’ to ‘int’
[-fpermissive]
 int j = this;
 ^~~~
small.C: In function ‘void f(A)’:
small.C:9:8: internal compiler error: non-constant element in constant
CONSTRUCTOR
   f(A{});
^
0x103f5bb verify_constructor_flags(tree_node*)
../../gcc-source-trunk/gcc/tree.c:1830
0x8aac29 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3945
0x8aad18 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:4092
0x8ab4ce cxx_eval_indirect_ref
../../gcc-source-trunk/gcc/cp/constexpr.c:2944
0x8ab4ce cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3771
0x8af369 cxx_eval_component_reference
../../gcc-source-trunk/gcc/cp/constexpr.c:2153
0x8ab7a8 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3923
0x8af369 cxx_eval_component_reference
../../gcc-source-trunk/gcc/cp/constexpr.c:2153
0x8ab7a8 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3923
0x8b0074 cxx_eval_bare_aggregate
../../gcc-source-trunk/gcc/cp/constexpr.c:2485
0x8aac62 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3952
0x8ab28c cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3694
0x8aadfa cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3779
0x8aa86b cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3981
0x8b1419 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:4211
0x8b4278 maybe_constant_value_1
../../gcc-source-trunk/gcc/cp/constexpr.c:4405
0x8b4278 maybe_constant_value(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:4429
0x66bcf2 build_over_call
../../gcc-source-trunk/gcc/cp/call.c:7648
0x6778d1 build_new_method_call_1
../../gcc-source-trunk/gcc/cp/call.c:8515
0x6778d1 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
../../gcc-source-trunk/gcc/cp/call.c:8585
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: 
$: cat small.C
struct A {
  struct {
int j = this;
  } b;
  int a = b.j;
};

void f(A) { 
  f(A{}); 
}

[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic, easyhack
   Last reconfirmed|2014-06-10 00:00:00 |2016-6-23

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Fredrik Hallenberg from comment #6)
> Reconfirmed with gcc 6.1.1

I don't think anything will change until someone volunteers to debug and
propose a fix: https://gcc.gnu.org/wiki/DebuggingGCC

The problem is in c-family/c-ppoutput.c

It seems print.prev_was_system_token is not always correctly updated. In
particular, we may call do_line_change at various places and emit a sysp
linemarker in print_line_1, but then not update print.prev_was_system_token. It
only makes sense to update its value within this function, so it is
synchronized with the corresponding linemarkers.

[Bug middle-end/69526] ivopts candidate strangeness

[amker at gcc dot gnu.org]

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

--- Comment #20 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #19)
> (In reply to rguent...@suse.de from comment #18)
> >
> 
> The match.pd patch is slowly assuming shape... Two things however I'm still
> unsure about:
> 
> 1.
> An existing rule in match.pd checks for overflow of the combined constant
> in (a +- CST1) +- CST2 and does not perform the simplification when an
> overflow occurs. My case looks quite similar, however CST1 and CST2
> are/might be unsigned ints/longs. I assume this is because non-overflow
> cannot be proved by the C frontend and it therefore internally uses unsigned
> representation?
> 
> (cast) (a +- CST1) +- CST2
> 
> We can prove the non-overflow of (a +- CST1) via VRP but an overflow check
> of (CST1 +- CST2) would fail since ((UINT_MAX - 1) + 1) does overflow.
IIUC we can simply handle signed/unsigned type differently.  Given a has
int/uint type. 
For unsigned case: (unsigned long long)(a + cst1) + cst2  and a is unsigned
int.
It can be simplified into (unsigned long long)a + cst3 iff a + cst1 doesn't
overflow/wrap.  Since unsigned type can wrap, simplify (unsigned long long)cst1
+ cst2 into cst3 is always safe.
For signed case: (long long)(a + cst) + cst2  and a is signed int.
It can be simplified into (long long)a + cst3 iff (long long)cst1 + cst2
doesn't overflow.  We don't need to prove (a+cst) doesn't overflow.
> 
> So, in general, should we care about overflow of the combined operation at
> all after having established the inner operation does not overflow?
> If the overflow is well-defined and we overflow, the result should be valid.
> If the overflow is undefined, we could do anything, in particular optimize
> this which wouldn't even be too unexpected from a user's perspective.
> Wouldn't any overflow in the combined constant be caused anyway, even
> without combining?
> 
> I think there are only two cases two discern, regardless of overflow:
>  
>  - abs(CST1 +- CST2) < abs(CST1), then we can simplify to (cast)(a +- (CST1
> +- CST2))
> 
>  - else, we can simplify to (cast)(a) +- (CST1 +- CST2)
> 
> 2.
> Is there an idiomatic/correct way to check a VR_RANGE for overflow? Does it
> suffice to check if the range includes +-INF or +-INF(OVF)? I suspect other,
> naive methods like checking if min < max will fail, since the ranges are
> canonicalized.

[Bug c++/71637] -Wmisleading-indentation only triggered when using integrated cpp

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-23
 CC||dmalcolm at gcc dot gnu.org,
   ||manu at gcc dot gnu.org
  Component|preprocessor|c++
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
It actually produces:

prog.cc: In function 'int main()':
prog.cc:6:5: warning: this 'else' clause does not guard...
[-Wmisleading-indentation]
 m(0);
 ^
prog.cc:6:5: note: ...this statement, but the latter is misleadingly indented
as if it is guarded by the 'else'

and the fact that both diagnostics are given at the same location is
suspicious. The warning code should be able to tell that something wrong
happened there and avoid warning.

[Bug middle-end/71585] Cannot selectively disable stack protector with LTO

[js at alien8 dot de]

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

--- Comment #3 from Julian Stecklina  ---
Is there the hope of having at least workaround here?

[Bug preprocessor/71637] New: -Wmisleading-indentation only triggered when using integrated cpp

[megahallon at gmail dot com]

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

Bug ID: 71637
   Summary: -Wmisleading-indentation only triggered when using
integrated cpp
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: megahallon at gmail dot com
  Target Milestone: ---

The following program:

---
#define m(x) ({ int y; if (x) y=0; else y=1; y; })

int main()
{
  int x =
m(0);
  return x;
}

---

compiled with:

gcc -ftrack-macro-expansion=0 -Wmisleading-indentation test.c

Gives a warning:

test.c:6:5: warning: this ‘else’ clause does not guard...
[-Wmisleading-indentation]
 m(0);
 ^

Which is possibly as expected given no macro expansion tracking, however when
trying to check the output with -save-temps (or using -no-integrated-cpp) the
warning is not issued making it difficult to understand what is going on.

This is extra confusing when using ccache (or similar system working on
preprocessed files) and -Werror as a ccache build will work, while not using
ccache will fail. By the way, ccache is also the reason to use
-ftrack-macro-expansion=0, see bug 60014.

gcc version 6.1.1 20160620 (Debian 6.1.1-7)

[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer

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

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #2 from Gerhard Steinmetz  
---
Replacing "size" with synonym "product(shape)" unveils an uninitialized value.


$ cat z2.f90
program p
  implicit none
  character(len=:), allocatable :: string
  integer, dimension(4), target :: array = [1,2,3,4]
  integer, dimension(:), pointer :: array_ptr
  integer :: ptr_size
  array_ptr => array
  ptr_size = size(array_ptr)

  print *, size(array_ptr)
  print *, product(shape(array_ptr))

  allocate (character(len=product(shape(array_ptr))) :: string)

  print *, len(string)
end


$ gfortran-6 -g -O0 -Wall -fcheck=all -ftrapv z2.f90
z2.f90:13:0:

   allocate (character(len=product(shape(array_ptr))) :: string)

Warning: 'val.7' may be used uninitialized in this function
[-Wmaybe-uninitialized]
z2.f90:13:0: Warning: '.string' may be used uninitialized in this function
[-Wmaybe-uninitialized]


$ a.out
   4
   4
   682229200

$ a.out
   4
   4
  1947807840

$ a.out
   4
   4
 -1207271008

[Bug fortran/57284] [OOP] ICE with find_array_spec for polymorphic arrays

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

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #7 from Gerhard Steinmetz  
---
Compiles if "size" is replaced with synonym "product(shape)".


$ cat z5.f90
module m
  type t
  end type
contains
  function foo(a, b) result(add)
class(t), intent(in) :: a(:)
class(t), intent(in) :: b(product(shape(a)))
type(t) :: add(product(shape(a)))
  end function
end module

program p
  use m
end program

$ gfortran-6 -g -O0 -fcheck=all z5.f90



$ cat z6.f90
module m
  type t
  end type
contains
  function foo(a, b) result(add)
class(*), intent(in) :: a(:)
class(*), intent(in) :: b(product(shape(a)))
type(t) :: add(product(shape(a)))
  end function
end module

program p
  use m
end program

$ gfortran-6 -g -O0 -fcheck=all z6.f90



Remark:
This workaround may or may not work for production codes, it depends.

[Bug fortran/55501] [F03] ICE using MERGE in constant expr

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

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #16 from Gerhard Steinmetz  
---
Update, running test from comment 13 :

$ gfortran-7 testmerge3.f90
testmerge3.f90:3:0:

   print "(a,99i2)",'i,iarray =',i,iarray

internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:6737



It works with a separated extra parameter :

$ cat z1.f90
program p
  integer, parameter :: n = merge(2,3,.true.)
  integer, parameter :: iarray(n) = 1, i = size(iarray)
  print "(a,99i2)",'i,iarray =',i,iarray
end

$ gfortran-6 -g -O0 -Wall -fcheck=all z1.f90
$ a.out
i,iarray = 2 1 1

[Bug tree-optimization/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization

--- Comment #13 from Uroš Bizjak  ---
Vectorizer PRs should be filled having tree-optimization component field.

[Bug rtl-optimization/71636] Missed optimization in variable alignment test

[rth at gcc dot gnu.org]

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

--- Comment #1 from Richard Henderson  ---
Oh, and I meant to mention -- if the target doesn't have an andnot
insn, both formulations are identical in complexity and minimal path.

Which might suggest *always* performing the transformation at a
high level, letting the andnot be used if it happens to be available.

[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch

[thiago at kde dot org]

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

--- Comment #10 from Thiago Macieira  ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Markus Trippelsdorf from comment #8)
> > Thiago, if you can parse Jakub's suggestion from comment 3 (I can't), you
> > could give it a try.
> 
> The intent was to see 1 preprocessed file attached (the header) which is
> compiled into pch, and then one semi-preprocessed file (preprocessed, with
> the first header unincluded) + 2 command lines.

I understand. I've done this before, but it takes a lot of scripting to figure
out which header to precompile and then creduce the header, then the source, to
trigger this error.

Considering I am using 6.1.1 and this problem does not exist for me, I simply
can't afford the time. Maybe Ubuntu folks that are still deploying GCC 5.3.1
can pick up the effort.

[Bug rtl-optimization/71636] New: Missed optimization in variable alignment test

[rth at gcc dot gnu.org]

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

Bug ID: 71636
   Summary: Missed optimization in variable alignment test
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

The following functions are equivalent,

unsigned f(unsigned x, unsigned b)
{
  return x & ((1U << b) - 1);
}

unsigned g(unsigned x, unsigned b)
{
  return x & ~(~0U << b);
}

If the target has an andnot insn, G is shorter:

aarch64:
f:  mov w2, 1
lsl w1, w2, w1
sub w2, w1, #1
and w0, w2, w0

g:  mov w2, -1
lsl w1, w2, w1
bic w0, w0, w1


x86_64 (-march=haswell):
f:  movl$1, %edx
shlx%esi, %edx, %eax
subl$1, %eax
andl%edi, %eax

g:  movl$-1, %edx
shlx%esi, %edx, %esi
andn%edi, %esi, %eax

[Bug middle-end/71625] missing strlen optimization on different array initialization style

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #4)
> I'm working on a patch that among other things transforms the CONSTRUCTOR
> node created for an array initializer to STRING_CST, as suggested by Richard
> in bug 71303 that this one is a duplicate of, to help fold strlen results
> for constant arguments (this also affects C++ constexpr where it would be
> useful to be able to call strlen).  Let me confirm this one since it has
> more discussion and close the other as a dupe.

That will be certainly useful not just for this, but also for the generated
code quality if it can't/shouldn't be optimized into constant (the usual case).

But,
int baz ()
{
  char a[4];
  a[0] = 'a';
  a[1] = 'b';
  a[2] = 'c';
  a[3] = '\0';
  return __builtin_strlen (a); 
}
still won't be optimized.  Not sure if it is worth to do something about it
though.  It can as well have the form
int baz2 ()
{
  char a[30];
  __builtin_memcpy (a, "1234567", 7);
  __builtin_memcpy (a + 7, "89abcdefg", 9);
  __builtin_memcpy (a + 16, "h", 2);
  return __builtin_strlen (a);
}
which isn't optimized either and would also need the notion of length > N.
Surprisingly
int baz3 ()
{
  char a[30];
  __builtin_memcpy (a, "1234567", 8);
  __builtin_memcpy (a + 7, "89abcdefg", 10);
  __builtin_memcpy (a + 16, "h", 2);
  return __builtin_strlen (a);
}
isn't optimized either.

[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

[megahallon at gmail dot com]

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

--- Comment #6 from Fredrik Hallenberg  ---
Reconfirmed with gcc 6.1.1

[Bug middle-end/71625] missing strlen optimization on different array initialization style

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Marc Glisse from comment #1)
> (In reply to Renlin Li from comment #0)
> >   char array[] = "abc";
> >   return __builtin_strlen (array);
> 
> There are DUPs for this part.

Well, this actually is optimized.

GCC is able to fold strlen of a string literal very early, but the rest is done
in the strlen pass.  For foo, there is:
  array = "abc";
  _1 = __builtin_strlen ();
where we can easily compute the string length of the rhs and copy it over to
the lhs (array).
In bar, we have instead:
  array[0] = 97;
  array[1] = 98;
  array[2] = 99;
  array[3] = 0;
  _1 = __builtin_strlen ();
and right now, the strlen pass only handles the various string/memory builtins
plus stores of zero.  For this to work, we'd need to also instrument scalar
stores of non-zero values, and record some transitive string length > N rather
than string length equals to N, so for the array[0] = 97; store we'd record
string length at [0] is > 0, for array[1] = 98; update that record to say
> 1, then > 2.

> Here it depends if we produce:
> 
> size_t tmp1=hallo();
> size_t tmp2=strlen(array);
> return tmp1+tmp2;
> 
> or use the reverse order for tmp1 and tmp2. Currently we evaluate a before b
> in a+b, this example seems to suggest that when one sub-expression is pure
> and not the other, it would make sense to evaluate the pure one first
> (assuming we can determine that information early enough). It also depends
> where the C++ proposal about order of evaluation is going...
> 
> Or we could do like clang and improve alias analysis. We should know that
> array doesn't escape and thus that hallo() cannot write to it.

The strlen pass uses the alias oracle, so the question is why it thinks the
call might affect the array.

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[uros at gcc dot gnu.org]

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

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jun 23 16:58:54 2016
New Revision: 237738

URL: https://gcc.gnu.org/viewcvs?rev=237738=gcc=rev
Log:
PR tree-optimization/71488
* gcc.target/i386/i386.exp (check_effective_target_sse4): Move to ...
* lib/target-supports.exp: ... here.
(check_sse4_hw_available): New procedure.
(check_effective_target_sse4_runtime): Ditto.
* g++.dg/pr71488.C (dg-additional-options): Use -msse4 instead of
-march=westmere for sse4_runtime targets.
* gcc.dg/vect/vect-bool-cmp.c: Include "tree-vect.h".
(dg-additional-options): Use for sse4_runtime targets.
(main): Call check_vect ().
(dg-final): Perform scan only for sse4_runtime targets.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/pr71488.C
trunk/gcc/testsuite/gcc.dg/vect/vect-bool-cmp.c
trunk/gcc/testsuite/gcc.target/i386/i386.exp
trunk/gcc/testsuite/lib/target-supports.exp

[Bug target/67400] -fno-plt doesn't work with function pointers

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Jun 23 16:30:43 2016
New Revision: 237736

URL: https://gcc.gnu.org/viewcvs?rev=237736=gcc=rev
Log:
i386: Access external function via GOT slot for -fno-plt

i386 psABI has been updated to clarify that R_386_GOT32X and R_386_GOT32
relocations can be used to access GOT without base register when PIC is
disabled:

https://groups.google.com/forum/#!topic/ia32-abi/awsRSvJOJfs

32-bit x86 assembler and linker from binutils 2.26.1 and 2.27 support

call/jmp *_start@GOT
cmpl $0, bar@GOT

for both normal and IFUNC functions.  We check if 32-bit x86 assembler
and linker have the fix for:

https://sourceware.org/bugzilla/show_bug.cgi?id=20244

before accessing external function via GOT slot for -fno-plt in both PIC
and non-PIC modes.

PR target/66232
PR target/67400
* configure.ac (as_ix86_tls_ldm_opt): Renamed to ...
(as_ix86_gas_32_opt): This.
(ld_ix86_tls_ldm_opt): Renamed to ...
(ld_ix86_gld_32_opt): This.
(R_386_TLS_LDM reloc): Updated.
(R_386_GOT32X reloc): New assembler/linker check.
(HAVE_AS_IX86_GOT32X): New.  Defined to 1 if 32-bit assembler and
linker support "jmp *_start@GOT" and "cmpl $0, bar@GOT".  Otherise,
defined to 0.
* config.in: Regenerated.
* configure: Likewise.
* config/i386/i386.c (ix86_force_load_from_GOT_p): Return
true if HAVE_AS_IX86_GOT32X is 1 in 32-bit mode.
(ix86_legitimate_address_p): Allow UNSPEC_GOT for -fno-plt
if ix86_force_load_from_GOT_p returns true.
(ix86_print_operand_address_as): Also support UNSPEC_GOT if
ix86_force_load_from_GOT_p returns true.
(ix86_expand_move): Generate UNSPEC_GOT in 32-bit mode to load
the external function address via the GOT slot.
(ix86_nopic_noplt_attribute_p): Check both TARGET_64BIT and
HAVE_AS_IX86_GOT32X before returning false.
(ix86_output_call_insn): Generate "%!jmp/call\t*%p0@GOT" in
32-bit mode if ix86_nopic_noplt_attribute_p returns true.

gcc/testsuite/

PR target/66232
PR target/67400
* gcc.target/i386/pr66232-14.c: New file.
* gcc.target/i386/pr66232-15.c: Likewise.
* gcc.target/i386/pr66232-16.c: Likewise.
* gcc.target/i386/pr66232-17.c: Likewise.
* gcc.target/i386/pr67400-1.c: Don't disable for ia32.  Scan for
ia32 if R_386_GOT32X relocation is supported.
* gcc.target/i386/pr67400-2.c: Likewise.
* gcc.target/i386/pr67400-3.c: Likewise.
* gcc.target/i386/pr67400-4.c: Likewise.
* gcc.target/i386/pr67400-6.c: Likewise.
* gcc.target/i386/pr67400-7.c: Likewise.
* lib/target-supports.exp (check_effective_target_got32x_reloc):
New.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr66232-14.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-15.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-16.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-17.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/config/i386/i386.c
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr67400-1.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-2.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-3.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-4.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-6.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-7.c
trunk/gcc/testsuite/lib/target-supports.exp

[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

[hjl at gcc dot gnu.org]

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

--- Comment #10 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Jun 23 16:30:43 2016
New Revision: 237736

URL: https://gcc.gnu.org/viewcvs?rev=237736=gcc=rev
Log:
i386: Access external function via GOT slot for -fno-plt

i386 psABI has been updated to clarify that R_386_GOT32X and R_386_GOT32
relocations can be used to access GOT without base register when PIC is
disabled:

https://groups.google.com/forum/#!topic/ia32-abi/awsRSvJOJfs

32-bit x86 assembler and linker from binutils 2.26.1 and 2.27 support

call/jmp *_start@GOT
cmpl $0, bar@GOT

for both normal and IFUNC functions.  We check if 32-bit x86 assembler
and linker have the fix for:

https://sourceware.org/bugzilla/show_bug.cgi?id=20244

before accessing external function via GOT slot for -fno-plt in both PIC
and non-PIC modes.

PR target/66232
PR target/67400
* configure.ac (as_ix86_tls_ldm_opt): Renamed to ...
(as_ix86_gas_32_opt): This.
(ld_ix86_tls_ldm_opt): Renamed to ...
(ld_ix86_gld_32_opt): This.
(R_386_TLS_LDM reloc): Updated.
(R_386_GOT32X reloc): New assembler/linker check.
(HAVE_AS_IX86_GOT32X): New.  Defined to 1 if 32-bit assembler and
linker support "jmp *_start@GOT" and "cmpl $0, bar@GOT".  Otherise,
defined to 0.
* config.in: Regenerated.
* configure: Likewise.
* config/i386/i386.c (ix86_force_load_from_GOT_p): Return
true if HAVE_AS_IX86_GOT32X is 1 in 32-bit mode.
(ix86_legitimate_address_p): Allow UNSPEC_GOT for -fno-plt
if ix86_force_load_from_GOT_p returns true.
(ix86_print_operand_address_as): Also support UNSPEC_GOT if
ix86_force_load_from_GOT_p returns true.
(ix86_expand_move): Generate UNSPEC_GOT in 32-bit mode to load
the external function address via the GOT slot.
(ix86_nopic_noplt_attribute_p): Check both TARGET_64BIT and
HAVE_AS_IX86_GOT32X before returning false.
(ix86_output_call_insn): Generate "%!jmp/call\t*%p0@GOT" in
32-bit mode if ix86_nopic_noplt_attribute_p returns true.

gcc/testsuite/

PR target/66232
PR target/67400
* gcc.target/i386/pr66232-14.c: New file.
* gcc.target/i386/pr66232-15.c: Likewise.
* gcc.target/i386/pr66232-16.c: Likewise.
* gcc.target/i386/pr66232-17.c: Likewise.
* gcc.target/i386/pr67400-1.c: Don't disable for ia32.  Scan for
ia32 if R_386_GOT32X relocation is supported.
* gcc.target/i386/pr67400-2.c: Likewise.
* gcc.target/i386/pr67400-3.c: Likewise.
* gcc.target/i386/pr67400-4.c: Likewise.
* gcc.target/i386/pr67400-6.c: Likewise.
* gcc.target/i386/pr67400-7.c: Likewise.
* lib/target-supports.exp (check_effective_target_got32x_reloc):
New.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr66232-14.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-15.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-16.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-17.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/config/i386/i386.c
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr67400-1.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-2.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-3.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-4.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-6.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-7.c
trunk/gcc/testsuite/lib/target-supports.exp

[Bug c++/36159] C++ compiler should issue a warning with missing new operator

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=6527

--- Comment #19 from Florian Weimer  ---
Current (unreleased) glibc usues this:

# define MALLOC_ALIGNMENT   (2 * SIZE_SZ < __alignof__ (long double) \
 ? __alignof__ (long double) : 2 * SIZE_SZ)

So the old bug https://sourceware.org/bugzilla/show_bug.cgi?id=6527 is gone.

To my knowledge, this level of alignment is sufficient to cover max_align_t.

These malloc changes are in principle back-portable, but they are a bit on the
risky side because where the definition of MALLOC_ALIGNMENT changes, malloc
allocation patterns (and eventually RSS usage) are affected.

[Bug tree-optimization/71631] [7 Regression] Wrong constant folding

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org

--- Comment #3 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #2)
> It looks so, but I was hoping all such issues were resolved with
> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg01829.html
> and other patches :(.

It probably was all resolved until the recent 'negate' changes. Reassoc does

   _11 = -_10;
   _12 = (unsigned short) _9;
-  _13 = _11 * _12;
   _14 = (unsigned short) _7;
-  _15 = _13 * _14;
+  _29 = _14 * _12;
+  _15 = _29 * _10;
   _16 = (unsigned short) iftmp.3_18;
-  _17 = _15 * _16;
+  _30 = _15 * _16;
+  _17 = -_30;

That is, _15 used to be the product of _11, _12 and _14, and reassoc replaced
_11 by _10, pulling the negation out of the product.

[Bug tree-optimization/71631] [7 Regression] Wrong constant folding

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Of course it is.

[Bug middle-end/69526] ivopts candidate strangeness

[rdapp at linux dot vnet.ibm.com]

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

--- Comment #19 from rdapp at linux dot vnet.ibm.com ---
(In reply to rguent...@suse.de from comment #18)
>

The match.pd patch is slowly assuming shape... Two things however I'm still
unsure about:

1.
An existing rule in match.pd checks for overflow of the combined constant
in (a +- CST1) +- CST2 and does not perform the simplification when an overflow
occurs. My case looks quite similar, however CST1 and CST2 are/might be
unsigned ints/longs. I assume this is because non-overflow cannot be proved by
the C frontend and it therefore internally uses unsigned representation?

(cast) (a +- CST1) +- CST2

We can prove the non-overflow of (a +- CST1) via VRP but an overflow check of
(CST1 +- CST2) would fail since ((UINT_MAX - 1) + 1) does overflow.

So, in general, should we care about overflow of the combined operation at all
after having established the inner operation does not overflow?
If the overflow is well-defined and we overflow, the result should be valid. If
the overflow is undefined, we could do anything, in particular optimize this
which wouldn't even be too unexpected from a user's perspective. Wouldn't any
overflow in the combined constant be caused anyway, even without combining?

I think there are only two cases two discern, regardless of overflow:

 - abs(CST1 +- CST2) < abs(CST1), then we can simplify to (cast)(a +- (CST1 +-
CST2))

 - else, we can simplify to (cast)(a) +- (CST1 +- CST2)

2.
Is there an idiomatic/correct way to check a VR_RANGE for overflow? Does it
suffice to check if the range includes +-INF or +-INF(OVF)? I suspect other,
naive methods like checking if min < max will fail, since the ranges are
canonicalized.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

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

--- Comment #17 from Jerry DeLisle  ---
Author: jvdelisle
Date: Thu Jun 23 15:58:05 2016
New Revision: 237735

URL: https://gcc.gnu.org/viewcvs?rev=237735=gcc=rev
Log:
2016-06-23  Jerry DeLisle  

PR libgfortran/48852
* io/write.c: Cleaned up whitespace.
(write_d, write_e, write_f, write_es, write_en): Use new helper
function
write_float_0. (write_float_0): New helper function.
(get_precision, select_buffer, select_string, write_float_string): New
helper functions used in remaining float writing functions. Helper
function
write_float_string now contains code for writing to kind=4 character
internal units.
(write_real): Modified to establish working buffers at this level and
to
use new helper functions.
(write_real_g0): Likewise modified.
(write_complex): Likewise modified. Gets both float strings before
output so that final lengths can be determined which allows right
justifying the complex number with no intervening spaces.
* io/write_float.def (build_float_string): Renamed from previosly
output_float, modified to use buffers passed in from higher functions,
builds a null terminated string of the floating point value. Character
kind=4 code eliminated.
(write_infnan): Likewise modified to use incoming buffers and eliminate
kind=4 related code.
(OUTPUT_FLOAT_FMT_G): Deleted, functionality moved into FORMAT_FLOAT.
(FORMAT_FLOAT): Renamed macro from WRITE_FLOAT. Use build_float_string.
(get_float_string): Renamed from write_float, uses FORMAT_FLOAT macro.
Buffer allocation removed, now at higher level.

PR libgfortran/48852
* gfortran.dg/char4_iunit_1.f03: Update test.
* gfortran.dg/f2003_io_5.f03: Update test.
* gfortran.dg/real_const_3.f90: Update test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/char4_iunit_1.f03
trunk/gcc/testsuite/gfortran.dg/f2003_io_5.f03
trunk/gcc/testsuite/gfortran.dg/real_const_3.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write.c
trunk/libgfortran/io/write_float.def

[Bug go/71635] gcc-go fails to link golang-googlecode-net

[dan at danny dot cz]

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

--- Comment #1 from Dan Horák  ---
original Fedora bug is https://bugzilla.redhat.com/show_bug.cgi?id=1349371

[Bug go/71635] New: gcc-go fails to link golang-googlecode-net

[dan at danny dot cz]

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

Bug ID: 71635
   Summary: gcc-go fails to link golang-googlecode-net
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dan at danny dot cz
CC: cmang at google dot com
  Target Milestone: ---

build of golang-googlecode-net package fails with gcc-go (checked on s390x in
Fedora buildsystem and manually on x86_64) due a linking error

...
+ go test -compiler gccgo -gccgoflags '-O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -march=z9-109 -mtune=z10 '
golang.org/x/net/ipv4
# testmain
/tmp/go-build546930784/golang.org/x/net/libipv4.a(_go_.o): In function
`golang_org_x_net_ipv4.set.pN28_golang_org_x_net_ipv4.rawOpt':
/builddir/build/BUILDROOT/golang-googlecode-net-0-0.32.gitbc3663d.fc25.s390x/usr/share/gocode/src/golang.org/x/net/ipv4/control.go:18:
multiple definition of
`golang_org_x_net_ipv4.set.pN28_golang_org_x_net_ipv4.rawOpt'
/tmp/go-build546930784/golang.org/x/net/ipv4/_test/golang.org/x/net/libipv4.a(_go_.o):/builddir/build/BUILDROOT/golang-googlecode-net-0-0.32.gitbc3663d.fc25.s390x/usr/share/gocode/src/golang.org/x/net/ipv4/control.go:18:
first defined here
/tmp/go-build546930784/golang.org/x/net/libipv4.a(_go_.o): In function
`golang_org_x_net_ipv4.clear.pN28_golang_org_x_net_ipv4.rawOpt':
/builddir/build/BUILDROOT/golang-googlecode-net-0-0.32.gitbc3663d.fc25.s390x/usr/share/gocode/src/golang.org/x/net/ipv4/control.go:19:
multiple definition of
`golang_org_x_net_ipv4.clear.pN28_golang_org_x_net_ipv4.rawOpt'
/tmp/go-build546930784/golang.org/x/net/ipv4/_test/golang.org/x/net/libipv4.a(_go_.o):/builddir/build/BUILDROOT/golang-googlecode-net-0-0.32.gitbc3663d.fc25.s390x/usr/share/gocode/src/golang.org/x/net/ipv4/control.go:19:
first defined here
/tmp/go-build546930784/golang.org/x/net/libipv4.a(_go_.o): In function
`golang_org_x_net_ipv4.isset.pN28_golang_org_x_net_ipv4.rawOpt':
/builddir/build/BUILDROOT/golang-googlecode-net-0-0.32.gitbc3663d.fc25.s390x/usr/share/gocode/src/golang.org/x/net/ipv4/control.go:20:
multiple definition of
`golang_org_x_net_ipv4.isset.pN28_golang_org_x_net_ipv4.rawOpt'
/tmp/go-build546930784/golang.org/x/net/ipv4/_test/golang.org/x/net/libipv4.a(_go_.o):/builddir/build/BUILDROOT/golang-googlecode-net-0-0.32.gitbc3663d.fc25.s390x/usr/share/gocode/src/golang.org/x/net/ipv4/control.go:20:
first defined here
/tmp/go-build546930784/golang.org/x/net/libipv4.a(_go_.o): In function
`golang_org_x_net_ipv4.ok.pN32_golang_org_x_net_ipv4.genericOpt':
/builddir/build/BUILDROOT/golang-googlecode-net-0-0.32.gitbc3663d.fc25.s390x/usr/share/gocode/src/golang.org/x/net/ipv4/endpoint.go:24:
multiple definition of
`golang_org_x_net_ipv4.ok.pN32_golang_org_x_net_ipv4.genericOpt'
/tmp/go-build546930784/golang.org/x/net/ipv4/_test/golang.org/x/net/libipv4.a(_go_.o):/builddir/build/BUILDROOT/golang-googlecode-net-0-0.32.gitbc3663d.fc25.s390x/usr/share/gocode/src/golang.org/x/net/ipv4/endpoint.go:24:
first defined here
/tmp/go-build546930784/golang.org/x/net/libipv4.a(_go_.o): In function
`golang_org_x_net_ipv4.ok.pN30_golang_org_x_net_ipv4.dgramOpt':
/builddir/build/BUILDROOT/golang-googlecode-net-0-0.32.gitbc3663d.fc25.s390x/usr/share/gocode/src/golang.org/x/net/ipv4/endpoint.go:48:
multiple definition of
`golang_org_x_net_ipv4.ok.pN30_golang_org_x_net_ipv4.dgramOpt'
...

for full log please see
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2266794

upstream sources for the package is https://github.com/golang/net

Version-Release number of selected component (if applicable):
gcc-go-6.1.1-2.fc24

Steps to reproduce locally:
mkdir -p src/golang.org/x/
cd src/golang.org/x/
git clone https://github.com/golang/net.git
cd ../..
GOPATH=`pwd`/.. go test golang.org/x/net/ipv4

[Bug target/63359] aarch64: 32bit registers in inline asm

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #13 from nsz at gcc dot gnu.org ---
there could be a format for reducing porting work between ilp32 and lp64 inline
asm:

asm ("ldr %?0, foo" : "=r"(ptr));

where %?0 behaves like %w0 on ilp32 and %x0 on lp64, which is a bit nicer than
doing preprocessor hacks like

#ifdef __LP64__
#define XW "x"
#else
#define XW "w"
#endif
asm ("ldr %" XW "0, foo" : "=r"(ptr));

[Bug rtl-optimization/56069] [4.9/5/6/7 Regression] RA pessimization

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=20295

--- Comment #15 from Jeffrey A. Law  ---
On 04/27/2016 05:33 AM, Bernd Schmidt wrote:
> On 04/27/2016 06:02 AM, Jeff Law wrote:
>> AFAICT the sra-1.c expects to see the incremented value and I'm at a
>> loss to understand what's really going on here.  Can you give more
>> details?
> 
> Yeah, maybe my first impression wasn't very accurate.
> 
> When I try to run gdb manually, it just crashes:
> 
> (gdb) show version
> GNU gdb (Gentoo 7.10.1 vanilla) 7.10.1
> (gdb) b 43
> Breakpoint 1 at 0x40059b: file sra-1.c, line 43.
> (gdb) run
> Starting program: /local/src/egcs/bscommit/gcc/a.out
> 
> Breakpoint 1, f3 (k=) at sra-1.c:43
> 43  bar (a.j);/* { dg-final { gdb-test 43 "a.j" "14" } } */
> (gdb) p a.j
> Segmentation fault (core dumped)
> 
[ ... ]

> 
> 
> I don't really understand the var-tracking stuff too well, so no idea
> where to go from here. I suppose I'm withdrawing my patch.
Based on the above, there's some kind of GDB bug.  So your patch may still be a
good thing.

I did a build on F23 which has effectively the same version of gdb and can
reproduce the gdb segfault.  It also reproduces on F24 which has gdb-7.11.1

AFAICT gdb thinks the value of "a" has been optimized out, but goes absolutely
bananas and segfaults if you try to examine a field within "a".

[law@torsion gcc]$ ./xgcc -B./ -g sra-1.c -O2
[law@torsion gcc]$ gdb ./a.out
GNU gdb (GDB) Fedora 7.10.1-30.fc23
[ ... ]
(gdb) b 43
Breakpoint 1 at 0x40056b: file sra-1.c, line 43.
(gdb) r
Starting program: /opt/notnfs/law/gcc-testing/obj/gcc/a.out 
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.22-10.fc23.x86_64

Breakpoint 1, f3 (k=) at sra-1.c:43
43bar (a.j);/* { dg-final { gdb-test 43 "a.j" "14" } } */
(gdb) p a
$1 = 
(gdb) p a.i
Segmentation fault (core dumped)


My gdb skills are far too rusty to take this further.  I've filed an upstream
report (BZ20295 in the gdb tracker).  Probably not much we can do until the GDB
side gets fixed.

I'm going to attach this to 56069 for future reference.
jeff

[Bug c/71560] union compound literal initializes wrong union field

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Created attachment 38752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38752=edit
Proposed documentation patch.

Please have a look at the attached patch and let me know if you have any
comments or suggestions.

[Bug c/71567] Incorrect loop optimization

[tyoma.ariv at gmail dot com]

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

--- Comment #8 from Artem  ---
(In reply to Manuel López-Ibáñez from comment #7)
> See https://gcc.gnu.org/wiki/FAQ#misoptimization
> 
> and https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

Thank you for the links.

However I am not able to find compilation keys to indicate initial problem.
Could you please provide an example when -Waggressive-loop-optimizations
returns warning?
You say that solution with using -fno-aggressive-loop-optimizations does not
guaranty correct compilation.
Maybe switch off optimization at all could help to avoid problems related to
"undefined behavior" during optimization. Could you please, advise. I
understand that source code will be broken but it have already worked correctly
for many years with xlC compiler.

[Bug c/52952] Wformat location info is bad (wrong column number)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #43 from David Malcolm  ---
(In reply to Manuel López-Ibáñez from comment #40)
> Unreviewed patch that increases precision in some cases:
> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01373.html

Looks like this was committed as r227975.

[Bug middle-end/71303] missing strlen optimization for strings initialized via a braced-init-list

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Bug 71625 has more discussion so closing this one as a duplicate of it

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

[Bug middle-end/71296] missing warning on strcat appending to a non-string

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71296
Bug 71296 depends on bug 71303, which changed state.

Bug 71303 Summary: missing strlen optimization for strings initialized via a 
braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71303

   What|Removed |Added

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

[Bug middle-end/71625] missing strlen optimization on different array initialization style

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
*** Bug 71303 has been marked as a duplicate of this bug. ***

[Bug middle-end/71625] missing strlen optimization on different array initialization style

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-23
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #4 from Martin Sebor  ---
I'm working on a patch that among other things transforms the CONSTRUCTOR node
created for an array initializer to STRING_CST, as suggested by Richard in bug
71303 that this one is a duplicate of, to help fold strlen results for constant
arguments (this also affects C++ constexpr where it would be useful to be able
to call strlen).  Let me confirm this one since it has more discussion and
close the other as a dupe.

[Bug target/63359] aarch64: 32bit registers in inline asm

[rearnsha at gcc dot gnu.org]

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

--- Comment #12 from Richard Earnshaw  ---
We considered that, but it won't work.  For example, in ILP32 address registers
need to use the X form, but are still 32-bits in size.  There are other cases
as well where a W or X form is required but that is not the natural size of the
object.

[Bug tree-optimization/71631] [7 Regression] Wrong constant folding

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
It looks so, but I was hoping all such issues were resolved with
https://gcc.gnu.org/ml/gcc-patches/2013-10/msg01829.html
and other patches :(.

[Bug tree-optimization/71632] [7 Regression] hang at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
In any case, this looks to me like expansion or TER bug.
The problem in this case is that expand_cond_expr_using_cmove
expands the tree arguments:
  op00 = expand_normal (gimple_assign_rhs1 (srcstmt));
  op01 = expand_normal (gimple_assign_rhs2 (srcstmt));
and then calls emit_conditional_move, which fails, thus we throw it all away,
and the caller of expand_cond_expr_using_cmove then calls jumpifnot, which
expands those again.  I bet this isn't the only spot in the expander that does
it similarly.  The problem is that with very deep TER trees this has
prohibitive compile time/memory complexity.
So, either we need to fix all the places in the expander that might try to
expand the same tree argument multiple times, or we need to tweak TER, so that
it e.g. counts number of leafs in a TER tree and/or their maximum depth and
artificially disables TER of certain SSA_NAMEs so that one expand_normal has
always reasonably sized TER trees to expand, not something unbounded.

void
foo (double d, double *p, double *q)
{
  int i;
  for (i = 0; i < 64; i++)
{
  double t1 = d > p[0] ? 1.0 : 0.0;
  double t2 = t1 > p[1] ? 1.0 : 0.0;
  double t3 = t2 > p[2] ? 1.0 : 0.0;
  double t4 = t3 > p[3] ? 1.0 : 0.0;
  double t5 = t4 > p[4] ? 1.0 : 0.0;
  double t6 = t5 > p[5] ? 1.0 : 0.0;
  double t7 = t6 > p[6] ? 1.0 : 0.0;
  double t8 = t7 > p[7] ? 1.0 : 0.0;
  double t9 = t8 > p[8] ? 1.0 : 0.0;
  double t10 = t9 > p[9] ? 1.0 : 0.0;
  double t11 = t10 > p[10] ? 1.0 : 0.0;
  double t12 = t11 > p[11] ? 1.0 : 0.0;
  double t13 = t12 > p[12] ? 1.0 : 0.0;
  double t14 = t13 > p[13] ? 1.0 : 0.0;
  double t15 = t14 > p[14] ? 1.0 : 0.0;
  double t16 = t15 > p[15] ? 1.0 : 0.0;
  double t17 = t16 > p[16] ? 1.0 : 0.0;
  double t18 = t17 > p[17] ? 1.0 : 0.0;
  double t19 = t18 > p[18] ? 1.0 : 0.0;
  double t20 = t19 > p[19] ? 1.0 : 0.0;
  double t21 = t20 > p[20] ? 1.0 : 0.0;
  double t22 = t21 > p[21] ? 1.0 : 0.0;
  double t23 = t22 > p[22] ? 1.0 : 0.0;
  double t24 = t23 > p[23] ? 1.0 : 0.0;
  double t25 = t24 > p[24] ? 1.0 : 0.0;
  double t26 = t25 > p[25] ? 1.0 : 0.0;
  double t27 = t26 > p[26] ? 1.0 : 0.0;
  double t28 = t27 > p[27] ? 1.0 : 0.0;
  double t29 = t28 > p[28] ? 1.0 : 0.0;
  double t30 = t29 > p[29] ? 1.0 : 0.0;
  double t31 = t30 > p[30] ? 1.0 : 0.0;
  double t32 = t31 > p[31] ? 1.0 : 0.0;
  double t33 = t32 > p[32] ? 1.0 : 0.0;
  double t34 = t33 > p[33] ? 1.0 : 0.0;
  double t35 = t34 > p[34] ? 1.0 : 0.0;
  double t36 = t35 > p[35] ? 1.0 : 0.0;
  double t37 = t36 > p[36] ? 1.0 : 0.0;
  double t38 = t37 > p[37] ? 1.0 : 0.0;
  double t39 = t38 > p[38] ? 1.0 : 0.0;
  *q = t39;
  p += 39;
  q++;
}
}

[Bug c/71602] [6/7 regression] ICE on __builtin_va_arg in build_va_arg, at c-family/c-common.c:5810

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01673.html

[Bug middle-end/71625] missing strlen optimization on different array initialization style

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
strlen is pure, not const, since its result depends on memory pointed to 
by its argument, not just the value of the pointer itself.  See 
extend.texi: "Note that a function that has pointer arguments and examines 
the data pointed to must @emph{not} be declared @code{const}.".

[Bug tree-optimization/71632] [7 Regression] hang at -O3 on x86_64-linux-gnu

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
As in optimized dump:


  :
  c.1_1 = c;
  _85 = *c.1_1;
  _87 = *_85;
  iftmp.0_88 = d_27(D) < _87 ? 1.0e+0 : 0.0;
  _90 = MEM[(double *)_85 + 8B];
  iftmp.0_91 = iftmp.0_88 < _90 ? 1.0e+0 : 0.0;
  _93 = MEM[(double *)_85 + 16B];
  iftmp.0_94 = iftmp.0_91 < _93 ? 1.0e+0 : 0.0;
  _96 = MEM[(double *)_85 + 24B];
  iftmp.0_97 = iftmp.0_94 < _96 ? 1.0e+0 : 0.0;
  _99 = MEM[(double *)_85 + 32B];
  iftmp.0_100 = iftmp.0_97 < _99 ? 1.0e+0 : 0.0;
  _110 = MEM[(double * *)c.1_1 + 8B];
  _112 = *_110;
  iftmp.0_113 = iftmp.0_100 < _112 ? 1.0e+0 : 0.0;
  _115 = MEM[(double *)_110 + 8B];
  iftmp.0_116 = iftmp.0_113 < _115 ? 1.0e+0 : 0.0;
  _118 = MEM[(double *)_110 + 16B];
  iftmp.0_119 = iftmp.0_116 < _118 ? 1.0e+0 : 0.0;
  _121 = MEM[(double *)_110 + 24B];
  iftmp.0_122 = iftmp.0_119 < _121 ? 1.0e+0 : 0.0;
  _124 = MEM[(double *)_110 + 32B];
  iftmp.0_125 = iftmp.0_122 < _124 ? 1.0e+0 : 0.0;
  _135 = MEM[(double * *)c.1_1 + 16B];
  _137 = *_135;
  iftmp.0_138 = iftmp.0_125 < _137 ? 1.0e+0 : 0.0;
  _140 = MEM[(double *)_135 + 8B];
  iftmp.0_141 = iftmp.0_138 < _140 ? 1.0e+0 : 0.0;
  _143 = MEM[(double *)_135 + 16B];
  iftmp.0_144 = iftmp.0_141 < _143 ? 1.0e+0 : 0.0;
  _146 = MEM[(double *)_135 + 24B];
  iftmp.0_147 = iftmp.0_144 < _146 ? 1.0e+0 : 0.0;
  _149 = MEM[(double *)_135 + 32B];
  iftmp.0_150 = iftmp.0_147 < _149 ? 1.0e+0 : 0.0;
  _160 = MEM[(double * *)c.1_1 + 24B];
  _162 = *_160;
  iftmp.0_163 = iftmp.0_150 < _162 ? 1.0e+0 : 0.0;
  _165 = MEM[(double *)_160 + 8B];
  iftmp.0_166 = iftmp.0_163 < _165 ? 1.0e+0 : 0.0;
  _168 = MEM[(double *)_160 + 16B];
  iftmp.0_169 = iftmp.0_166 < _168 ? 1.0e+0 : 0.0;
  _171 = MEM[(double *)_160 + 24B];
  iftmp.0_172 = iftmp.0_169 < _171 ? 1.0e+0 : 0.0;
  _174 = MEM[(double *)_160 + 32B];
  iftmp.0_175 = iftmp.0_172 < _174 ? 1.0e+0 : 0.0;
  _185 = MEM[(double * *)c.1_1 + 32B];
  _187 = *_185;
  iftmp.0_188 = iftmp.0_175 < _187 ? 1.0e+0 : 0.0;
  _190 = MEM[(double *)_185 + 8B];
  iftmp.0_191 = iftmp.0_188 < _190 ? 1.0e+0 : 0.0;
  _193 = MEM[(double *)_185 + 16B];
  iftmp.0_194 = iftmp.0_191 < _193 ? 1.0e+0 : 0.0;
  _196 = MEM[(double *)_185 + 24B];
  iftmp.0_197 = iftmp.0_194 < _196 ? 1.0e+0 : 0.0;
  _199 = MEM[(double *)_185 + 32B];
  iftmp.0_200 = iftmp.0_197 < _199 ? 1.0e+0 : 0.0;
  _5 = MEM[(double * *)c.1_1 + 40B];
  _29 = *_5;
  iftmp.0_64 = _29 > iftmp.0_200 ? 1.0e+0 : 0.0;
  _45 = MEM[(double *)_5 + 8B];
  iftmp.0_23 = _45 > iftmp.0_64 ? 1.0e+0 : 0.0;
  _14 = MEM[(double *)_5 + 16B];
  iftmp.0_16 = _14 > iftmp.0_23 ? 1.0e+0 : 0.0;
  _74 = MEM[(double *)_5 + 24B];
  iftmp.0_75 = iftmp.0_16 < _74 ? 1.0e+0 : 0.0;
  _9 = MEM[(double *)_5 + 32B];
  iftmp.0_22 = _9 > iftmp.0_75 ? 1.0e+0 : 0.0;
  b = 5;
  a = 6;
  MEM[(double *)_85 + 40B] = iftmp.0_22;
  return;


Every iftmp definition uses the previous one.

[Bug tree-optimization/71632] [7 Regression] hang at -O3 on x86_64-linux-gnu

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
The commit if-converts below loop:

  :
  # b.5_38 = PHI <0(3), _10(7)>
  # d_40 = PHI 
  # ivtmp_17 = PHI <5(3), ivtmp_37(7)>
  _6 = (long unsigned int) b.5_38;
  _7 = _6 * 8;
  _8 = _5 + _7;
  _9 = *_8;
  if (_9 > d_40)
goto ;
  else
goto ;

  :

  :
  # iftmp.0_22 = PHI <1.0e+0(4), 0.0(5)>
  _10 = b.5_38 + 1;
  ivtmp_37 = ivtmp_17 - 1;
  if (ivtmp_37 != 0)
goto ;
  else
goto ;

  :
  goto ;

into :
  :
  # b.5_38 = PHI <0(3), _10(5)>
  # d_40 = PHI 
  # ivtmp_17 = PHI <5(3), ivtmp_37(5)>
  _6 = (long unsigned int) b.5_38;
  _7 = _6 * 8;
  _8 = _5 + _7;
  _9 = *_8;
  iftmp.0_22 = _9 > d_40 ? 1.0e+0 : 0.0;
  _10 = b.5_38 + 1;
  ivtmp_37 = ivtmp_17 - 1;
  if (ivtmp_37 != 0)
goto ;
  else
goto ;

  :
  goto ;

It looks like a correct transform, even the result loop can't be vectorized.

Then the loop is completely unrolled and and long single def-use chain for
"iftmp" is generated.  I suspect this causes exponential behavior in TER?

[Bug middle-end/71625] missing strlen optimization on different array initialization style

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #2 from nsz at gcc dot gnu.org ---
int hallo ();
int dummy ()
{
  char array[] = "abc";
  hallo ();
  return __builtin_strlen (array);
}

if strlen is pure then it cannot be evaluated at compile time because hallo
might modify global state, but strlen should be modeled with attribute const,
since the result cannot depend on global state.

i.e. in gcc/builtins.def

DEF_LIB_BUILTIN_CHKP   (BUILT_IN_STRLEN, "strlen", BT_FN_SIZE_CONST_STRING,
ATTR_PURE_NOTHROW_NONNULL_LEAF)

the PURE should be CONST.

[Bug tree-optimization/71631] [7 Regression] Wrong constant folding

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |7.0

[Bug tree-optimization/71631] [7 Regression] Wrong constant folding

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-23
Summary|Wrong constant folding  |[7 Regression] Wrong
   ||constant folding
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
Wild guess: SSA_NAME reuse in reassoc without clearing VRP info.

[Bug tree-optimization/71632] [7 Regression] hang at -O3 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
It hangs during expansion of:

(gdb) p debug_gimple_stmt(stmt)
iftmp.0_22 = _9 > iftmp.0_75 ? 1.0e+0 : 0.0;


in:

#119 0x008b6978 in expand_expr_real (exp=exp@entry=0x769c9048,
target=target@entry=0x0, tmode=tmode@entry=VOIDmode,
modifier=modifier@entry=EXPAND_NORMAL, alt_rtl=alt_rtl@entry=0x0,
inner_reference_p=inner_reference_p@entry=false) at ../../gcc/expr.c:8104
#120 0x0082a881 in expand_normal (exp=0x769c9048) at
../../gcc/expr.h:285
---Type  to continue, or q  to quit---
#121 do_compare_and_jump (treeop0=treeop0@entry=0x769c9048,
treeop1=treeop1@entry=0x769c90d8, signed_code=signed_code@entry=LT,
unsigned_code=unsigned_code@entry=LTU,
if_false_label=if_false_label@entry=0x7ffe030c3300,
if_true_label=if_true_label@entry=0x0, 
prob=-1) at ../../gcc/dojump.c:1172
#122 0x0082c6d0 in do_jump_1 (code=, op0=0x769c9048,
op1=0x769c90d8, if_false_label=if_false_label@entry=0x7ffe030c3300,
if_true_label=if_true_label@entry=0x0, prob=prob@entry=-1) at
../../gcc/dojump.c:264
#123 0x0082b738 in do_jump (exp=0x769caaa0,
if_false_label=0x7ffe030c3300, if_true_label=if_true_label@entry=0x0, prob=-1)
at ../../gcc/dojump.c:531
#124 0x0082c4c7 in jumpifnot (exp=exp@entry=0x769caaa0,
label=label@entry=0x7ffe030c3300, prob=prob@entry=-1) at ../../gcc/dojump.c:132
#125 0x008c669f in expand_expr_real_2 (ops=ops@entry=0x7fffc600,
target=target@entry=0x0, tmode=tmode@entry=VOIDmode,
modifier=modifier@entry=EXPAND_NORMAL) at ../../gcc/expr.c:9482
#126 0x008b43c4 in expand_expr_real_1 (exp=0x769c9120,
target=, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0,
inner_reference_p=) at ../../gcc/expr.c:9736
#127 0x008c834e in expand_normal (exp=) at
../../gcc/expr.h:285
#128 expand_cond_expr_using_cmove (treeop2=0x769972b8,
treeop1=0x769972d0, treeop0=0x769c2e38) at ../../gcc/expr.c:8160
#129 expand_expr_real_2 (ops=ops@entry=0x7fffc840, target=target@entry=0x0,
tmode=tmode@entry=VOIDmode, modifier=modifier@entry=EXPAND_NORMAL) at
../../gcc/expr.c:9460
#130 0x008b43c4 in expand_expr_real_1 (exp=0x769c91f8,
target=, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0,
inner_reference_p=) at ../../gcc/expr.c:9736
#131 0x008c834e in expand_normal (exp=) at
../../gcc/expr.h:285
#132 expand_cond_expr_using_cmove (treeop2=0x769972b8,
treeop1=0x769972d0, treeop0=0x769caac8) at ../../gcc/expr.c:8160
#133 expand_expr_real_2 (ops=ops@entry=0x7fffca80, target=target@entry=0x0,
tmode=tmode@entry=VOIDmode, modifier=modifier@entry=EXPAND_NORMAL) at
../../gcc/expr.c:9460
#134 0x008b43c4 in expand_expr_real_1 (exp=0x769c92d0,
target=, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0,
inner_reference_p=) at ../../gcc/expr.c:9736
#135 0x008c83bb in expand_normal (exp=) at
../../gcc/expr.h:285
#136 expand_cond_expr_using_cmove (treeop2=0x769972b8,
treeop1=0x769972d0, treeop0=0x769b9e38) at ../../gcc/expr.c:8161
#137 expand_expr_real_2 (ops=ops@entry=0x7fffccc0, target=target@entry=0x0,
tmode=tmode@entry=VOIDmode, modifier=modifier@entry=EXPAND_NORMAL) at
../../gcc/expr.c:9460
#138 0x008b43c4 in expand_expr_real_1 (exp=0x769b2c18,
target=, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0,
inner_reference_p=) at ../../gcc/expr.c:9736
#139 0x008c83bb in expand_normal (exp=) at
../../gcc/expr.h:285
#140 expand_cond_expr_using_cmove (treeop2=0x769972b8,
treeop1=0x769972d0, treeop0=0x769b9f28) at ../../gcc/expr.c:8161
#141 expand_expr_real_2 (ops=ops@entry=0x7fffcf00, target=target@entry=0x0,
tmode=tmode@entry=VOIDmode, modifier=modifier@entry=EXPAND_NORMAL) at
../../gcc/expr.c:9460
#142 0x008b43c4 in expand_expr_real_1 (exp=0x7688be10,
target=, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0,
inner_reference_p=) at ../../gcc/expr.c:9736
#143 0x008c83bb in expand_normal (exp=) at
../../gcc/expr.h:285
#144 expand_cond_expr_using_cmove (treeop2=0x769972b8,
treeop1=0x769972d0, treeop0=0x769c2000) at ../../gcc/expr.c:8161
#145 expand_expr_real_2 (ops=ops@entry=0x7fffd140, target=target@entry=0x0,
tmode=tmode@entry=VOIDmode, modifier=modifier@entry=EXPAND_NORMAL) at
../../gcc/expr.c:9460
#146 0x008b43c4 in expand_expr_real_1 (exp=0x7688bbd0,
target=, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0,
inner_reference_p=) at ../../gcc/expr.c:9736
#147 0x008c834e in expand_normal (exp=) at
../../gcc/expr.h:285
#148 expand_cond_expr_using_cmove (treeop2=0x769972b8,
treeop1=0x769972d0, treeop0=0x769c2348) at ../../gcc/expr.c:8160
#149 

[Bug target/63359] aarch64: 32bit registers in inline asm

[gcc.hall at gmail dot com]

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

--- Comment #11 from Jeremy  ---
int32_t n;
asm( "str %1,[%0],#4" : "+r" (ptr) : "r" (n) : "memory" );

Caught me until I just happened to examine the assembler.

Of course %w1 works - but then I need SEPARATE code for 32-bit ARM and for
aarch64.

Now arnv8 has two register sizes, I ask also, please could it work like x86 and
use the operand size to determine which to emit, x or w.

[Bug middle-end/71619] [7 Regression] ICE: in predict_loops, at predict.c:1772 with --param=max-predicted-iterations=0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed on trunk.

[Bug middle-end/71619] [7 Regression] ICE: in predict_loops, at predict.c:1772 with --param=max-predicted-iterations=0

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Thu Jun 23 11:04:35 2016
New Revision: 237730

URL: https://gcc.gnu.org/viewcvs?rev=237730=gcc=rev
Log:
Fix PR middle-end/71619

PR middle-end/71619
* predict.c (predict_loops): Revert the hunk that was removed
in r237103.
* gcc.dg/pr71619.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr71619.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/predict.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71632] [7 Regression] hang at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-23
 CC||amker at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
  Component|c   |tree-optimization
   Target Milestone|--- |7.0
Summary|hang at -O3 on  |[7 Regression] hang at -O3
   |x86_64-linux-gnu|on x86_64-linux-gnu
 Ever confirmed|0   |1

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

[Bug rtl-optimization/71634] New: Invalid write with in mark_loops_for_removal (ira-build.c:2256) with --param ira-max-loops-num=0

[marxin at gcc dot gnu.org]

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

Bug ID: 71634
   Summary: Invalid write with in mark_loops_for_removal
(ira-build.c:2256) with --param ira-max-loops-num=0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello.

Following simple test-case produces invalid write of size 1B in:

==29696== Invalid write of size 1
==29696==at 0xA05331: mark_loops_for_removal (ira-build.c:2256)
==29696==by 0xA05331: remove_unnecessary_regions(bool) (ira-build.c:2595)
==29696==by 0xA0838A: ira_build() (ira-build.c:3422)
==29696==by 0x9FEFA3: ira (ira.c:5220)
==29696==by 0x9FEFA3: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5525)
==29696==by 0xAE0463: execute_one_pass(opt_pass*) (passes.c:2344)
==29696==by 0xAE0A37: execute_pass_list_1(opt_pass*) [clone .constprop.81]
(passes.c:2428)
==29696==by 0xAE0A49: execute_pass_list_1(opt_pass*) [clone .constprop.81]
(passes.c:2429)
==29696==by 0xAE0A94: execute_pass_list(function*, opt_pass*)
(passes.c:2439)
==29696==by 0x7D4713: cgraph_node::expand() (cgraphunit.c:1983)
==29696==by 0x7D6000: expand_all_functions (cgraphunit.c:2119)
==29696==by 0x7D6000: symbol_table::compile() [clone .part.48]
(cgraphunit.c:2475)
==29696==by 0x7D8427: compile (cgraphunit.c:2539)
==29696==by 0x7D8427: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2565)
==29696==by 0xBAAEB7: compile_file() (toplev.c:490)
==29696==by 0x63F4B3: do_compile (toplev.c:1998)
==29696==by 0x63F4B3: toplev::main(int, char**) (toplev.c:2132)
==29696==  Address 0x40 is not stack'd, malloc'd or (recently) free'd

$ valgrind --leak-check=yes --trac gcc -O3  --param ira-max-loops-num=0 tc.i

$ cat tc.i
fn1() {}

I consider having min value of the parameter to zero does not make much sense
and I'll send patch to mailing list.

Martin

[Bug ipa/71633] New: [7 regression][CHKP] internal compiler error: in inline_call

[ienkovich at gcc dot gnu.org]

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

Bug ID: 71633
   Summary: [7 regression][CHKP] internal compiler error: in
inline_call
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

There is a regression introduced by r236274.

>cat small.i
class c1
{
  virtual void fn1 ();
};

class c2
{
  virtual int *fn2 () const;
};

class c3 : c1, c2
{
  int *fn2 () const;
  int *fn3 (int) const;
};

int *c3::fn2 () const
{
}

int *c3::fn3 (int p) const
{
  return fn3 (p);
}
>g++ -O2 -mmpx -fcheck-pointer-bounds small.i -S
small.i:24:1: internal compiler error: in inline_call, at
ipa-inline-transform.c:432
 }
 ^
0x13fa45a inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
   
/export/users/gnutester/stability/svn/trunk/gcc/ipa-inline-transform.c:432
0x13f1c8a inline_small_functions
/export/users/gnutester/stability/svn/trunk/gcc/ipa-inline.c:2027
0x13f1c8a ipa_inline
/export/users/gnutester/stability/svn/trunk/gcc/ipa-inline.c:2437
0x13f1c8a execute
/export/users/gnutester/stability/svn/trunk/gcc/ipa-inline.c:2848

[Bug c/71560] union compound literal initializes wrong union field

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
(In reply to Martin Sebor from comment #4)
> Please let me know if you're planning to make these
> changes, otherwise I can give it a whirl.

Unfortunately I don't have time for this. Please go ahead.

[Bug c/71567] Incorrect loop optimization

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Artem from comment #6)
> Is there any way to indicate such kind of errors during compilation.
> I tried to add options -Wall -Waggressive-loop-optimizations for compilation
> code from the description. But I didn't get any warnings related to "reading
> one past the array bounds".
> Which kind of warnings are switched on by adding
> -Waggressive-loop-optimizations?

See https://gcc.gnu.org/wiki/FAQ#misoptimization

and https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

[Bug c++/71618] Improve C++ compilation by adding specific optimization flags

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #7)
> Okay, I updated the Wiki.  I would have liked to have added a link to the
> --help option in the manual but, unfortunately, the anchors in it change
> from one release to the next.  I suppose the next best thing I could do is
> link to the Overall-Options.html page where it's documented.

Indeed: PR43887

I think it makes sense to mention both methods since the -fverbose-asm way
gives you exactly the list of flags AND their values, in case they may take a
value. I have updated it accordingly.

[Bug c/71632] New: hang at -O3 on x86_64-linux-gnu

[chengniansun at gmail dot com]

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

Bug ID: 71632
   Summary: hang at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

This is a recent regression. gcc-5.3 is okay. 

$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160623 (experimental) [trunk revision 237726] (GCC) 
$: 
$: timeout -s 9 30 gcc-trunk -O3 small.c
Killed
$: 
$: cat small.c
int a, b;
double **c;
void fn1() {
  double d;
  a = 0;
  for (; a < 6; a++) {
b = 0;
for (; b < 5; b++)
  d = c[a][b] > d;
  }
  c[0][b] = d;
}

$:

[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Markus Trippelsdorf from comment #8)
> Thiago, if you can parse Jakub's suggestion from comment 3 (I can't), you
> could give it a try.

The intent was to see 1 preprocessed file attached (the header) which is
compiled into pch, and then one semi-preprocessed file (preprocessed, with the
first header unincluded) + 2 command lines.

[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
Thiago, if you can parse Jakub's suggestion from comment 3 (I can't), you
could give it a try.

[Bug tree-optimization/71631] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 71631
   Summary: Wrong constant folding
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

GCC 7.0.0 for x86_64 miscompiles the following code.

% cat test.c 

volatile char buff = 0;
void PRINTF(const char* s)
{
while(*s++) buff = *s;
}

int a = 1;
int b = 1;
int c = 1;

int main (void)
{
volatile int d = 1;
volatile int e = 1;

int f =  1 / a;
int g = 1U < f;
int h =  2 + g;
int i =  3 % h;
int j =  e && b;
int k =  1 == c;
int l =  d != 0;
short m = (short)( -1 * i * l );

short x =  j * ( k * m );


if (i == 1)  {PRINTF("OK");}
if (x != -1) __builtin_abort();

return 0;
}

% gcc-7.0 test.c -O3 
% ./a.out
zsh: abort (core dumped)  ./a.out

% gcc-7.0 -v
Using built-in specs.
COLLECT_GCC=gcc-7.0
COLLECT_LTO_WRAPPER=/home/cappie/opt/gcc-7.0.0/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/cappie/opt/gcc-7.0.0 --disable-nls
--disable-multilib --program-suffix=-7.0 --enable-languages=c
Thread model: posix
gcc version 7.0.0 20160621 (experimental) (GCC)

[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[thiago at kde dot org]

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

--- Comment #16 from Thiago Macieira  ---
(In reply to Markus Trippelsdorf from comment #15)
> All these bogus valgrind warnings can be suppressed if you configure gcc
> with --enable-valgrind-annotations.

That's good to know, but Valgrind didn't report a single erroneous access. And
since there's no actual crash when run inside gdb, I don't think valgrind will
help further.

If I put a breakpoint on tree.c:508 (the line reported in the output), I get:

#0  tree_node_structure_for_code (code=30240) at ../../gcc/tree.c:508
#1  tree_node_structure (t=t@entry=0x73e27438) at ../../gcc/tree.c:3370
#2  0x00545080 in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:243
#3  0x007188c6 in ggc_mark_root_tab (rt=0x10b9d08
) at ../../gcc/ggc-common.c:81
#4  0x00718b91 in ggc_mark_roots () at ../../gcc/ggc-common.c:98
#5  0x005d1280 in ggc_collect () at ../../gcc/ggc-page.c:2199
#6  0x0087931f in execute_one_pass (pass=pass@entry=0x19920e0) at
../../gcc/passes.c:2371
#7  0x00879646 in execute_pass_list_1 (pass=0x19920e0) at
../../gcc/passes.c:2383
#8  0x00879658 in execute_pass_list_1 (pass=0x1991d20,
pass@entry=0x1991c60) at ../../gcc/passes.c:2384
#9  0x00879699 in execute_pass_list (fn=0x72f479d8, pass=0x1991c60)
at ../../gcc/passes.c:2394
#10 0x0062dc8b in cgraph_node::expand (this=this@entry=0x72f45498)
at ../../gcc/cgraphunit.c:1896
#11 0x0062ef74 in expand_all_functions () at
../../gcc/cgraphunit.c:2032
#12 symbol_table::compile (this=this@entry=0x100478d300) at
../../gcc/cgraphunit.c:2385
#13 0x00630410 in symbol_table::compile (this=0x100478d300) at
../../gcc/timevar.h:110
#14 symbol_table::finalize_compilation_unit (this=0x100478d300) at
../../gcc/cgraphunit.c:2462
#15 0x004ce4d3 in cp_write_global_declarations () at
../../gcc/cp/decl2.c:4849
#16 0x0091d763 in compile_file () at ../../gcc/toplev.c:613
#17 0x0045f095 in do_compile () at ../../gcc/toplev.c:2067
#18 toplev::main (this=this@entry=0x7fffd040, argc=argc@entry=84,
argv=argv@entry=0x7fffd148)
at ../../gcc/toplev.c:2165
#19 0x0045fd8a in main (argc=84, argv=0x7fffd148) at
../../gcc/main.c:39

It crashes after this.

[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[trippels at gcc dot gnu.org]

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

--- Comment #15 from Markus Trippelsdorf  ---
All these bogus valgrind warnings can be suppressed if you configure gcc
with --enable-valgrind-annotations.

[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[thiago at kde dot org]

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

--- Comment #14 from Thiago Macieira  ---
(In reply to Markus Trippelsdorf from comment #12)
> (In reply to Thiago Macieira from comment #11)
> > (In reply to Markus Trippelsdorf from comment #9)
> > > Yes. Just invoke cc1plus directly.
> > > (Add -v to the gcc invocation and then copy & paste the cc1plus command
> > > line, that is printed out.
> > 
> > That's what I've done. cc1plus seems not to crash when run inside gdb.
> 
> Ah, sorry. It looks like a dup of 63319.
> 
> *** This bug has been marked as a duplicate of bug 63319 ***

That might be, but bug 63319 is closed as WORKSFORME. Any recourse possible?

[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #7 from Markus Trippelsdorf  ---
Apparently it still happens.

[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[thiago at kde dot org]

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

--- Comment #13 from Thiago Macieira  ---
(In reply to Markus Trippelsdorf from comment #10)
> valgrind --track-origins=yes --trace-children=yes g++...
> will probably also print a backtrace.

First error:

==32645== Conditional jump or move depends on uninitialised value(s)
==32645==at 0x7EE1B2: sparseset_bit_p (sparseset.h:147) 
==32645==by 0x7EE1B2: mark_pseudo_regno_live(int) (ira-lives.c:301) 
==32645==by 0x7EEE40: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.c:1281) 
==32645==by 0x7D6276: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
(ira-build.c:1845)  
==32645==by 0x7EFB21: ira_create_allocno_live_ranges() (ira-lives.c:1582)   
==32645==by 0x7D7BF3: ira_build() (ira-build.c:3461)
==32645==by 0x7D114A: ira (ira.c:5278)
==32645==by 0x7D114A: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5570)
==32645==by 0x879215: execute_one_pass(opt_pass*) (passes.c:2330)
==32645==by 0x879645: execute_pass_list_1(opt_pass*) [clone .constprop.64]
(passes.c:2383)
==32645==by 0x879657: execute_pass_list_1(opt_pass*) [clone .constprop.64]
(passes.c:2384)
==32645==by 0x879698: execute_pass_list(function*, opt_pass*)
(passes.c:2394)
==32645==by 0x62DC8A: cgraph_node::expand() (cgraphunit.c:1896)
==32645==by 0x62EF73: expand_all_functions (cgraphunit.c:2032)
==32645==by 0x62EF73: symbol_table::compile() [clone .part.43]
(cgraphunit.c:2385)
==32645==  Uninitialised value was created by a heap allocation
==32645==at 0x4C2D12F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32645==by 0xF33B97: xmalloc (xmalloc.c:147)
==32645==by 0x90E544: sparseset_alloc(unsigned long) (sparseset.c:33)
==32645==by 0x7EFAAF: ira_create_allocno_live_ranges() (ira-lives.c:1574)
==32645==by 0x7D7BF3: ira_build() (ira-build.c:3461)
==32645==by 0x7D114A: ira (ira.c:5278)
==32645==by 0x7D114A: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5570)
==32645==by 0x879215: execute_one_pass(opt_pass*) (passes.c:2330)
==32645==by 0x879645: execute_pass_list_1(opt_pass*) [clone .constprop.64]
(passes.c:2383)
==32645==by 0x879657: execute_pass_list_1(opt_pass*) [clone .constprop.64]
(passes.c:2384)
==32645==by 0x879698: execute_pass_list(function*, opt_pass*)
(passes.c:2394)
==32645==by 0x62DC8A: cgraph_node::expand() (cgraphunit.c:1896)
==32645==by 0x62EF73: expand_all_functions (cgraphunit.c:2032)
==32645==by 0x62EF73: symbol_table::compile() [clone .part.43]
(cgraphunit.c:2385)

Followed by a lot of similar errors, then

==32645== Use of uninitialised value of size 8
==32645==at 0x7EE1B7: sparseset_bit_p (sparseset.h:147)
==32645==by 0x7EE1B7: mark_pseudo_regno_live(int) (ira-lives.c:301)
==32645==by 0x7EEBA6: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.c:1106)
==32645==by 0x7D6295: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
(ira-build.c:1845)
==32645==by 0x7EFB21: ira_create_allocno_live_ranges() (ira-lives.c:1582)
==32645==by 0x7D7BF3: ira_build() (ira-build.c:3461)
==32645==by 0x7D114A: ira (ira.c:5278)
==32645==by 0x7D114A: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5570)
==32645==by 0x879215: execute_one_pass(opt_pass*) (passes.c:2330)
==32645==by 0x879645: execute_pass_list_1(opt_pass*) [clone .constprop.64]
(passes.c:2383)
==32645==by 0x879657: execute_pass_list_1(opt_pass*) [clone .constprop.64]
(passes.c:2384)
==32645==by 0x879698: execute_pass_list(function*, opt_pass*)
(passes.c:2394)
==32645==by 0x62DC8A: cgraph_node::expand() (cgraphunit.c:1896)
==32645==by 0x62EF73: expand_all_functions (cgraphunit.c:2032)
==32645==by 0x62EF73: symbol_table::compile() [clone .part.43]
(cgraphunit.c:2385)
==32645==  Uninitialised value was created by a heap allocation
==32645==at 0x4C2D12F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32645==by 0xF33B97: xmalloc (xmalloc.c:147)
==32645==by 0x90E544: sparseset_alloc(unsigned long) (sparseset.c:33)
==32645==by 0x7EFAAF: ira_create_allocno_live_ranges() (ira-lives.c:1574)
==32645==by 0x7D7BF3: ira_build() (ira-build.c:3461)
==32645==by 0x7D114A: ira (ira.c:5278)
==32645==by 0x7D114A: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5570)
==32645==by 0x879215: execute_one_pass(opt_pass*) (passes.c:2330)
==32645==by 0x879645: execute_pass_list_1(opt_pass*) [clone .constprop.64]
(passes.c:2383)
==32645==by 0x879657: execute_pass_list_1(opt_pass*) [clone .constprop.64]
(passes.c:2384)
==32645==by 0x879698: execute_pass_list(function*, opt_pass*)
(passes.c:2394)

[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #12 from Markus Trippelsdorf  ---
(In reply to Thiago Macieira from comment #11)
> (In reply to Markus Trippelsdorf from comment #9)
> > Yes. Just invoke cc1plus directly.
> > (Add -v to the gcc invocation and then copy & paste the cc1plus command
> > line, that is printed out.
> 
> That's what I've done. cc1plus seems not to crash when run inside gdb.

Ah, sorry. It looks like a dup of 63319.

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

[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||milla.pohjanheimo at qt dot io

--- Comment #6 from Markus Trippelsdorf  ---
*** Bug 71622 has been marked as a duplicate of this bug. ***

[Bug c++/71630] New: ICE on valid C++14 code with variable templates: in get, at cgraph.h:395

[su at cs dot ucdavis.edu]

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

Bug ID: 71630
   Summary: ICE on valid C++14 code with variable templates: in
get, at cgraph.h:395
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++11 code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

This is a regression from 6.1.x.


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160622 (experimental) [trunk revision 237715] (GCC) 
$ 
$ g++-6.1 -c -std=c++14 small.cpp
$ clang++ -c -std=c++14 small.cpp
$ 
$ g++-trunk -c -std=c++14 small.cpp
small.cpp:3:23: internal compiler error: in get, at cgraph.h:395
 template int a < int >;
   ^
0x10c32ab symtab_node::get(tree_node const*)
../../gcc-source-trunk/gcc/cgraph.h:392
0x10c32ab varpool_node::get(tree_node const*)
../../gcc-source-trunk/gcc/cgraph.h:2480
0x10c32ab varpool_node::get_create(tree_node*)
../../gcc-source-trunk/gcc/varpool.c:144
0x764d23 var_finalized_p
../../gcc-source-trunk/gcc/cp/decl2.c:1971
0x764d23 c_parse_final_cleanups()
../../gcc-source-trunk/gcc/cp/decl2.c:4807
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


-


template < typename > extern int a; 
template < typename > int a = 1;
template int a < int >;

[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[thiago at kde dot org]

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

--- Comment #11 from Thiago Macieira  ---
(In reply to Markus Trippelsdorf from comment #9)
> Yes. Just invoke cc1plus directly.
> (Add -v to the gcc invocation and then copy & paste the cc1plus command
> line, that is printed out.

That's what I've done. cc1plus seems not to crash when run inside gdb.

[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
valgrind --track-origins=yes --trace-children=yes g++ ...
will probably also print a backtrace.

[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
valgrind --track-origins=yes --trace-children=yes g++...
will probably also print a backtrace.

[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
(In reply to Thiago Macieira from comment #8)
> cc1plus doesn't stop in gdb, for some reason. Instead, it prints:
> 
> painting/qdrawhelper.cpp: In function ‘void
> qt_bitmapblit_quint16(QRasterBuffer*, int, int, const QRgba64&, const
> uchar*, int, int, int)’:
> painting/qdrawhelper.cpp:5753:20: internal compiler error: in
> tree_node_structure_for_code, at tree.c:508
>  inline static void qt_bitmapblit_quint16(QRasterBuffer *rasterBuffer,
> ^
> 
> Outside of gdb, it prints "Segmentation fault", but doesn't generate a core
> file nor does systemd-coredump catch this crash, so no postmortem debugging.
> 
> Any tricks to do that?

Yes. Just invoke cc1plus directly.
(Add -v to the gcc invocation and then copy & paste the cc1plus command
line, that is printed out.

[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[thiago at kde dot org]

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

--- Comment #8 from Thiago Macieira  ---
cc1plus doesn't stop in gdb, for some reason. Instead, it prints:

painting/qdrawhelper.cpp: In function ‘void
qt_bitmapblit_quint16(QRasterBuffer*, int, int, const QRgba64&, const uchar*,
int, int, int)’:
painting/qdrawhelper.cpp:5753:20: internal compiler error: in
tree_node_structure_for_code, at tree.c:508
 inline static void qt_bitmapblit_quint16(QRasterBuffer *rasterBuffer,
^

Outside of gdb, it prints "Segmentation fault", but doesn't generate a core
file nor does systemd-coredump catch this crash, so no postmortem debugging.

Any tricks to do that?

[Bug target/71629] New: [7 Regression] ICE in lra_set_insn_recog_data, at lra.c:964 w/ -O2 -mlra

[asolokha at gmx dot com]

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

Bug ID: 71629
   Summary: [7 Regression] ICE in lra_set_insn_recog_data, at
lra.c:964 w/ -O2 -mlra
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-e500v2-linux-gnuspe

gcc-7.0.0-alpha20160619 snapshot ICEs when compiling the following testcase w/
-O2 (-O3, -Ofast) -mlra:

long long int nk;
int gn;

void
pf (long long int kx)
{
  int h7 = 1;
  unsigned int u1;

  for (u1 = 0; u1 != 0; ++u1)
{
  unsigned long long int *fd = 
  long long int *sm = 
  int qg = 1;
  int *b6;

  while (qg != 0)
{
 n5:
  h7 = 0;
  for (gn = -3; gn < 0; ++gn)
{
  nk *= 2;
  if (qg / nk != 0)
{
  kx = -1;
  while (*sm < 0)
{
  *b6 = 
  ++kx;
}
}
}
  kx = *fd;
  if (*sm / qg > *sm / kx)
sm = 0;
}
}
  if (h7 != 0)
goto n5;
}

% powerpc-e500v2-linux-gnuspe-gcc-7.0.0-alpha20160619 -w -c -O2 -mlra
yqpf1ggk.c 
yqpf1ggk.c: In function 'pf':
yqpf1ggk.c:41:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:964

[Bug c++/71628] New: ICE on valid C++11 code (with lambda expression, __typeof operator and variable length array): verify_gimple failed

[su at cs dot ucdavis.edu]

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

Bug ID: 71628
   Summary: ICE on valid C++11 code (with lambda expression,
__typeof operator and variable length array):
verify_gimple failed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++11 code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It also affects 4.8.x and later, and is a regression from 4.7.x. 


sica [159] % g++-4.7 -c small.cpp -std=c++11
sica [160] % sh
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160622 (experimental) [trunk revision 237715] (GCC)
$
$ g++-4.7 -c -std=c++11 small.cpp
$ clang++ -c -std=c++11 small.cpp
$
$ g++-trunk -c -std=c++11 small.cpp
small.cpp: In lambda function:
small.cpp:6:5: error: Local declaration from a different function
   [&] { __typeof (a) x; } ();
 ^
D.2029
small.cpp:6:22: note: in statement
   [&] { __typeof (a) x; } ();
  ^
_1 = (sizetype) D.2029;
small.cpp:6:5: error: Local declaration from a different function
   [&] { __typeof (a) x; } ();
 ^
D.2029
small.cpp:6:22: note: in statement
   [&] { __typeof (a) x; } ();
  ^
_5 = (sizetype) D.2029;
small.cpp:6:5: internal compiler error: verify_gimple failed
   [&] { __typeof (a) x; } ();
 ^
0xdff39f verify_gimple_in_cfg(function*, bool)
../../gcc-source-trunk/gcc/tree-cfg.c:5212
0xce9212 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1964
0xce9c0b execute_todo
../../gcc-source-trunk/gcc/passes.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


--


int i;

void foo ()
{ 
  int a[i];
  [&] { __typeof (a) x; } ();
}

[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
Might be related to PR63319.

Can you please run gcc under gdb to get a backtrace?