[Bug sanitizer/64839] libsanitizer shouldn't require

[ygribov at gcc dot gnu.org]

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

--- Comment #13 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Tue May 12 07:02:09 2015
New Revision: 223032

URL: https://gcc.gnu.org/viewcvs?rev=223032&root=gcc&view=rev
Log:
2015-05-12  Yury Gribov  

Backport from mainline
2015-04-13  Yury Gribov  

PR sanitizer/64839
* sanitizer_common/sanitizer_platform.h: Cherry pick
upstream r234470.
* sanitizer_common/sanitizer_platform_limits_posix.cc: Ditto.
* configure.ac (RPC_DEFS): Check for precense of RPC headers.
* sanitizer_common/Makefile.am (DEFS): Pass info to compiler.
* Makefile.in: Regenerate.
* asan/Makefile.in: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.
* interception/Makefile.in: Regenerate.
* libbacktrace/Makefile.in: Regenerate.
* lsan/Makefile.in: Regenerate.
* sanitizer_common/Makefile.in: Regenerate.
* tsan/Makefile.in: Regenerate.
* ubsan/Makefile.in: Regenerate.

Modified:
branches/gcc-5-branch/libsanitizer/ChangeLog
branches/gcc-5-branch/libsanitizer/Makefile.in
branches/gcc-5-branch/libsanitizer/asan/Makefile.in
branches/gcc-5-branch/libsanitizer/config.h.in
branches/gcc-5-branch/libsanitizer/configure
branches/gcc-5-branch/libsanitizer/configure.ac
branches/gcc-5-branch/libsanitizer/interception/Makefile.in
branches/gcc-5-branch/libsanitizer/libbacktrace/Makefile.in
branches/gcc-5-branch/libsanitizer/lsan/Makefile.in
branches/gcc-5-branch/libsanitizer/sanitizer_common/Makefile.am
branches/gcc-5-branch/libsanitizer/sanitizer_common/Makefile.in
branches/gcc-5-branch/libsanitizer/sanitizer_common/sanitizer_platform.h
   
branches/gcc-5-branch/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
branches/gcc-5-branch/libsanitizer/tsan/Makefile.in
branches/gcc-5-branch/libsanitizer/ubsan/Makefile.in

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 35522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35522&action=edit
gcc5-pr66112.patch

Supposedly just using SWI248 instead of SWI48 iterator should fix this, though
not sure about all the AMD scheduling stuff.

[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.

[lixin.fnst at cn dot fujitsu.com]

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

li xin  changed:

   What|Removed |Added

 CC||lixin.fnst at cn dot 
fujitsu.com

--- Comment #8 from li xin  ---
(In reply to Jason Merrill from comment #5)
> Fixed for 4.8.3/4.9.  Not fixing on 4.7 branch.

It will lead to the lsb test caes
/libstdcxx-t2c/tests/LanguageSupport/LanguageSupport FAIL.
So I want to know the right return value of std::uncaught_exception() (inside
exception-constructor).

The LSB test code is as follows:

cat main.cpp
#include 
#include 

using namespace std;
class exception_test : public exception
{
public:
bool result;
exception_test(): exception(){result = uncaught_exception();}
~exception_test() throw(){};
};

int main(int argc, char ** argv)
{
bool result;

try
{
throw exception_test();
}
catch(exception_test et)
{
result = et.result;
}
cerr << result << endl;
return 0;
}

# g++ ./main.cpp
# ./a.out
0

My GCC version is 4.9.2, the return value of result is 0,and the test is FAIL.
If the the return value of result is 1,and the test will be PASS.

[Bug target/66049] Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64*
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2015-05-12
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |6.0
  Known to fail||6.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Venkat, are you planning to submit this patch to gcc-patches?
Also, does this mean we can remove the patterns that do arith+shift using MULT
rtxes? (like *adds__multp2)

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 35522 [details]
> gcc5-pr66112.patch
> 
> Supposedly just using SWI248 instead of SWI48 iterator should fix this,
> though not sure about all the AMD scheduling stuff.

Just copy HImode patterns, as is already case with QI, SI/DImode (and we
tolerated it). We can macroize these patterns latter, if needed at all.

I wonder, why HImode patterns were left out in the first place ...

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias, missed-optimization
 Status|RESOLVED|NEW
   Last reconfirmed||2015-05-12
 CC||rguenth at gcc dot gnu.org
  Component|tree-optimization   |middle-end
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
So what happens is that GCC sees

  _3 = p_2(D)->p1;
  _3->f2 = 9;
  _5 = p_2(D)->p1;
  _5->f2 = 10;

and to remove the first store it first has to prove that _3 and _5 are equal.
CSE cannot prove this because it thinks the store to _3->f2 can clobber the
value at p_2(D)->p1 (if p->p1 points to p).

get_alias_set (_3->f2) returns 0, the alias oracle has special code to also
consider the alias set of the base objects:

  /* Do type-based disambiguation.  */
  if (base1_alias_set != base2_alias_set
  && !alias_sets_conflict_p (base1_alias_set, base2_alias_set))
return false;

but their alias sets happen to conflict because struct s2 alias set is a subset
of the struct s1 alias set (which is because alias set zero is a subset of
the struct s1 alias set...):

struct GTY(()) alias_set_entry_d {
  /* The alias set number, as stored in MEM_ALIAS_SET.  */
  alias_set_type alias_set;

  /* Nonzero if would have a child of zero: this effectively makes this
 alias set the same as alias set zero.  */
  int has_zero_child;

(I've always questioned this... - the code that looks at has_zero_child in
alias_set_subset_of / alias_sets_conflict_p).

Index: gcc/alias.c
===
--- gcc/alias.c (revision 222996)
+++ gcc/alias.c (working copy)
@@ -470,15 +470,13 @@ alias_sets_conflict_p (alias_set_type se
   /* See if the first alias set is a subset of the second.  */
   ase = get_alias_set_entry (set1);
   if (ase != 0
-  && (ase->has_zero_child
- || ase->children->get (set2)))
+  && ase->children->get (set2))
 return 1;

   /* Now do the same, but with the alias sets reversed.  */
   ase = get_alias_set_entry (set2);
   if (ase != 0
-  && (ase->has_zero_child
- || ase->children->get (set1)))
+  && ase->children->get (set1))
 return 1;

   /* The two alias sets are distinct and neither one is the

fixes this.  I don't remember what broke (but I remember trying this for a few
times - maybe with also changing alias_set_subset_of which isn't that obvious).

[Bug c++/65133] [C++11] Result type deduction proceeds even though argument deduction fails

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
Confirmed fixed for 5.1.0. I'm adding a testcase and closing the bug.

[Bug c++/65133] [C++11] Result type deduction proceeds even though argument deduction fails

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue May 12 09:03:04 2015
New Revision: 223047

URL: https://gcc.gnu.org/viewcvs?rev=223047&root=gcc&view=rev
Log:
2015-05-12  Paolo Carlini  

PR c++/65133
* g++.dg/cpp0x/trailing10.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/trailing10.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/65133] [C++11] Result type deduction proceeds even though argument deduction fails

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[gcc.hall at gmail dot com]

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

--- Comment #3 from Jeremy  ---
Related FYI,
Few instructions on ARM set the overflow flag.  Two that do are 32-bit add and
subtract.  For these two, GCC could just emit "adds" followed by "bvs" 
Instead it produces:-

bl  atoi@
add r1, r4, r0  @ tmp121, a, b
cmp r0, #0  @ b,
blt .L4 @,
cmp r1, r4  @ tmp121, a
bge .L5 @,
b   .L3 @
.L4:
cmp r1, r4  @ tmp121, a
ble .L5 @,

[Bug tree-optimization/66101] [5/6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
It's DCE leaving loops broken and not marking them for fixup.

[Bug target/65955] [arm] ICE during movcond_addsi split

[ktkachov at gcc dot gnu.org]

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue May 12 09:15:09 2015
New Revision: 223049

URL: https://gcc.gnu.org/viewcvs?rev=223049&root=gcc&view=rev
Log:
[ARM] Fix PR 65955: Do not take REGNO on non-REG operand in movcond_addsi

PR target/65955
* config/arm/arm.md (movcond_addsi): Check that operands[2] is a
REG before taking its REGNO.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Ah, it for example breaks bootstrap via (broken...) -Wstrict-aliasing:

In file included from
/space/rguenther/src/svn/trunk/gcc/../libdecnumber/bid/decimal128Local.h:1:0,
 from /space/rguenther/src/svn/trunk/gcc/dfp.c:43:
/space/rguenther/src/svn/trunk/gcc/dfp.c: In function ‘bool
decimal_real_arithmetic(real_value*, tree_code, const real_value*, const
real_value*)’:
/space/rguenther/src/svn/trunk/gcc/../libdecnumber/dpd/decimal128Local.h:40:8:
error: dereferencing type-punned pointer will break strict-aliasing rules
[-Werror=strict-aliasing]
   { (d)->bytes[WORDS_BIGENDIAN ? 0 : 15] ^= 0x80; }
^
/space/rguenther/src/svn/trunk/gcc/dfp.c:704:2: note: in expansion of macro
‘decimal128FlipSign’
  decimal128FlipSign ((decimal128 *) r->sig);
  ^
/space/rguenther/src/svn/trunk/gcc/../libdecnumber/dpd/decimal128Local.h:36:8:
error: dereferencing type-punned pointer will break strict-aliasing rules
[-Werror=strict-aliasing]
   { (d)->bytes[WORDS_BIGENDIAN ? 0 : 15] &= ~0x80; }
^
/space/rguenther/src/svn/trunk/gcc/dfp.c:714:2: note: in expansion of macro
‘decimal128ClearSign’
  decimal128ClearSign ((decimal128 *) r->sig);
  ^
/space/rguenther/src/svn/trunk/gcc/dfp.c: In function ‘void
decimal_real_maxval(real_value*, int, machine_mode)’:
/space/rguenther/src/svn/trunk/gcc/../libdecnumber/dpd/decimal128Local.h:32:8:
error: dereferencing type-punned pointer will break strict-aliasing rules
[-Werror=strict-aliasing]
   { (d)->bytes[WORDS_BIGENDIAN ? 0 : 15] |= ((unsigned) (b) << 7); }
^
/space/rguenther/src/svn/trunk/gcc/dfp.c:754:5: note: in expansion of macro
‘decimal128SetSign’
 decimal128SetSign ((decimal128 *) r->sig, 1);
 ^
cc1plus: all warnings being treated as errors
make[3]: *** [dfp.o] Error 1


I remember dfp.c _does_ violate strict-aliasing.  Trying --disable-werror.

[Bug target/66049] Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.

[vekumar at gcc dot gnu.org]

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

--- Comment #4 from vekumar at gcc dot gnu.org ---
(In reply to ktkachov from comment #3)
> Venkat, are you planning to submit this patch to gcc-patches?
> Also, does this mean we can remove the patterns that do arith+shift using
> MULT rtxes? (like *adds__multp2)

Hi Kyrill, 

Yes I am planing to submit the patch. But before that I need to test by putting
some assert and check if *adds__multp2 and similar patterns are
not used anymore.

[Bug target/65955] [arm] ICE during movcond_addsi split

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||6.0
   Target Milestone|--- |5.2
  Known to fail||4.9.3, 5.0

--- Comment #13 from ktkachov at gcc dot gnu.org ---
Fixed on trunk. Will be backporting if testing on trunk shows no problem and
testing on branches goes ok

[Bug tree-optimization/66010] [6 Regression] Missed optimization after inlining va_list parameter

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue May 12 09:46:47 2015
New Revision: 223054

URL: https://gcc.gnu.org/viewcvs?rev=223054&root=gcc&view=rev
Log:
Don't take address of ap unless necessary

2015-05-12  Tom de Vries  

PR tree-optimization/66010
* gimplify.c (gimplify_modify_expr): Handle new do_deref argument of
ifn_va_arg.
* gimplify.h (gimplify_va_arg_internal): Remove loc parameter.
(gimplify_va_arg_internal): Remove loc parameter.  Assert no
array-typed
va_lists are passed, and remove corresponding handling.
(gimplify_va_arg_expr): Only take address of ap if necessary.  Add
do_deref argument to ifn_va_arg.
* tree-stdarg.c (expand_ifn_va_arg_1): Handle new do_deref argument of
ifn_va_arg.

* c-common.c (build_va_arg): Don't mark ap addressable unless
necessary.

* gcc.dg/tree-ssa/stdarg-2.c: Undo scan xfails for f15.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/gimplify.c
trunk/gcc/gimplify.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/stdarg-2.c
trunk/gcc/tree-stdarg.c

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[rohitarulraj at gmail dot com]

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

Rohit  changed:

   What|Removed |Added

 CC||rohitarulraj at gmail dot com

--- Comment #7 from Rohit  ---
glibc build for PowerPC fails too.

[Bug tree-optimization/65961] [6 Regression] ice in vect_is_simple_use_1 with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Hmpf, so we have an operand that is both part of a regular SLP node _and_ is
part
of a SLP node that gets its operand built up from scalars.  So obviously
looking at STMT_VINFO_VECTORIZABLE (def-of-op) isn't giving the correct answer
(it depends on context).

I tried to avoid passing down the SLP node to vect_is_simple_use[_1], but that
is what it would take to fix this (well, or reject the SLP build while we
compute
STMT_VINFO_VECTORIZABLE ()).

I have to think more about what refactoring would make sense here.

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #35522|0   |1
is obsolete||
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-12
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
Created attachment 35523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35523&action=edit
gcc6-pr66112-1.patch

Generic fix, to improve minimum precision computation for unsigned values.

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 35524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35524&action=edit
gcc6-pr66112-2.patch

And i386 mulvhi4 and umulvhi4 support.  For umulvhi4, I haven't found
corresponding i386.md instruction that would emit mul{w}, so just changed SWI48
to SWI248 iterator in that case.

[Bug tree-optimization/66010] [6 Regression] Missed optimization after inlining va_list parameter

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from vries at gcc dot gnu.org ---
Patch committed, marking resolved fixed.

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
As for ARM, please file a separate enhancement request.  The generic code has
the means for backends to provide better patterns, but arm doesn't use them
(only i386.md uses them right now), so arm maintainers should add those if
needed.

[Bug target/64691] Suboptimal register allocation for bytes comparison on i386

[ysrumyan at gmail dot com]

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

Yuri Rumyantsev  changed:

   What|Removed |Added

 CC||ysrumyan at gmail dot com

--- Comment #1 from Yuri Rumyantsev  ---
I found another register allocation deficiency which can be exhibited at the
attached test-case extracted from important benchmark. If we look at inner loop
for(i = 0; i < size; i++) {
byte xr, xg, xb, t1;
sbyte t2, t3;
x1 = read[0];
x2 = read[1];
x3 = read[2];
t1 = (byte) (((C1 * x1) + (C2 * x2) + (C3 * x3) +
(1 << (SCALE - 1))) >> SCALE);
t2 = (sbyte) (((C4 * x1) + (C5 * x2) + (C6 * x3) +
(1 << (SCALE - 1))) >> SCALE);
t3 = (sbyte) (((C7 * x1) + (C8 * x2) + (C9 * x3) +
(1 << (SCALE - 1))) >> SCALE);
write[0] = t1;
write[1] = (byte) t2;
write[2] = (byte) t3;
read += 3;
write += 3;
}
we can see that 7 registers is enough to keep all variable (except for upper
loop bound): 3 registers for x1,x2,x3, 2 registers for read and write pointers
and 2 registers for computation one for t1,t2,t3  computations and one scratch
register for multiplications (but since consumers of t1,t2,t3 is byte store
this register must belong also to Q_REQS subset, i.e. AREG,BREG,CREG or DREG).
But LRA does not perform such allocation and this leads to redundant
spill/fills and results in performance degradation. Assembly file produced 6.0
compiler with "-O2 -m32 -march=slm" options is attached too.

[Bug c++/66119] New: Regression in optimization of avx-code

[joachim.schoeberl at tuwien dot ac.at]

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

Bug ID: 66119
   Summary: Regression in optimization of avx-code
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joachim.schoeberl at tuwien dot ac.at
  Target Milestone: ---

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

gcc 5.1 produces a lot of scalar moves for the attached vector-class code. 
gcc 4.9 generates compact code (see below).

compiled using:
gcc -O3 -mavx -S -std=c++11 testgcc.cpp

compiler version:
gcc (GCC) 5.1.1 20150505



gcc 5.1 works fine in any of the cases:

- we use a manual copy constructor instead of '= default' (line 37):
MyTSIMD (const MyTSIMD & s2) : data(s2.data) { ; } 

- we use the concrete vector-class instead of the template (line 45):
using MyVec = MyAVX;

- we do not use  
  __attribute__ ((__always_inline__)) 
for ComputeSomething  (line 58)



Cheers, Joachim




code generated by gcc5.1:

.globl  _Z12TestFunction4Vec2S_
.type   _Z12TestFunction4Vec2S_, @function
_Z12TestFunction4Vec2S_:
.LFB4604:
.cfi_startproc
movq72(%rsp), %rdx
vmovapd 40(%rsp), %ymm0
movq%rdi, %rax
vmovapd 8(%rsp), %ymm1
movq%rdx, -88(%rsp)
movq80(%rsp), %rdx
movq%rdx, -80(%rsp)
movq88(%rsp), %rdx
movq%rdx, -72(%rsp)
movq96(%rsp), %rdx
movq%rdx, -64(%rsp)
movq104(%rsp), %rdx
vaddpd  -88(%rsp), %ymm1, %ymm1
movq%rdx, -56(%rsp)
movq112(%rsp), %rdx
movq%rdx, -48(%rsp)
movq120(%rsp), %rdx
vmovapd %ymm1, (%rdi)
movq%rdx, -40(%rsp)
movq128(%rsp), %rdx
movq%rdx, -32(%rsp)
vaddpd  -56(%rsp), %ymm0, %ymm0
vmovapd %ymm0, 32(%rdi)
vzeroupper
ret
.cfi_endproc




code generated by gcc 4.9.2:

.type   _Z12TestFunction4Vec2S_, @function
_Z12TestFunction4Vec2S_:
.LFB2234:
.cfi_startproc
vmovapd 40(%rsp), %ymm0
movq%rdi, %rax
vmovapd 8(%rsp), %ymm1
vaddpd  104(%rsp), %ymm0, %ymm0
vaddpd  72(%rsp), %ymm1, %ymm1
vmovapd %ymm0, 32(%rdi)
vmovapd %ymm1, (%rdi)
vzeroupper
ret
.cfi_endproc

[Bug target/64691] Suboptimal register allocation for bytes comparison on i386

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
Created attachment 35526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35526&action=edit
tset-case to reproduce and assembly file.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||mikestump at comcast dot net
   Target Milestone|--- |5.2
Summary|[5.1.0 regression] (stage   |[5 regression] (stage 2)
   |2) build/genmatch segfaults |build/genmatch segfaults in
   |in operand::gen_transform   |operand::gen_transform
   |(gcc/hash-table.h:223)  |(gcc/hash-table.h:223)

--- Comment #6 from Richard Biener  ---
(In reply to Douglas Mencken from comment #5)
> (In reply to rguent...@suse.de from comment #4)
> > Can you build stage2 with debuginfo?  (--without-build-config at 
> > configure)
> > 
> > That should imrpove the backtrace.
> > 
> > Thanks,
> > Richard.
> 
> Sure I can. Here you go:
> 
> (gdb) bt
> #0  0xe208 in operand::gen_transform () at
> ../../gcc-5.1.0/gcc/hash-table.h:223
> #1  0x8530 in get_operator (id=0x808bec "tcc_comparison") at
> ../../gcc-5.1.0/gcc/genmatch.c:1495
> #2  0x9ef8 in parser::parse_operator_list (this=0xb698) at
> ../../gcc-5.1.0/gcc/genmatch.c:2941
> #3  0xd190 in parser::parse_pattern (this=0xb698) at
> ../../gcc-5.1.0/gcc/hash-table.h:223
> #4  0xe19c in parser::parser (this=0xb698, r_=0xb4f8) at
> ../../gcc-5.1.0/gcc/hash-table.h:223
> #5  0x0005f3ac in main (argc=3146720, argv=0xb4f8) at
> ../../gcc-5.1.0/gcc/genmatch.c:3711
> Current language:  auto; currently c++

Huh, the line numbers don't make any sense.

I wonder what

ld warning: atom sorting error for operand::gen_transform(__sFILE*, char
const*, bool, int, char const*, capture_info*, dt_operand**, bool) and
hash_table::find_with_hash(id_base const*,
unsigned int) in build/genmatch.o

means and if that explains things?  Like it ends up calling the wrong
function because of a linker bug?  Can you paste the linker command for
linking stage2 build/genmatch and the output when -v -Wl,-v -Wl,-debug is
appended?

As far as I understand ld on ppc-darwin is a GNU ld variant, correct?
I can't find anything in current binutils though.  Mike?

[Bug target/66120] New: __builtin_add/sub_overflow for int32_t emit poor code on ARM

[gcc.hall at gmail dot com]

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

Bug ID: 66120
   Summary: __builtin_add/sub_overflow for int32_t emit poor code
on ARM
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.hall at gmail dot com
  Target Milestone: ---

Please see related PR66112 for x86
---
#include 
#include 
int
main( int argc, const char *argv[] )
{
  int32_t result, a = (int32_t)atoi(argv[1]), b = (int32_t)atoi( argv[2] );
  if( __builtin_add_overflow( a, b, &result ) )
printf( "Overflow\n");
 else
printf( "Sum is %d\n", result );
}
--
Few instructions on ARM set the overflow flag.  Two that do are 32-bit add and
subtract.  For these two, GCC could just emit "adds" or "subs" followed by
"bvs".
Instead (from the last atoi() down) it produces:-

bl  atoi@
add r1, r4, r0  @ tmp121, a, b
cmp r0, #0  @ b,
blt .L4 @,
cmp r1, r4  @ tmp121, a
bge .L5 @,
b   .L3 @
.L4:
cmp r1, r4  @ tmp121, a
ble .L5 @,

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[gcc.hall at gmail dot com]

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

--- Comment #7 from Jeremy  ---
Comment on attachment 35522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35522
gcc5-pr66112.patch

Done, PR66120

[Bug c++/66119] [5/6 Regression] in optimization of avx-code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 CC||jakub at gcc dot gnu.org,
   ||jgreenhalgh at gcc dot gnu.org
   Target Milestone|--- |5.2
Summary|Regression in optimization  |[5/6 Regression] in
   |of avx-code |optimization of avx-code
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Broken by r217191.

[Bug c++/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Confirmed.  We expand from

  :
  a$data_13 = MEM[(struct Vec2 *)&a];
  a$32$data_14 = MEM[(struct Vec2 *)&a + 32B];
  b = b;
  v2_15 = MEM[(struct Vec2 *)&b];
  v2$32_16 = MEM[(struct Vec2 *)&b + 32B];
  _7 = a$32$data_14 + v2$32_16;
  _10 = a$data_13 + v2_15;
  MEM[(struct Vec2 *)&] = _10;
  MEM[(struct Vec2 *)& + 32B] = _7;
  return ;

in GCC 5 (note the b = b assignment) while 4.9 sees

  :
  a$data_4 = MEM[(struct Vec2 *)&a];
  a$32$data_13 = MEM[(struct Vec2 *)&a + 32B];
  v2_14 = MEM[(struct Vec2 *)&b];
  v2$32_15 = MEM[(struct Vec2 *)&b + 32B];
  _7 = a$32$data_13 + v2$32_15;
  _10 = a$data_4 + v2_14;
  MEM[(struct Vec2 *)&] = _10;
  MEM[(struct Vec2 *)& + 32B] = _7;
  return ;

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Ah, it's parameter b assigned to local decl b.

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
And we indeed rely on SRA to copy propagate aggregates.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[clyon at gcc dot gnu.org]

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

--- Comment #8 from clyon at gcc dot gnu.org ---
Can we consider moving this to -pedantic as suggested by Richard in comment #4?

Full compiler builds are broken because of this.

Thanks

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 35524 [details]
> gcc6-pr66112-2.patch
> 
> And i386 mulvhi4 and umulvhi4 support.  For umulvhi4, I haven't found
> corresponding i386.md instruction that would emit mul{w}, so just changed
> SWI48 to SWI248 iterator in that case.

No, mulw outputs to %ax:%dx pair of HImode registers! Please see [1]

[1] http://x86.renejeschke.de/html/file_module_x86_id_210.html

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
DEFPARAM (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED,
  "sra-max-scalarization-size-Ospeed",
  "Maximum size, in storage units, 

storage units!  But the value seems to be in bits?  It gets used as

if (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (var)))
<= max_scalarization_size)

max_scalarization_size is 384, the aggregate size is 512.

Looks like get_move_ratio returns different things at SRA time (if I re-call
it)
and the time it gets invoked in toplev.c.

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Fixed by

Index: toplev.c
===
--- toplev.c(revision 223044)
+++ toplev.c(working copy)
@@ -1311,6 +1311,9 @@ process_options (void)
  so we can correctly initialize debug output.  */
   no_backend = lang_hooks.post_options (&main_input_filename);

+  /* Some machines may reject certain combinations of options.  */
+  targetm.target_option.override ();
+
   /* Set default values for parameters relation to the Scalar Reduction
  of Aggregates passes (SRA and IP-SRA).  We must do this here, rather
  than in opts.c:default_options_optimization as historically these
@@ -1325,9 +1328,6 @@ process_options (void)
  get_move_ratio (false) * UNITS_PER_WORD,
  global_options.x_param_values, global_options_set.x_param_values);

-  /* Some machines may reject certain combinations of options.  */
-  targetm.target_option.override ();
-
   /* Avoid any informative notes in the second run of -fcompare-debug.  */
   if (flag_compare_debug) 
 diagnostic_inhibit_notes (global_dc);

though not sure whether a 2nd maybe_set_param_value will still allow the
target to adjust this default...

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[steffen at hauihau dot de]

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

--- Comment #31 from Steffen Hau  ---
Just a short update.

With LTO enabled, configure thinks I have a buggy GCC:
checking if gcc has a visibility bug with class-level attributes (GCC bug
26905)... yes
configure: WARNING: Your gcc is not -fvisibility=hidden safe. Disabling
visibility

I've then added -ffat-lto-objects to my ${C,CXX,Ld}FLAGS and the warning
disappeared.

The build failes at the same place, but instead of a segmentation fault I now
get a illegal instruction error:
/bin/sh: line 1: 10795 Illegal instruction SAL_USE_VCLPLUGIN=svp
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/ure/lib:$I/program"
$I/program/gengal.bin "-env:BRAND_BASE_DIR=file://$S/instdir"
"-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb 
file://$W/ComponentTarget/comphelper/util/comphelp.component 
file://$W/ComponentTarget/configmgr/source/configmgr.component 
file://$W/ComponentTarget/drawinglayer/drawinglayer.component 
file://$W/ComponentTarget/framework/util/fwk.component 
file://$W/ComponentTarget/i18npool/util/i18npool.component 
file://$W/ComponentTarget/package/source/xstor/xstor.component 
file://$W/ComponentTarget/package/util/package2.component 
file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component 
file://$W/ComponentTarget/sfx2/util/sfx.component 
file://$W/ComponentTarget/svgio/svgio.component 
file://$W/ComponentTarget/svx/util/svx.component 
file://$W/ComponentTarget/svx/util/svxcore.component 
file://$W/ComponentTarget/ucb/source/core/ucb1.component 
file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component 
file://$W/ComponentTarget/unoxml/source/service/unoxml.component"
"-env:UNO_TYPES= file://$I/program/types/offapi.rdb 
file://$I/ure/share/misc/types.rdb" -env:URE_INTERNAL_LIB_DIR=file://$I/ure/lib
-env:LO_LIB_DIR=file://$I/program --build-tree --destdir
file://$S/extras/source/gallery --name "arrows" --path $W/Gallery/arrows
--filenames file://$RESPONSEFILE
/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/solenv/gbuild/Gallery.mk:72:
recipe for target
'/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done'
failed
make[1]: ***
[/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done]
Error 132
make[1]: *** Waiting for unfinished jobs

[Bug sanitizer/64839] libsanitizer shouldn't require

[thierry.reding at gmail dot com]

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

--- Comment #14 from Thierry Reding  ---
Thanks Yury.

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #7 from James Greenhalgh  ---
(In reply to Richard Biener from comment #5)
> DEFPARAM (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED,
>   "sra-max-scalarization-size-Ospeed",
>   "Maximum size, in storage units, 
> 
> storage units!  But the value seems to be in bits?  It gets used as
> 
> if (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (var)))
> <= max_scalarization_size)
> 

Well, that part should have been covered by:

+  unsigned max_scalarization_size
+= (optimize_function_for_size_p (cfun)
+   ? PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SIZE)
+   : PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED))
+  * BITS_PER_UNIT;

>From the original patch, 

> Looks like get_move_ratio returns different things at SRA time (if I re-call
> it)
> and the time it gets invoked in toplev.c.

But, yes these parameters will cause a difference in code generation if
previously MOVE_RATIO could return different values at different times, as it
might well have if target_option_override set up a structure used by
MOVE_RATIO.

The patch I applied carries the hidden assumption that MOVE_RATIO is constant.
Clearly there are a number of situations we might not want that to be true
(say, for switchable targets - which I don't think your patch will help).

[Bug sanitizer/64839] libsanitizer shouldn't require

[y.gribov at samsung dot com]

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

--- Comment #15 from Yury Gribov  ---
(In reply to Thierry Reding from comment #14)
> Thanks Yury.

Np, you are welcome.

@Harald: could you close the bug if it works for you?

[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to li xin from comment #8)
> It will lead to the lsb test caes
> /libstdcxx-t2c/tests/LanguageSupport/LanguageSupport FAIL.
> So I want to know the right return value of std::uncaught_exception()
> (inside exception-constructor).

What isn't clear about the bug report? The right value is the one G++ gives
now.

The LSB test is wrong.

[Bug sanitizer/64839] libsanitizer shouldn't require

[geoff at geoff dot codes]

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

Geoff Nixon  changed:

   What|Removed |Added

 CC||geoff at geoff dot codes

--- Comment #16 from Geoff Nixon  ---
Sorry to be an idiot, but I just ran into this building from the 5.1 release
tarball. Is the patch attached to this bug (dated 2015-04-10) what I should use
to patch against the release? Or is there a different set of changes specific
to the 5.1 branch backport?

[Bug c++/66121] New: internal compiler error: in strip_typedefs, at cp/tree.c:1369

[dennis.demidov at gmail dot com]

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

Bug ID: 66121
   Summary: internal compiler error: in strip_typedefs, at
cp/tree.c:1369
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dennis.demidov at gmail dot com
  Target Milestone: ---

Created attachment 35527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35527&action=edit
The preprocessed code stripped with the delta tool.

The following code (reduced from [vexcl](https://github.com/ddemidov/vexcl)
library) leads to an internal compiler error:

$ cat strip_typedefs_ice.cpp
#include 
typedef int32_t cl_int __attribute__((aligned(4)));
struct buffer_unmapper {
void operator()(cl_int* ptr) const {
}
};
typedef std::unique_ptr mapped_array;

$ g++ -c -std=c++11 strip_typedefs_ice.cpp  
strip_typedefs_ice.cpp:7:50: internal compiler error: in strip_typedefs, at
cp/tree.c:1369
 typedef std::unique_ptr mapped_array;
  ^

[Bug sanitizer/64839] libsanitizer shouldn't require

[y.gribov at samsung dot com]

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

--- Comment #17 from Yury Gribov  ---
(In reply to Geoff Nixon from comment #16)
> what I should use to patch against the release?
> Or is there a different set of changes
> specific to the 5.1 branch backport?

For 5.1 you'd better use the patch in gcc-5-branch:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=223032

[Bug middle-end/66084] ICE:internal compiler error: in fold_convert_loc, at fold-const.c:1974

[zhongyunde at huawei dot com]

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

--- Comment #4 from vfdff  ---
ok, it is ok based on gcc 4.9.2, thanks.
$GCC492/gcc ticket_1634.c -O2

[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Tue May 12 11:55:40 2015
New Revision: 223059

URL: https://gcc.gnu.org/viewcvs?rev=223059&root=gcc&view=rev
Log:
2015-05-12  Richard Biener  

PR tree-optimization/37021
* tree-vectorizer.h (struct _slp_tree): Add two_operators flag.
(SLP_TREE_TWO_OPERATORS): New define.
* tree-vect-slp.c (vect_create_new_slp_node): Initialize
SLP_TREE_TWO_OPERATORS.
(vect_build_slp_tree_1): Allow two mixing plus/minus in an
SLP node.
(vect_build_slp_tree): Adjust.
(vect_analyze_slp_cost_1): Likewise.
(vect_schedule_slp_instance): Vectorize mixing plus/minus by
emitting two vector stmts and mixing the results.

* gcc.target/i386/vect-addsub.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/vect-addsub.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vectorizer.h

[Bug sanitizer/64839] libsanitizer shouldn't require

[geoff at geoff dot codes]

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

--- Comment #18 from Geoff Nixon  ---
Ok thanks, for other idiots like myself who can't seem to figure out how to get
viewvc to generate a diff for a specific rev, a -p1 patch is:

svn diff -c 223032 svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch

Or if you don't have subversion installed, here:
http://gist.github.com/anonymous/7f239960c46240d83a67/raw

[Bug c/66122] New: Bad uninlining decisions

[vda.linux at googlemail dot com]

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

Bug ID: 66122
   Summary: Bad uninlining decisions
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vda.linux at googlemail dot com
  Target Milestone: ---

On linux kernel build, I found thousands of cases where functions which are
expected (by programmer) to be inlined, aren't actually inlined.

The following script is used to find them:

nm --size-sort vmlinux | grep -iF ' t ' | uniq -c | grep -v '^ *1 ' | sort -rn

It caltually finds functions which have same name, size, and occur more than
once. There are a few false positives, but vast majority of them are functions
which were supposed to be inlined, but weren't:

(Count) (size) (name)
473 000b t spin_unlock_irqrestore
449 005f t rcu_read_unlock
355 0009 t atomic_inc
353 006e t rcu_read_lock
350 0075 t rcu_read_lock_sched_held
291 000b t spin_unlock
266 0019 t arch_local_irq_restore
215 000b t spin_lock
180 0011 t kzalloc
165 0012 t list_add_tail
161 0019 t arch_local_save_flags
153 0016 t test_and_set_bit
134 000b t spin_unlock_irq
134 0009 t atomic_dec
130 000b t spin_unlock_bh
122 0010 t brelse
120 0016 t test_and_clear_bit
120 000b t spin_lock_irq
119 001e t get_dma_ops
117 0053 t cpumask_next
116 0036 t kref_get
114 001a t schedule_work
106 000b t spin_lock_bh
103 0019 t arch_local_irq_disable
 98 0014 t atomic_dec_and_test
 83 0020 t sg_page
 81 0037 t cpumask_check
 79 0036 t pskb_may_pull
 72 0044 t perf_fetch_caller_regs
 70 002f t cpumask_next
 68 0036 t clk_prepare_enable
 65 0018 t pci_write_config_byte
 65 0013 t tasklet_schedule
 61 0023 t init_completion
 60 002b t trace_handle_return
 59 0043 t nlmsg_trim
 59 0019 t pci_read_config_dword
 59 000c t slow_down_io
...
...

Note tiny sizes of some functions. Let's take a look at atomic_inc:

static inline void atomic_inc(atomic_t *v)
{
asm volatile(LOCK_PREFIX "incl %0"
 : "+m" (v->counter));
}

You would imagine that this won't ever be deinlined, right? It's one assembly
instruction. Well, it isn't always inlined. Here's the disassembly of vmlinux:

81003000 :
81003000:   55  push   %rbp
81003001:   48 89 e5mov%rsp,%rbp
81003004:   f0 ff 07lock incl (%rdi)
81003007:   5d  pop%rbp
81003008:   c3  retq

This can be fixed using __always_inline, but kernel developers hesitate to slap
thousands of __always_inline everywhere, the mood is that this is a compiler's
fault and it should not be accomodated for, but fixed.

This happens quite easily with -Os (IOW: with CC_OPTIMIZE_FOR_SIZE=y kernel
build), but -O2 is not immune either.

I found a file which exhibits an example of bad deinlining for both -O2 and -Os
and I'm going to attach it.

[Bug c/66122] Bad uninlining decisions

[vda.linux at googlemail dot com]

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

--- Comment #1 from Denis Vlasenko  ---
Created attachment 35528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35528&action=edit
Preprocessed example exhibiting a bug

This is a preprocessed kernel/locking/mutex.c file from kernel source.
When built with either -O2 or -Os, it wrongly deinlines spin_lock() and
spin_unlock():

$ gcc -O2 -c mutex.preprocessed.c -o mutex.preprocessed.o
$ objdump -dr mutex.preprocessed.o
mutex.preprocessed.o: file format elf64-x86-64
Disassembly of section .text:
 :
   0:   80 07 01addb   $0x1,(%rdi)
   3:   c3  retq
   4:   66 66 66 2e 0f 1f 84data32 data32 nopw %cs:0x0(%rax,%rax,1)
   b:   00 00 00 00 00
0010 <__mutex_init>:
...
0040 :
  40:   e9 00 00 00 00  jmpq   45 
41: R_X86_64_PC32   _raw_spin_lock-0x4
  45:   66 66 2e 0f 1f 84 00data32 nopw %cs:0x0(%rax,%rax,1)
  4c:   00 00 00 00

These functions are defined as:

static inline __attribute__((no_instrument_function)) void
spin_unlock(spinlock_t *lock)
{
 __raw_spin_unlock(&lock->rlock);
}

static inline __attribute__((no_instrument_function)) void spin_lock(spinlock_t
*lock)
{
 _raw_spin_lock(&lock->rlock);
}

and programmer's intent was that they will always be inlined.

This is with gcc-4.7.2

[Bug c++/66091] [c++-concepts] Overloading of member operators based on constraints rejected; regression from r211591

[andrew.n.sutton at gmail dot com]

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

--- Comment #1 from Andrew Sutton  ---

Confirmed. Fixed in r223061.

When a function declaration started with a non-function declarator, the
requires-clause wasn't being attached to the right declarator object so it
wasn't being added to the declaration.

[Bug c/66123] New: Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[SztfG at yandex dot ru]

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

Bug ID: 66123
   Summary: Array of labels as values + ternary operator + pointer
arithmetic = internal compiler error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---

Created attachment 35529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35529&action=edit
Preprocessed source

bug.c: In function ‘test’:
bug.c:1:5: internal compiler error: Segmentation fault

Target: x86_64-linux-gnu
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

Code in attachment

It also produces internal compiler error for ARM and ARM64 target

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
$ ./cc1 -quiet x.c -O
x.c: In function ‘test’:
x.c:2:1: internal compiler error: Segmentation fault
 test (int foo)
 ^
0xd7129c crash_signal
/home/marek/src/gcc/gcc/toplev.c:380
0xecc3e3 propagate_rhs_into_lhs
/home/marek/src/gcc/gcc/tree-ssa-dom.c:2945
0xecc660 eliminate_const_or_copy
/home/marek/src/gcc/gcc/tree-ssa-dom.c:3017
0xecc7c4 eliminate_degenerate_phis_1
/home/marek/src/gcc/gcc/tree-ssa-dom.c:3054
0xecc817 eliminate_degenerate_phis_1
/home/marek/src/gcc/gcc/tree-ssa-dom.c:3061
0xecc817 eliminate_degenerate_phis_1
/home/marek/src/gcc/gcc/tree-ssa-dom.c:3061
0xecc921 execute
/home/marek/src/gcc/gcc/tree-ssa-dom.c:3155
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 CC||mpolacek at gcc dot gnu.org
  Component|c   |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed, ICEs since gcc 4.6.

int
test (int foo)
{
  static void *dummy[] = { &&a, &&b };
  goto *((char *) &&b - 2 * (foo < 0));
a:
b:
  return 0;
}

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 CC||vehre at gcc dot gnu.org
Summary|elemental dependency|[6 Regression] elemental
   |mishandling when derived|dependency mishandling when
   |types are involved  |derived types are involved
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
The code in comment 0 does not abort at run time up to revision r222352
(2015-04-23), but does so at r222398 (2015-04-24), likely r222361.

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c  (revision 223044)
+++ tree-ssa-dom.c  (working copy)
@@ -2914,7 +2914,7 @@ propagate_rhs_into_lhs (gimple stmt, tre
  else
val = gimple_goto_dest  (use_stmt);

- if (val && is_gimple_min_invariant (val))
+ if (val && TREE_CODE (val) == INTEGER_CST)
{
  basic_block bb = gimple_bb (use_stmt);
  edge te = find_taken_edge (bb, val);

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Or rather

Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c  (revision 223044)
+++ tree-ssa-dom.c  (working copy)
@@ -2918,6 +2918,8 @@ propagate_rhs_into_lhs (gimple stmt, tre
{
  basic_block bb = gimple_bb (use_stmt);
  edge te = find_taken_edge (bb, val);
+ if (te)
+   {
  edge_iterator ei;
  edge e;
  gimple_stmt_iterator gsi;
@@ -2961,6 +2963,7 @@ propagate_rhs_into_lhs (gimple stmt, tre
  te->flags |= EDGE_FALLTHRU;
  if (te->probability > REG_BR_PROB_BASE)
te->probability = REG_BR_PROB_BASE;
+   }
}
}
}

if computed goto removal should work.

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c/66122] Bad uninlining decisions

[vda.linux at googlemail dot com]

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

--- Comment #2 from Denis Vlasenko  ---
Tested with gcc-4.9.2. The attached testcase doesn't exhibit the bug, but
compiling the same kernel tree, with the same .config, and then running

nm --size-sort vmlinux | grep -iF ' t ' | uniq -c | grep -v '^ *1 ' | sort -rn

reveals that now other functions get wrongly deinlined:

  8 0028 t acpi_os_allocate_zeroed
  7 0011 t dst_output_sk
  7 000b t hweight_long
  5 0023 t umask_show
  5 000f t init_once
  4 0047 t uni2char
  4 0028 t cmask_show
  4 0025 t inv_show
  4 0025 t edge_show
  4 0020 t char2uni
  4 001f t event_show
  4 001d t acpi_node
  4 0012 t t_stop
  4 0012 t dst_discard
  4 0011 t kzalloc
  4 000b t udp_lib_close
  4 0006 t udp_lib_hash
  3 0059 t get_expiry
  3 0025 t __uncore_inv_show
  3 0025 t __uncore_edge_show
  3 0023 t __uncore_umask_show
  3 0023 t name_show
  3 0022 t acpi_os_allocate
  3 001f t __uncore_event_show
  3 000d t cpumask_set_cpu
  3 000a t nofill
...
...

For example, hweight_long:

static inline unsigned long hweight_long(unsigned long w)
{
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
}

wasn't expected by programmer to be deinlined. But it was:

81009c40 :
81009c40:   55  push   %rbp
81009c41:   e8 da eb 31 00  callq  81328820
<__sw_hweight64>
81009c46:   48 89 e5mov%rsp,%rbp
81009c49:   5d  pop%rbp
81009c4a:   c3  retq   
81009c4b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

I'm going to find and attach a file which deinlines hweight_long.

[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Target|arm*-*gnueabi   |arm
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
Confirmed.  Looks like the ARM port needs to implement the addv3 and
subv3 patterns; although those do not appear to be documented in the
internals manual.

[Bug c/66000] Suggestion: more than one "not declared in this scope" per line

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
(In reply to Michael Darling from comment #0)
> With the code
>nonExistantClass varName = nonExistantFunction();
> 
> gcc 5.1.0 gives
>error: `nonExistantClass' was not declared in this scope
>   nonExistantClass varName = nonExistantFunction();
>   ^
> 
> It might be better if it ALSO gave:
>error: `nonExistantFunction' was not declared in this scope
>   nonExistantClass varName = nonExistantFunction();
>  ^

idk, this might lengthen the error output considerably for files with a lot of
undeclared identifiers in them...

[Bug fortran/66102] dependency mishandling with reallocation on assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
The code segfault at run time when compiled with 4.5 to 4.7 and aborts with 4.8
and above.

[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Not those, but addv4 and subv4 instead (perhaps {,u}mulv4 if
the ISA detects multiplication overflows, also there is negv3).

[Bug c/66122] Bad uninlining decisions

[vda.linux at googlemail dot com]

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

--- Comment #3 from Denis Vlasenko  ---
Created attachment 35530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35530&action=edit
Preprocessed example exhibiting a bug on gcc -4.9.2

This is a preprocessed kernel/pid.c file from kernel source.
When built with -O2, it wrongly deinlines hweight_long.

$ gcc -O2 -c pid.preprocessed.c -o kernel.pid.o
$ objdump -dr kernel.pid.o | grep -A3 hweight_long
 :
   0:   e8 00 00 00 00  callq  5 
1: R_X86_64_PC32__sw_hweight64-0x4
   5:   c3  retq
$ gcc -v 2>&1 | tail -1
gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)

[Bug target/66081] Invalid ARM ldrb instruction offset

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Target||arm
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Earnshaw  ---
There's nothing invalid about that instruction.  The Thumb-2 ISA has a 4-byte
LDRB opcode that supports larger offsets.

[Bug ipa/65740] spectacularly bad inlinining decisions with -Os

[vda.linux at googlemail dot com]

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

Denis Vlasenko  changed:

   What|Removed |Added

 CC||vda.linux at googlemail dot com

--- Comment #3 from Denis Vlasenko  ---
Bug 66122 contains more information, and a recipe how to find many examples
using linux kernel build.

For one, this is not limited to -Os (it does happen with -Os way more easily).

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Bootstrapped / tested on x86_64 with --disable-werror

Running target unix/
FAIL: gcc.dg/alias-2.c  (test for warnings, line 14)
FAIL: gcc.dg/alias-2.c (test for excess errors)

Running target unix//-m32
FAIL: gcc.dg/alias-2.c  (test for warnings, line 14)
FAIL: gcc.dg/alias-2.c (test for excess errors)

[Bug c++/66124] New: greg_month.cpp from boost date_time shows internal compiler error: Segmentation fault

[wilkinson.bob at gmail dot com]

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

Bug ID: 66124
   Summary: greg_month.cpp from boost date_time shows internal
compiler error: Segmentation fault
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilkinson.bob at gmail dot com
  Target Milestone: ---

Created attachment 35531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35531&action=edit
gzipped version of grep_month.ii

I use the most recently packaged version of gcc for AIX 5.3 packaged by IBM and
available from
ftp://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/gcc/

The version I used is :

bash-4.2# csum *.rpm
0a0ad6f0228d2ebba18d6632f946f15f  gcc-4.2.0-3.aix5.3.ppc.rpm
01757ef0a46f062a9a5dcf487b809a3e  gcc-cplusplus-4.2.0-3.aix5.3.ppc.rpm
69a0cdd26b841db4401cc96a238c31bf  gcc-locale-4.2.0-3.aix5.3.ppc.rpm
1e6665b79e21e87a2664a510c04dbf48  libffi-4.2.0-3.aix5.3.ppc.rpm
9579df6d8c21fa74827604c6be336685  libffi-devel-4.2.0-3.aix5.3.ppc.rpm
1f23e47835f96d9a48074c7e29e2f625  libgcc-4.2.0-3.aix5.3.ppc.rpm
ba0044da1a5a45fde81ea80fa9bbd984  libgomp-4.2.0-3.aix5.3.ppc.rpm
59a82bf0df8087b549a3c1a66501ada6  libstdcplusplus-4.2.0-3.aix5.3.ppc.rpm
4e390df393af6fde78d2f36017d0de07  libstdcplusplus-devel-4.2.0-3.aix5.3.ppc.rpm
bash-4.2# oslevel -s
5300-12-04-1119
bash-4.2# 

I try to compile my (large) software project but see 

internal compiler error: Segmentation fault while compiling greg_month.cpp from
boost date_time.

Details suggested on https://gcc.gnu.org/bugs/ follow and the file
greg_month.ii is attached (though I had to compress it with gzip so that it was
under the file size limit).

bash-4.2# cat gmbuild 
g++ -v -save-temps -Wall -Wextra -c -mminimal-toc -maix32 -fPIC -O0 -g1
-fvisibility=default -fPIC -I/home/bob/work/trunk/3rdparty/boost_1_49_0 -shared
-I /home/bob/work/trunk/common/basic/cppunit/include -D_REENTRANT=1
-DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_TEST_DYN_LINK=1 -Daix=1 -Dbigendian=1
-Dunix=1
-I3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/include
-I3rdparty/boost_1_49_0/libs/date_time/include
-I3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/res
-I3rdparty/boost_1_49_0/libs/date_time/res -Icommon/include -Icommon/basic
-Iunix/common/include
3rdparty/boost_1_49_0/libs/date_time/src/gregorian/greg_month.cpp

bash-4.2# bash gmbuild
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enable-languages=c,c++,java --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs --host=powerpc-ibm-aix5.3.0.0
--target=powerpc-ibm-aix5.3.0.0 --build=powerpc-ibm-aix5.3.0.0
--disable-libjava-multilib
Thread model: aix
gcc version 4.2.0
 /opt/freeware/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/cc1plus -E -quiet -v
-I/home/bob/work/trunk/3rdparty/boost_1_49_0 -I
/home/bob/work/trunk/common/basic/cppunit/include
-I3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/include
-I3rdparty/boost_1_49_0/libs/date_time/include
-I3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/res
-I3rdparty/boost_1_49_0/libs/date_time/res -Icommon/include -Icommon/basic
-Iunix/common/include -D_ALL_SOURCE -D_REENTRANT=1 -DBOOST_DATE_TIME_DYN_LINK=1
-DBOOST_TEST_DYN_LINK=1 -Daix=1 -Dbigendian=1 -Dunix=1
3rdparty/boost_1_49_0/libs/date_time/src/gregorian/greg_month.cpp -mminimal-toc
-maix32 -Wall -Wextra -fvisibility=default -fPIC -fworking-directory -O0
-fpch-preprocess -o greg_month.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/../../../../powerpc-ibm-aix5.3.0.0/include"
ignoring nonexistent directory
"3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/include"
ignoring nonexistent directory "3rdparty/boost_1_49_0/libs/date_time/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/bob/work/trunk/3rdparty/boost_1_49_0
 /home/bob/work/trunk/common/basic/cppunit/include

3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/res
 3rdparty/boost_1_49_0/libs/date_time/res
 common/include
 common/basic
 unix/common/include
 /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include/c++

/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include/c++/powerpc-ibm-aix5.3.0.0
 /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include/c++/backward
 /opt/freeware/include
 /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include
 /usr/include
End of search list.
 /opt/freeware/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/cc1plus -fpreprocessed
greg_month.ii -quiet -dumpbase greg_month.cpp -mminimal-toc -maix32 -auxbase
greg_month -g1 -O0 -Wall -Wextra -version -fvisibility=de

[Bug c/66122] Bad uninlining decisions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
gcc 4.7 is not supported anymore, so there is no point reporting issues against
it.
As for #c3, that got fixed (well, improved, inline unlike always_inline
attribute is just an optimization hint) by r219108, which is certainly not
backportable to 4.9 branch.

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[carloscastro10 at hotmail dot com]

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

carloscastro10 at hotmail dot com changed:

   What|Removed |Added

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

--- Comment #9 from carloscastro10 at hotmail dot com ---
__alignof__(__m128i) is 16, just like __alignof__(long) is 8 and
__alignof__(int) is 4. However, if I have a pointer to long or a pointer to
int, the memory addresses pointed at by those pointers can be aligned to any
byte boundary. Assuming that the address pointed at by a pointer to __m128i is
aligned to a 16-byte boundary is not a correct assumption, especially when
compiling with -mavx. It prevents proper modeling in debug mode of access to
unaligned operands in memory. This problem is also present with the __m256i
type. In AVX, aligned memory load operations (_mm256_load_si256 and similar)
are the exceptions in that they require pointers to aligned memory addresses.
Most AVX operations accept unaligned addresses.

[Bug lto/66125] New: lto1: code model kernel does not support PIC mode

[dimhen at gmail dot com]

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

Bug ID: 66125
   Summary: lto1: code model kernel does not support PIC mode
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r222758 PASS
r222759 FAIL

Alas, I had no compact testcase.

But 'argv[i] --> filename' change is not clear for me.
At least, it"s not mentioned in ChangeLog :)

$ svn diff -c222759 gcc/lto-wrapper.c
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c   (revision 222758)
+++ gcc/lto-wrapper.c   (revision 222759)
@@ -934,7 +934,7 @@
  filename[p - argv[i]] = '\0';
  file_offset = (off_t) loffset;
}
-  fd = open (argv[i], O_RDONLY);
+  fd = open (filename, O_RDONLY | O_BINARY);
   if (fd == -1)
{
  lto_argv[lto_argc++] = argv[i];

[Bug c/66122] Bad uninlining decisions

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
The last time I looked at the kernel build with -Os, all cases
were simply caused by:

ipa-inline.c:
 820   /* If call is cold, do not inline when function body would grow. */  
 821   else if (!e->maybe_hot_p ()  
 822&& (growth >= MAX_INLINE_INSNS_SINGLE   
 823|| growth_likely_positive (callee, growth)))
 824 {  
 825   e->inline_failed = CIF_UNLIKELY_CALL;
 826   want_inline = false; 
 827 }  
 828 }

[Bug c++/66096] Unexpected __gnu_cxx::__concurrence_lock_error with _GLIBCXX_DEBUG

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target|32 bit  |x86_64-w64-mingw32
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-12
   Host|Windows 7 x64   |x86_64-w64-mingw32
 Ever confirmed|0   |1
  Build|g++.EXE (tdm-1) 4.9.2   |
   |Copyright (C) 2014 Free |
   |Software Foundation, Inc.   |

--- Comment #3 from Jonathan Wakely  ---
This report is not very useful without a stack trace showing where the
exception is thrown. I suspect it's a mingw-w64 problem as it doesn't happen on
other targets, so there may be nothing to fix in the upstream libstdc++ code.

As requested at https://gcc.gnu.org/bugs/ please provide the output of 'gcc -v'
not just the version number.

[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  ---
That's what I meant.  Still can't find any info on them in md.texi, though!

[Bug tree-optimization/66101] [5 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue May 12 13:28:33 2015
New Revision: 223065

URL: https://gcc.gnu.org/viewcvs?rev=223065&root=gcc&view=rev
Log:
2015-05-12  Richard Biener  

PR tree-optimization/66101
* tree-ssa-dce.c (remove_dead_stmt): Properly mark loops for
fixup if we turn a loop exit edge to a fallthru edge.

* gcc.dg/torture/pr66101.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr66101.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dce.c

[Bug tree-optimization/66101] [5 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression] internal   |[5 Regression] internal
   |compiler error: in  |compiler error: in
   |verify_loop_structure, at   |verify_loop_structure, at
   |cfgloop.c:1662  |cfgloop.c:1662
  Known to fail||5.1.0

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
Mul doesn't produce useful overflow bits when the flags are set.  We could do
negv3.

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to carloscastro10 from comment #9)
> __alignof__(__m128i) is 16, just like __alignof__(long) is 8 and
> __alignof__(int) is 4. However, if I have a pointer to long or a pointer to
> int, the memory addresses pointed at by those pointers can be aligned to any
> byte boundary.

That is not the case, please read the C or C++ standards.

> Assuming that the address pointed at by a pointer to __m128i
> is aligned to a 16-byte boundary is not a correct assumption, especially
> when compiling with -mavx. It prevents proper modeling in debug mode of
> access to unaligned operands in memory. This problem is also present with
> the __m256i type. In AVX, aligned memory load operations (_mm256_load_si256
> and similar) are the exceptions in that they require pointers to aligned
> memory addresses. Most AVX operations accept unaligned addresses.

One thing is how the HW instructions look like, another is the language you're
writing this in (C/C++), that isn't necessarily the same thing.
As I said, you really shouldn't add *(__m128i*) or similar (other __m128*,
__m256*, custom vector_size attribute defined types, etc.) dereferences if the
pointer isn't suitably aligned.  Use the unaligned loads and the compiler for
-mavx will when optimizing combine them where possible with the actual vector
arithmetics etc. instructions.

[Bug lto/66125] lto1: code model kernel does not support PIC mode

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Testcase?  The fix makes options from archive members visible to lto-wrapper,
so you likely have a mismatch between -fPIC / -fno-PIC somehwere.

[Bug lto/66125] lto1: code model kernel does not support PIC mode

[dimhen at gmail dot com]

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

--- Comment #2 from Dmitry G. Dyachenko  ---
(In reply to Richard Biener from comment #1)
> Testcase?  The fix makes options from archive members visible to lto-wrapper,
> so you likely have a mismatch between -fPIC / -fno-PIC somehwere.

After reading PR65559 sounds like my FAIL

[Bug lto/66125] lto1: code model kernel does not support PIC mode

[dimhen at gmail dot com]

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

Dmitry G. Dyachenko  changed:

   What|Removed |Added

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

--- Comment #3 from Dmitry G. Dyachenko  ---
(In reply to Richard Biener from comment #1)
> Testcase?  The fix makes options from archive members visible to lto-wrapper,
> so you likely have a mismatch between -fPIC / -fno-PIC somehwere.

Yes, you are right : I have mismatch between -fPIC / -fno-PIC.

[Bug c/66126] New: 2-float SSE vector with vector_size(8) is passed incorrectly to functions on x86

[tanel.kriik at outlook dot com]

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

Bug ID: 66126
   Summary: 2-float SSE vector with vector_size(8) is passed
incorrectly to functions on x86
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tanel.kriik at outlook dot com
  Target Milestone: ---

Created attachment 35532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35532&action=edit
Preprocessed source code of the original program

GCC version: 4.8.4
System type: i386-unknown-openbsd5.7
Configured with: /usr/obj/ports/gcc-4.8.4/gcc-4.8.4/configure --enable-libgcj
--without-jar --verbose --program-transform-name='s,^,e,' --disable-nls
--with-system-zlib --disable-libmudflap --disable-libgomp --disable-tls
--with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-ld --with-gnu-as
--enable-threads=posix --enable-wchar_t --with-gmp=/usr/local
--enable-languages=c,c++,fortran,objc,java,ada --disable-libstdcxx-pch
--enable-cpp --enable-shared --prefix=/usr/local --sysconfdir=/etc
--mandir=/usr/local/man --infodir=/usr/local/info --localstatedir=/var
--disable-silent-rules --disable-gtk-doc

Defining a 2D float vector with vector_size(8) produces a type that doesn't
seem to be passed correctly to functions.


#include 

typedef float vec2f __attribute__ ((vector_size(8)));

static void vec2f_print(vec2f v)
{
printf("%f %f\n", v[0], v[1]);
}

int main(void)
{
vec2f v = {1, 3};
vec2f_print(v);
printf("%f %f\n", v[0], v[1]);

return 0;
}


Compiling the code above with 'gcc -msse' and running it produces the following
output:

-nan -nan
1.00 3.00

The first line should be same as the second line because the vector is just
passed to a function that prints the first and second float in the vector while
the second output line is the result of printing the 2 floats directly without
a function call. If I apply optimization when compiling, the result is correct,
probably due to eliminating the simple function call.

I get similar behaviour on my 64-bit Ubuntu machine when the same program is
compiled in 32-bit mode (-m32).

This bug doesn't appear on x86-64, otherwise.

[Bug target/66126] 2-float SSE vector with vector_size(8) is passed incorrectly to functions on x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
  Component|c   |target
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
i?86 passes it in %mm0 (oops) (with -msse2), even if the function is externally
visible.

I think -msse shouldn't change the ABI.

[Bug c++/66124] greg_month.cpp from boost date_time shows internal compiler error: Segmentation fault

[wilkinson.bob at gmail dot com]

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

--- Comment #1 from wilkinson.bob at gmail dot com ---
More succinctly my failing compilation can be reduced to :

g++ -v -save-temps -Wall -Wextra -c
-I/home/bob/work/trunk/3rdparty/boost_1_49_0
3rdparty/boost_1_49_0/libs/date_time/src/gregorian/greg_month.cpp

which exhibits the same failure.

[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Created attachment 35533
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35533&action=edit
Suggested fix

I've been testing following patch for 5.1.0 branch. I'm wondering if comparison
of just TYPE_ARG_TYPES is sufficient?

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #3)
> The code in comment 0 does not abort at run time up to revision r222352
> (2015-04-23), but does so at r222398 (2015-04-24), likely r222361.

Yes, probably the change in gfc_add_loop_ss_code (which comment #1 removes).

[Bug rtl-optimization/56766] Fails to combine (vec_select (vec_concat ...)) to (vec_merge ...)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 CC||uros at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
The vectorizer patch is now in (I added a testcase for addsubps because for
that
it happens to work).

We still need to fixup the sse3_addsubv2df3 pattern or fix combine to try
multiple "canonical" forms of vec_merge vs. (vec_select (vec_concat ...)).
Or decide which one is canonical (I'd prefer simply dropping vec_merge - with
AVX512 we've run out of bits for the CONST_INT selector)

One issue with the vec_select form is that it requires an intermediate mode of
double-size while vec_merge avoids this.

Eventually one can also teach combine that certain (vec_select (vec_concat ..))
can be treated as (vec_merge ...).

void testd (double * __restrict__ p, double * __restrict q)
{
  p[0] = p[0] - q[0];
  p[1] = p[1] + q[1];
}

should vectorize to addsubpd with -msse3.

[Bug target/66126] 2-float SSE vector with vector_size(8) is passed incorrectly to functions on x86

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)
> i?86 passes it in %mm0 (oops) (with -msse2), even if the function is
> externally visible.
> 
> I think -msse shouldn't change the ABI.

8-byte vectors are passed to functions in mmx registers. This is part of 32bit
ABI. The 64bit ABI is different, 8-byte vectors are passed in sse registers.

The problem is that when mmx register is referenced, shared x87/mmx register
stack switches into mmx mode until emms is executed. When in mmx mode, all x87
registers show nan.

This is not a gcc bug.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[vp at gcc dot gnu.org]

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

--- Comment #9 from Vidya Praveen  ---
glibc's tz code (which causes this error) will get fixed  eventually:
https://sourceware.org/bugzilla/show_bug.cgi?id=18396

However if it's justifiable, it's good to move this error under -pedantic.

[Bug middle-end/66127] New: Division by zero gets folded away

[mpolacek at gcc dot gnu.org]

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

Bug ID: 66127
   Summary: Division by zero gets folded away
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

In match.pd, we have

(simplify
 (mult @0 integer_zerop@1)
 @1)

so anything * 0 -> 0.  That seems to be undesirable in case "anything" contains
a division by zero.  And a few lines below we have

/* Make sure to preserve divisions by zero.  This is the reason why
   we don't simplify x / x to 1 or 0 / x to 0.  */
(for op (mult trunc_div ceil_div floor_div round_div exact_div)
  (simplify
(op @0 integer_onep)
(non_lvalue @0)))

This means that
int
main (void)
{
  int z = 0;
  int a = 0 * (1 / z);
  return a;
}
$ xgcc f.c; ./a.out
is "ok", but e.g.
int
main (void)
{
  int z = 0;
  int a = 1 * (1 / z);
  return a;
}
naturally results in SIGFPE.

Yes, I know that division by zero is UB and there are no guarantees whatsoever,
but this folding is causing me a grief in the C FE because while fold doesn't
fold away "1 / 0", it folds "0 * (1 / 0)" into 0.  That's bad when we find
ourselves in a situation where a constant integer expression is required.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-12
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #10 from Marek Polacek  ---
Working on this, but it isn't a simple matter of adding "pedantic".

[Bug middle-end/66127] Division by zero gets folded away

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Ideally the front-end folding of expressions-of-constants might avoid 
folding-for-optimization such as this (instead just folding cases where 
the evaluated operands are actually constants, so not folding anything 
where 1 / 0 is an evaluated operand).

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #11 from Manuel López-Ibáñez  ---
(In reply to Marek Polacek from comment #10)
> Working on this, but it isn't a simple matter of adding "pedantic".

Joseph, would testing global_dc->pedantic_errors be an acceptable work-around
(with a big ??? note) while a better solution is found?

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[joseph at codesourcery dot com]

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

--- Comment #12 from joseph at codesourcery dot com  ---
On Tue, 12 May 2015, manu at gcc dot gnu.org wrote:

> > Working on this, but it isn't a simple matter of adding "pedantic".
> 
> Joseph, would testing global_dc->pedantic_errors be an acceptable work-around
> (with a big ??? note) while a better solution is found?

If you want a workaround, a test for "pedantic" would be the natural 
workaround, but I think the proper fix is folding as I described at 
 to allow these 
cases to reach the existing pedwarn-if-pedantic logic.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
I expect to have a proper fix (additional folding in c_fully_fold_internal)
today or tomorrow, depends on how many issues I hit along the way (see e.g.
PR66127).  The tzdata issue seems to be being worked on, so I think the
"pedantic" stopgap isn't needed right now.

[Bug middle-end/66127] Division by zero gets folded away

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to jos...@codesourcery.com from comment #1)
> Ideally the front-end folding of expressions-of-constants might avoid 
> folding-for-optimization such as this (instead just folding cases where 
> the evaluated operands are actually constants, so not folding anything 
> where 1 / 0 is an evaluated operand).

I understand that Marek is saying that currently: "1 / 0" is not folded, but "0
* (1 / 0)" is folded into 0.

The answer is that we really need to separate the FE folding from the ME one,
and do only FE folding for language conformance purposes, while we can do ME
folding for warnings and when the FE is finished.  Isn't this what you explain
in text quoted at A.5 at https://gcc.gnu.org/wiki/Better_Diagnostics?

This will also liberate the ME to do optimizations that before could not do
because we wanted to reject invalid programs with -pedantic-errors.

I seem to remember there has been further discussion about this after or while
match.pd was implemented, discussing whether it was worth it that the FE saves
the GIMPLE generated when doing FE folding (or ME folding in case of FE
warnings requesting it), but I cannot find a link now.

[Bug c++/53553] misleading locations for error in initializers

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tromey at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Tom Tromey  ---
Dup; preferring the other bug since it is assigned.

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

[Bug c++/61940] Wrong error location for error in initialization list

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

 CC||akim.demaille at gmail dot com

--- Comment #3 from Tom Tromey  ---
*** Bug 53553 has been marked as a duplicate of this bug. ***

[Bug c++/61940] Wrong error location for error in initialization list

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

 CC||jan.kratochvil at redhat dot 
com

--- Comment #4 from Tom Tromey  ---
*** Bug 59621 has been marked as a duplicate of this bug. ***

[Bug c++/59621] wrong caret / lineno for wrong ctor field initializer

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||tromey at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Tom Tromey  ---
Dup; preferring the other bug since it is assigned.

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

[Bug fortran/66128] New: ICE for some intrinsics with zero sized array parameter

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

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

Bug ID: 66128
   Summary: ICE for some intrinsics with zero sized array
parameter
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This simplified code snippet with a zero sized array parameter z ...
   program p
  integer, parameter :: z(0) = 0
  print *, any(z > 0)
  print *, all(z > 0)
   end

or this variation ...
   program p
  integer, parameter :: z(1:0) = 0
  print *, any(z > 0)
  print *, all(z > 0)
   end

prints (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
internal compiler error: in gfc_conv_intrinsic_anyall, at
fortran/trans-intrinsic.c:3149

Whereas, without declaring z as a parameter it works, e.g.
   program p
  integer :: z(0) = 0
  print *, any(z > 0)
  print *, all(z > 0)
   end

Kind regards.