[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org ---
Yes, there are a few remaining. I changed the code on trunk to avoid all those
casts completely.

[Bug c++/67372] New: Functions created via cp/decl2.c:start_objects not properly registered

[rguenth at gcc dot gnu.org]

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

Bug ID: 67372
   Summary: Functions created via cp/decl2.c:start_objects not
properly registered
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, jason at gcc dot gnu.org
  Target Milestone: ---

Those never go through cgraph::finalize_function or rest_of_decl_compilation.
Eventually they get created a cgraph node for via c-genericize here:

  /* Dump all nested functions now.  */
  cgn = cgraph_node::get_create (fndecl);
  for (cgn = cgn-nested; cgn ; cgn = cgn-next_nested)
c_genericize (cgn-decl);

this causes us to not generate any early debug for those functions (which
might be desired but then those decls should be DECL_IGNORED_P, not just
DECL_ARTIFICIAL - there is some ObjC use I don't grok and VTV use).

Removing the above get_create will create the cgraph node from
decl_init_priority_insert (in the VTV case) which happens via
lang_hooks.decls.post_compilation_parsing_cleanups which happens
_after_ finalizing the CU.

This is from debugging an ICE (missed early debug DIE) with LTO early debug
and g++.dg/ubsan/pr59437.C

STH is rotten here regarding to symtab correctness I think.  Not sure what
debug info we want for DECL_ARTIFICIAL functions that do not have an
(non-artificial) abstract origin but are not DECL_IGNORED_P.

[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h

[bshastry at sec dot t-labs.tu-berlin.de]

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

--- Comment #12 from Bhargava Shastry bshastry at sec dot t-labs.tu-berlin.de 
---
Also, I noticed a couple of potentially suspicious casts not fixed upstream.
They are in _S_right [1] and elsewhere.

The problem I see is this:
a. _M_right is a pointer to an object of type _Rb_tree_node_base
b. _Link_type is a pointer to an object of type _Rb_tree_node_Val that is
derived from _Rb_tree_node_base
b. _M_right points to an object of type _Rb_tree_node_base in init() [2] and
reset() [3]

a) and b) together imply that it is possible that _M_right points to an object
of type _Rb_tree_node_base when cast to _Link_type in [1]. Is this a matter for
concern?


[1]:
https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/libstdc%2B%2B-v3/include/bits/stl_tree.h?view=markuppathrev=223811#l685
[2]:
https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/libstdc%2B%2B-v3/include/bits/stl_tree.h?view=markuppathrev=223811#l614
[3]:
https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/libstdc%2B%2B-v3/include/bits/stl_tree.h?view=markuppathrev=223811#l604

[Bug c++/67371] New: Never executed throw in constexpr function fails to compile

[ldionne.2 at gmail dot com]

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

Bug ID: 67371
   Summary: Never executed throw in constexpr function fails to
compile
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code fails to compile on GCC trunk:

constexpr void f() {
if (false)
throw;
}


The error is:

[snip]: In function 'constexpr void f()':
[snip]: error: expression 'throw-expression' is not a constant-expression
 }
 ^


The code should compile because the throw expression is never executed inside a
constexpr context. Clang indeed compiles this just fine.

Live example: http://melpon.org/wandbox/permlink/V0g96xpWdO2eWGNx

[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Bhargava Shastry from comment #12)
 a) and b) together imply that it is possible that _M_right points to an
 object of type _Rb_tree_node_base when cast to _Link_type in [1]. Is this a
 matter for concern?

Not especially, because we never dereference it except when it really does
point to the derived type.

We might be able to replace those with reinterpret_cast, or just return the
base pointer and delay the cast until needed.

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 27 Aug 2015, rearnsha at gcc dot gnu.org wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
 
 --- Comment #9 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
 Does that really do the right thing?  That is, does force_reg understand a
 misaligned memory op?
 
 Also, what if one memory operand is aligned, but the other not?  Don't we want
 to have the right combination of aligned/misaligned instructions?

I think you never get two MEMs, you at most get a constant on the
RHS of a store.

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[ramana at gcc dot gnu.org]

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

--- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---

(In reply to rguent...@suse.de from comment #10)
 On Thu, 27 Aug 2015, rearnsha at gcc dot gnu.org wrote:
 
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
  
  --- Comment #9 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
  Does that really do the right thing?  That is, does force_reg understand a
  misaligned memory op?

In practice I think yes.

  
  Also, what if one memory operand is aligned, but the other not?  Don't we 
  want
  to have the right combination of aligned/misaligned instructions?
 
 I think you never get two MEMs, you at most get a constant on the
 RHS of a store.

Yep that's my understanding too. movmisalignmode has stricter rules compared
to movmode so we have to handle some of these carefully. The logic in here is
essentially from neon.md : movmisalignmode, so some of it may not be relevant
here in the scalar case, but it's probably better to be a bit defensive here.

I tried playing with the HImode case but the pain I had was with the fact that
HImode movmisalign expects a load into a HImode register and I hadn't got my
head around that given other things I needed to finish up before leaving.

[Bug target/67356] PowerPC insn does not satisfy its constraints

[amodra at gcc dot gnu.org]

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

--- Comment #2 from Alan Modra amodra at gcc dot gnu.org ---
Author: amodra
Date: Thu Aug 27 13:56:39 2015
New Revision: 227260

URL: https://gcc.gnu.org/viewcvs?rev=227260root=gccview=rev
Log:
[RS6000] Correct constraints for iormode_mask

iormode_mask always splits to rtl matching rotlmode3_insert.  The
latter requires one of its input operands match the output, so let
reload/lra know the equivalent operand match must also occur for
iormode_mask.

PR target/67356
* config/rs6000/rs6000.md (iormode_mask): Use constraint 0
for operand 1.


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

[Bug target/67356] PowerPC insn does not satisfy its constraints

[amodra at gmail dot com]

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

Alan Modra amodra at gmail dot com changed:

   What|Removed |Added

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

--- Comment #3 from Alan Modra amodra at gmail dot com ---
fixed

[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org ---
In fact I also already fixed it on the gcc-5 branch, see r223811. The 5.1.0
sources are not current.

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[rearnsha at gcc dot gnu.org]

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

--- Comment #9 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Does that really do the right thing?  That is, does force_reg understand a
misaligned memory op?

Also, what if one memory operand is aligned, but the other not?  Don't we want
to have the right combination of aligned/misaligned instructions?

[Bug tree-optimization/67283] GCC regression over inlining of returned structures

[roche at httrack dot com]

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

--- Comment #10 from Xavier Roche roche at httrack dot com ---
The Second test case attached should produce exactly the same bytes
(byte-to-byte) for the two demo_1 and demo_2 functions. And this would not rely
on stack size that might change.

With GCC 4.4.7:

demo_2():
subq$72, %rsp
movl$0, 32(%rsp)
movq32(%rsp), %rax
movq$0, 48(%rsp)
movq$0, 40(%rsp)
movq$0, 8(%rsp)
movq$0, 16(%rsp)
movq%rax, (%rsp)
callsome_unknown_function(foo)
addq$72, %rsp
ret
demo_1():
subq$72, %rsp
movl$0, 32(%rsp)
movq32(%rsp), %rax
movq$0, 48(%rsp)
movq$0, 40(%rsp)
movq$0, 8(%rsp)
movq$0, 16(%rsp)
movq%rax, (%rsp)
callsome_unknown_function(foo)
addq$72, %rsp
ret

[Bug tree-optimization/67283] GCC regression over inlining of returned structures

[alalaw01 at gcc dot gnu.org]

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

--- Comment #7 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Thu Aug 27 15:40:10 2015
New Revision: 227265

URL: https://gcc.gnu.org/viewcvs?rev=227265root=gccview=rev
Log:
completely_scalarize arrays as well as records

gcc/:

PR tree-optimization/67283
* tree-sra.c (type_consists_of_records_p): Rename to...
(scalarizable_type_p): ...this, add case for ARRAY_TYPE.

(completely_scalarize_record): Rename to...
(completely_scalarize): ...this, add ARRAY_TYPE case, move some code
to:
(scalarize_elem): New.

gcc/testsuite/:

* gcc.dg/tree-ssa/sra-15.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-15.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug tree-optimization/67283] GCC regression over inlining of returned structures

[roche at httrack dot com]

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

--- Comment #9 from Xavier Roche roche at httrack dot com ---
Created attachment 36260
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36260action=edit
Second test case (might be useful for unit testing)

[Bug tree-optimization/67283] GCC regression over inlining of returned structures

[roche at httrack dot com]

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

--- Comment #11 from Xavier Roche roche at httrack dot com ---
PS: Shall I create a twin ticket for the structure case ?

[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org ---
Fixed.

[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Thu Aug 27 17:07:35 2015
New Revision: 227268

URL: https://gcc.gnu.org/viewcvs?rev=227268root=gccview=rev
Log:
PR middle-end/67005
* tree-ssa-dce.c (remove_dead_stmt): Also schedule fixup if removing
an entry into an irreducible region.

* gcc.dg/torture/pr67005.c: New test.

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

[Bug libstdc++/67374] New: std::cbegin can't call valarray range access functions

[redi at gcc dot gnu.org]

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

Bug ID: 67374
   Summary: std::cbegin can't call valarray range access functions
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: redi at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This fails:

#include valarray
#include iterator

int main()
{
  std::valarrayint v;
  std::cbegin(v);
}

The problem is that the begin overloads in valarray are not declared before
the non-member functions in bits/range_access.h so can't be called from
there.

This works:

namespace std {
templateclass _Tp
  struct valarray;

templateclass _Tp
inline _Tp*
begin(valarray_Tp __va);

  /**
   *  @brief  Return an iterator pointing to the first element of
   *  the const valarray.
   *  @param  __va  valarray.
   */
  templateclass _Tp
inline const _Tp*
begin(const valarray_Tp __va);

}

#include valarray
#include iterator

int main()
{
  std::valarrayint v;
  std::cbegin(v);
}

[Bug libstdc++/67374] std::cbegin can't call valarray range access functions

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-27
 Ever confirmed|0   |1

[Bug bootstrap/67373] New: Can't compile gcc snapshot for avr target with mingw

[kontakt at michaelstather dot com]

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

Bug ID: 67373
   Summary: Can't compile gcc snapshot for avr target with mingw
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kontakt at michaelstather dot com
  Target Milestone: ---

Created attachment 36259
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36259action=edit
config.log

I tried compiling a snapshot from gcc6 for avr target with mingw.

I configured with:

mkdir install-avr
mkdir obj-avr
cd obj-avr
../configure --prefix=/c/gcc-6-20150823/install-avr --target=avr
--enable-languages=c,c++ --disable-nls --disable-libssp

configure succeded, then I ran make which failed with:
checking for suffix of object files... configure: error in
/c/gcc-6-20150823/obj-avr/avr/libgcc
configure: error: cannot compute suffix of object files: cannot compile

Attached is obj-avr/avr/config.log

[Bug tree-optimization/67283] GCC regression over inlining of returned structures

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org

--- Comment #8 from alalaw01 at gcc dot gnu.org ---
I believe this should now be fixed. Do we want a testcase, and if so is there a
good way to scan for the stack usage pattern (as observed in the assembler)?
One can scan-assembler times for addq.*%rsp, but fixing the constant 72 seems
rather fragile, and I don't see a dejagnu way to scan for the constant being
the same in each demoN()...

And the case of unions is still not handled!!

[Bug lto/66752] spec2000 255.vortex performance compiled with GCC is ~20% lower than with CLANG

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law law at redhat dot com ---
The fix for the ppc64 bootstrap regression looks good.  I'm just having a bear
of a time producing a reasonable test for the regression suite.

[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356

[ldionne.2 at gmail dot com]

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

--- Comment #4 from Louis Dionne ldionne.2 at gmail dot com ---
Still fails on trunk. Out of curiosity Markus, do you use software to reduce 
test cases? Did you generate these A, B, ... structs yourself?

Anyway, I was able to reduce to the following:

--
template typename T
T declval();

template typename ...
struct expand;

template typename ...Xn
struct closure {
closure();

template typename ...Yn, typename = expand
decltype(Xn(declvalYn()))...

closure(Yn ...);

template typename ...Yn
closure(closureYn...);
};

int main() {
closureclosure empty{};
closureclosure copy(empty);
}
--


The command line and output (formatted to fit the report) are:

--
 ~/code/gcc/prefix/bin/g++ --version
g++ (GCC) 6.0.0 20150827 (experimental)

 ~/code/gcc/prefix/bin/g++ -std=c++14 test/worksheet.cpp
test/worksheet.cpp: In substitution of ‘
templateclass ... Yn 
closureXn::closure(closureYn ...) [with Yn = missing]’:

test/worksheet.cpp:1573:31:   required by substitution of ‘
templateclass ... Yn, class 
closureXn::closure(Yn ...) [with Yn = closureclosure ; 
   template-parameter-1-2 = missing]’

test/worksheet.cpp:1584:34:   required from here
test/worksheet.cpp:1573:31: internal compiler error: 
tree check: expected class ‘expression’, have ‘exceptional’ 
(argument_pack_select) in tree_operand_check, at tree.h:3356

 template typename ...Yn, typename = expand
   ^
--

[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Aug 27 18:29:37 2015
New Revision: 227271

URL: https://gcc.gnu.org/viewcvs?rev=227271root=gccview=rev
Log:
PR target/67317
* config/i386/i386.md (*addmode3_cc): Remove insn pattern.
(addqi3_cc): Ditto.
(UNSPEC_ADD_CARRY): Remove.
(addqi3_cconly_overflow): New expander.
(*adddwi3_doubleword): Split to addmode3_cconly_overflow.
Adjust for changed addmode3_carry.
(*negdwi2_doubleword): Adjust for changed addmode3_carry.
(*subdwi3_doubleword): Adjust for changed submode3_carry.
(plusminus_insnmode3_carry): Remove expander.
(*plusminus_insnmode3_carry): Split insn pattern to
addmode3_carry and submode3_carry.
(plusminus_carry_mnemonic): Remove code attribute.
(addmode3_carry): Canonicalize insn pattern.
(*addsi3_carry_zext): Ditto.
(submode3_carry): Ditto.
(*subsi3_carry_zext): Ditto.
(adcxmode3): Remove insn pattern.
(addcarrymode): New insn pattern.
(subborrowmode): Ditto.
* config/i386/i386.c (ix86_expand_strlensi_unroll_1): Use
gen_addqi3_cconly_overflow instead of gen_addqi3_cc.
(ix86_expand_builtin) case IX86_BUILTIN_SBB32,
case IX86_BUILTIN_SBB64, case IX86_BUILTIN_ADDCARRY32,
case IX86_BUILTIN_ADDCARRY64: Use CODE_FOR_subborrowsi,
CODE_FOR_subborrowdi, CODE_FOR_addcarrysi and CODE_FOR_addcarrydi.
Rewrite expander to not clobber carry flag chains.

testsuite/ChangeLog:

PR target/67317
* gcc.target/i386/pr67317-1.c: New test.
* gcc.target/i386/pr67317-2.c: Ditto.
* gcc.target/i386/pr67317-3.c: Ditto.
* gcc.target/i386/pr67317-4.c: Ditto.
* gcc.target/i386/adx-addcarryx32-1.c: Also scan for adcl.
* gcc.target/i386/adx-addcarryx32-2.c: Also scan for adcq.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr67317-1.c
trunk/gcc/testsuite/gcc.target/i386/pr67317-2.c
trunk/gcc/testsuite/gcc.target/i386/pr67317-3.c
trunk/gcc/testsuite/gcc.target/i386/pr67317-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/adx-addcarryx32-1.c
trunk/gcc/testsuite/gcc.target/i386/adx-addcarryx64-1.c

[Bug libstdc++/67374] std::cbegin can't call valarray range access functions

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Thu Aug 27 19:05:19 2015
New Revision: 227274

URL: https://gcc.gnu.org/viewcvs?rev=227274root=gccview=rev
Log:
PR libstdc++/67374
* include/bits/range_access.h (valarray, begin, end): Declare.
* testsuite/26_numerics/valarray/range_access.cc: Test const
overloads.
* testsuite/26_numerics/valarray/range_access2.cc: New.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/valarray/range_access2.cc
  - copied, changed from r227257,
trunk/libstdc++-v3/testsuite/26_numerics/valarray/range_access.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/range_access.h
trunk/libstdc++-v3/testsuite/26_numerics/valarray/range_access.cc

[Bug libstdc++/67374] std::cbegin can't call valarray range access functions

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

Version|4.9.4   |5.2.1
   Target Milestone|--- |5.3
  Known to fail||5.2.0, 6.0

[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion

[ldionne.2 at gmail dot com]

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

Louis Dionne ldionne.2 at gmail dot com changed:

   What|Removed |Added

 CC||ldionne.2 at gmail dot com

--- Comment #4 from Louis Dionne ldionne.2 at gmail dot com ---
The following code triggers the same warning on GCC trunk:

--
struct Object { int method(int) const { return 0; } };

template typename ...T void expand(T...);
template int ... struct index_sequence { };

template typename ...
struct TemplateStruct {
static constexpr Object get_object() { return {}; }

template int ...i
static void f(index_sequencei...) {
constexpr auto object = get_object(); // only fires with 'auto'
expand(object.method(i)...);
}
};

template void TemplateStruct::f(index_sequence);
--

The warning is:

[snip]: In instantiation of ‘
static void TemplateStruct template-parameter-1-1
::f(index_sequencei ...) [with int ...i = {};
  template-parameter-1-1 = {}]’:
[snip]:   required from here
[snip]: warning: variable ‘object’ set but not used
[-Wunused-but-set-variable]
 constexpr auto object = get_object(); // only fires with 'auto'
^


This is very annoying because that will cause perfectly fine code to emit 
warnings when used with empty parameter packs. Also surprising is that the 
warning goes away if either

(1) A non-template struct is used instead of TemplateStruct
(2) One uses `Object object = ...` instead of `auto object = ...`

which makes it obvious that this is a bug, not a feature. Please fix your
compiler, or metaprogrammers all around the world will hate you for forcing
them to write

constexpr auto object = get_object();
(void)object; // workaround GCC false positive
expand(object.method(i)...);

in every place where a variable may be 'unused' when a parameter pack is empty.

[Bug fortran/67367] Program crashes on READ(IOSTAT=IOS, ...) on directory OPEN()ed without error

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #1)
 Program received signal SIGSEGV, Segmentation fault.
 0x77ba152e in buf_read (s=0x6063b0, buf=optimized out, 
 nbyte=optimized out) at ../../../trunk/libgfortran/io/unix.c:535
 535 memcpy (p, s-buffer, did_read);

There are a bunch of bugs lurking in fortran/io.c.
For example, flush(iostat=ios) causes a problem.

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #23 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Created attachment 36261
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36261action=edit
tree-slp-details dump

Ah, I was looking at the code in the test suite this time, rather than the raw
posted code, so the line numbers changed for the dejagnu commands.  The
statement number is now 12.

Attaching the details dump for SLP.

[Bug middle-end/63510] Wrong line number in Wstrict-overflow message

[gang.chen.5i5j at gmail dot com]

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

--- Comment #9 from Chen Gang gang.chen.5i5j at gmail dot com ---
We need call warning_at() instead of warnings() in fold_overflow_warning() in
gcc/fold-const.c.

The related location parameter of warning_at() should be calculated, just like
another gcc files has done: e.g. gcc/c-family/*.c which use warning_at().

I shall continue to analyze how to calculate the location in gcc/fold-const.c,
reference from the other files.

Thanks.

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #22 from Bill Schmidt wschmidt at gcc dot gnu.org ---
(In reply to Richard Biener from comment #21)
 (In reply to Bill Schmidt from comment #20)

...snip...
 
 I see it only failing due to cost issues (tried ppc64le and -mcpu=power8).
 The unaligned loads cost 3 and we end up with
 
 t.f90:8:0: note: Cost model analysis:
   Vector inside of loop cost: 40
   Vector prologue cost: 8
   Vector epilogue cost: 4
   Scalar iteration cost: 12
   Scalar outside cost: 6
   Vector outside cost: 12
   prologue iterations: 0
   epilogue iterations: 0
 t.f90:8:0: note: cost model: the vector iteration cost = 40 divided by the
 scalar iteration cost = 12 is greater or equal to the vectorization factor =
 1.
 
 Note that we are (still) not very good in estimating the SLP cost as we
 account 4 vector loads here (because we essentially will end up with
 4 different permutations used), so the unaligned part is accounted for
 too much and likely the permutation cost as well.  Both are a limitation
 of the SLP data structures and not easily fixable.  With
 -fvect-cost-model=unlimited I see both loops vectorized.

Yes, I get these same results for the loop vectorizer (using -O2
-ftree-vectorize -mcpu=power8 -ffast-math).  But I was looking at the failure
to do SLP vectorization.  In comment 19 you indicated this was now working,
presumably on x86, but for Power we fail to SLP-vectorize
fast-math-pr37021.f90:9:0.

However, with today's trunk my SLP dump looks slightly different so I need to
have another look at whether this is still failing due to alignment or
something else.  I'll comment again when I've dug into it further.

[Bug libstdc++/67375] New: abi::__cxa_demangle crashes demangling a lambda

[l337.h4x0r at gmail dot com]

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

Bug ID: 67375
   Summary: abi::__cxa_demangle crashes demangling a lambda
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: l337.h4x0r at gmail dot com
  Target Milestone: ---

Here's how I reproduce this crash in __cxa_demangle:
-
$ cat test.cpp
#include stdio.h
#include cxxabi.h

int main()
{
  printf(%s\n,
abi::__cxa_demangle(_ZNSt9_AAA_9_M_bbIPZN5c10DD20INS1_10FFEEEvRT_EUlvE_EES6_v,
NULL, NULL, NULL));
}

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.2-0ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-0ubuntu1~14.04)

$ g++ -o test test.cpp

$ gdb test
(gdb) run
(gdb) bt
...
#32477 0x77b32c56 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#32478 0x77b30e04 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#32479 0x77b31019 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#32480 0x77b31473 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#32481 0x77b31019 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#32482 0x77b3269b in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#32483 0x77b32c56 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#32484 0x77b37266 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#32485 0x77b374fa in __cxa_demangle () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#32486 0x00400673 in main ()
–

[Bug tree-optimization/67351] Missed optimisation on 64-bit field compared to 32-bit

[ubizjak at gmail dot com]

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

Uroš Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Target|i?86|x86_64
 CC||hs.naveen2u at gmail dot com
  Component|target  |tree-optimization

--- Comment #7 from Uroš Bizjak ubizjak at gmail dot com ---
Adding CC.

[Bug c++/67371] Never executed throw in constexpr function fails to compile

[ldionne.2 at gmail dot com]

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

--- Comment #1 from Louis Dionne ldionne.2 at gmail dot com ---
This is almost certainly a duplicate of #66026, yet it is still unconfirmed.

[Bug c++/67376] New: Comparison with pointer to past-the-end of array fails inside constant expression

[ldionne.2 at gmail dot com]

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

Bug ID: 67376
   Summary: Comparison with pointer to past-the-end of array fails
inside constant expression
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code fails to compile on GCC trunk:

struct array {
int elems_[1];
};

constexpr array a{{0}};
static_assert(a.elems_ != a.elems_ + 1, );

The error (formatted to fit the report) is

[snip]: error: non-constant condition for static assertion
 static_assert(a.elems_ != a.elems_ + 1, );
 ^
[snip]: error: ‘(((const int*)( a.array::elems_)) != 
(((const int*)( a.array::elems_)) + 4u))’ 
is not a constant expression
 static_assert(a.elems_ != a.elems_ + 1, );
^

It seems like GCC does not like the fact that we're comparing a past-the-end
pointer. But then again, that's weird because the following code works fine:

constexpr int a[1] = {0};
static_assert(a != a + 1, );

Live example: http://melpon.org/wandbox/permlink/4QKMVN5vm3ePJcpY

[Bug c/67377] New: gcc 6.0 fails to compile on Darwin 14

[juergen.reuter at desy dot de]

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

Bug ID: 67377
   Summary: gcc 6.0 fails to compile on Darwin 14
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

When compiling gcc (svn r227279) on Darwin 14.5.0 with Xcode 6.4, clang Apple
LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0, I get the compile error: 
test -f config.h || (rm -f stamp-h1 
/Applications/Xcode.app/Contents/Developer/usr/bin/make stamp-h1)
true AR_FLAGS=rc CC_FOR_BUILD=gcc CFLAGS=-g  CXXFLAGS=-g 
CFLAGS_FOR_BUILD=-g -O2 CFLAGS_FOR_TARGET=-g -O2
INSTALL=/opt/local/bin/ginstall -c INSTALL_DATA=/opt/local/bin/ginstall -c
-m 644 INSTALL_PROGRAM=/opt/local/bin/ginstall -c
INSTALL_SCRIPT=/opt/local/bin/ginstall -c LDFLAGS=-Wl,-no_pie 
LIBCFLAGS=-g -O2 LIBCFLAGS_FOR_TARGET=-g -O2
MAKE=/Applications/Xcode.app/Contents/Developer/usr/bin/make
MAKEINFO=makeinfo --split-size=500 --split-size=500
--split-size=500  PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh
EXPECT=expect RUNTEST=runtest RUNTESTFLAGS= exec_prefix=/usr/local
infodir=/usr/local/share/info libdir=/usr/local/lib prefix=/usr/local
tooldir=/usr/local/x86_64-apple-darwin14.5.0 AR=ar AS=as CC=gcc
CXX=g++ -std=gnu++98
LD=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
LIBCFLAGS=-g -O2 NM=nm PICFLAG= RANLIB=ranlib DESTDIR= DO=all
multi-do # /Applications/Xcode.app/Contents/Developer/usr/bin/make
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
true  DO=all multi-do # /Applications/Xcode.app/Contents/Developer/usr/bin/make
test -f config.h || (rm -f stamp-h1 
/Applications/Xcode.app/Contents/Developer/usr/bin/make stamp-h1)
make[3]: Nothing to be done for `all'.
g++ -std=gnu++98 -fno-PIE -c  -DTARGET_NAME=\x86_64-apple-darwin14.5.0\ -g 
-DIN_GCC-fno-strict-aliasing -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include
-I/usr/local//include -I/usr/local//include -I/usr/local//include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc/../libbacktrace   -o toplev.o -MT toplev.o -MMD -MP -MF
./.deps/toplev.TPo ../../gcc/toplev.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
[]
../../gcc/toplev.c:1320:10: error: use of undeclared identifier
'flag_loop_block'
  || flag_loop_block
 ^
../../gcc/toplev.c:1321:10: error: use of undeclared identifier
'flag_loop_interchange'
  || flag_loop_interchange
 ^
../../gcc/toplev.c:1322:10: error: use of undeclared identifier
'flag_loop_strip_mine'
  || flag_loop_strip_mine
 ^

This has probably to do with changes from Yosemite 10.10.4-10.10.5, or with
Xcode 6.4 (quite unlikely) or any changes in gcc between r226713 and r227279. 
When using r276713, toplevel.c compiles but then I'm stuck with:
The directory that should contain system headers does not exist:
  /usr/include
What puzzles me is that MAC OS X/clang tries to compile the C code in gcc by
means of g++ -std=gnu++98 and then issuing a warning that this behavior is
deprecated. I'll do a few check, but someone else should have been stumbled
over those things, too.

[Bug c/67377] gcc 6.0 fails to compile on Darwin 14

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
First remark from my side: the error with the missing /usr/install came from an
incompletely installed MAC OS X command line tools, sorry for the digression.

[Bug c++/66135] trailing return type error for generic lambda

[ldionne.2 at gmail dot com]

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

Louis Dionne ldionne.2 at gmail dot com changed:

   What|Removed |Added

 CC||ldionne.2 at gmail dot com

--- Comment #2 from Louis Dionne ldionne.2 at gmail dot com ---
Another test case:

template typename T
void f(T) {
[](auto x) - decltype(x.foo()) { };
}

template void f(int);

And a variation, which also yields an invalid x has incomplete type error:

template typename T
void f(T) {
[](auto x) - decltype(x.foo()) { };
}

template void f(int);

[Bug libstdc++/67362] std::regex(((.), std::regex_constants::basic) throws

[timshen at gcc dot gnu.org]

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

--- Comment #3 from Tim Shen timshen at gcc dot gnu.org ---
Author: timshen
Date: Fri Aug 28 03:39:53 2015
New Revision: 227291

URL: https://gcc.gnu.org/viewcvs?rev=227291root=gccview=rev
Log:
Backport from mainline
2015-08-28  Tim Shen  tims...@google.com

PR libstdc++/67362
* include/bits/regex_scanner.tcc (_Scanner::_M_scan_normal):
Always returns ordinary char token if the char isn't
considered a special char.
* testsuite/28_regex/regression.cc: New test file for collecting
regression testcases from, typically, bugzilla.

Added:
branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/regression.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex_scanner.tcc

[Bug libstdc++/67362] std::regex(((.), std::regex_constants::basic) throws

[timshen at gcc dot gnu.org]

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

Tim Shen timshen at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from Tim Shen timshen at gcc dot gnu.org ---
Fixed.

[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Louis Dionne from comment #4)
 Still fails on trunk. Out of curiosity Markus, do you use software to reduce 
 test cases? Did you generate these A, B, ... structs yourself?

I normally just use https://github.com/csmith-project/creduce .
But, as your testcase shows, you can sometimes reduce testcases further by
hand.

[Bug libstdc++/67362] std::regex(((.), std::regex_constants::basic) throws

[timshen at gcc dot gnu.org]

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

--- Comment #1 from Tim Shen timshen at gcc dot gnu.org ---
Author: timshen
Date: Fri Aug 28 02:35:21 2015
New Revision: 227289

URL: https://gcc.gnu.org/viewcvs?rev=227289root=gccview=rev
Log:
PR libstdc++/67362
* include/bits/regex_scanner.tcc (_Scanner::_M_scan_normal):
Always returns ordinary char token if the char isn't
considered a special char.
* testsuite/28_regex/regression.cc: New test file for collecting
regression testcases from, typically, bugzilla.

Added:
trunk/libstdc++-v3/testsuite/28_regex/regression.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/regex_scanner.tcc

[Bug c++/67371] Never executed throw in constexpr function fails to compile

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf trippels at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-28
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.2.1, 6.0

--- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Switch statements are rejected, too:

constexpr int fun(int n) {
  switch (n) {
  case 0:
return 1;
  default:
throw;
  }
}
static_assert(fun(0), );

Only the ternary operator works fine.

[Bug libstdc++/67362] std::regex(((.), std::regex_constants::basic) throws

[timshen at gcc dot gnu.org]

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

--- Comment #2 from Tim Shen timshen at gcc dot gnu.org ---
Author: timshen
Date: Fri Aug 28 03:03:55 2015
New Revision: 227290

URL: https://gcc.gnu.org/viewcvs?rev=227290root=gccview=rev
Log:
Backport from mainline
2015-08-28  Tim Shen  tims...@google.com

PR libstdc++/67362
* include/bits/regex_scanner.tcc (_Scanner::_M_scan_normal):
Always returns ordinary char token if the char isn't
considered a special char.
* testsuite/28_regex/regression.cc: New test file for collecting
regression testcases from, typically, bugzilla.

Added:
branches/gcc-5-branch/libstdc++-v3/testsuite/28_regex/regression.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/regex_scanner.tcc

[Bug tree-optimization/53852] [4.9/5/6 Regression] -ftree-loop-linear: large compile time / memory usage

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:

   What|Removed |Added

   Last reconfirmed|2013-02-03 00:00:00 |2015-8-28
 CC||spop at gcc dot gnu.org
  Known to fail||6.0

--- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 
---
since today on trunk this also triggers for options such as -floop-block, which
didn't trigger this before.

[Bug c++/66026] C++14] throw-expression is not a valid constant-expression

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf trippels at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Lets merge this one with pr67371.

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

[Bug c++/67371] Never executed throw in constexpr function fails to compile

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf trippels at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rhalbersma at gmail dot com

--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
*** Bug 66026 has been marked as a duplicate of this bug. ***

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 27 Aug 2015, rearnsha at gcc dot gnu.org wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
 
 --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
 (In reply to Richard Biener from comment #1)
  I think this boils down to the fact that memcpy expansion is done too late
  and
  that (with more recent GCC) the inlining done on the GIMPLE level is
  restricted
  to !SLOW_UNALIGNED_ACCESS but arm defines STRICT_ALIGNMENT to 1
  unconditionally.
  
 
 Yep, we have to define STRICT_ALIGNMENT to 1 because not all load instructions
 work with misaligned addresses (ldm, for example).  The only way to handle
 misaligned copies is through the movmisalign API.

Are the movmisalign handled ones reasonably efficient?  That is, more
efficient than memcpy/memmove?  Then we should experiment with

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 227252)
+++ gcc/gimple-fold.c   (working copy)
@@ -708,7 +708,9 @@ gimple_fold_builtin_memory_op (gimple_st
  /* If the destination pointer is not aligned we must be 
able
 to emit an unaligned store.  */
   (dest_align = GET_MODE_ALIGNMENT (TYPE_MODE (type))
- || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), 
dest_align)))
+ || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), 
dest_align)
+ || (optab_handler (movmisalign_optab, TYPE_MODE 
(type))
+ != CODE_FOR_nothing)))
{
  tree srctype = type;
  tree desttype = type;
@@ -720,7 +722,10 @@ gimple_fold_builtin_memory_op (gimple_st
srcmem = tem;
  else if (src_align  GET_MODE_ALIGNMENT (TYPE_MODE 
(type))
SLOW_UNALIGNED_ACCESS (TYPE_MODE (type),
-src_align))
+src_align)
+   (optab_handler (movmisalign_optab,
+ TYPE_MODE (type))
+  == CODE_FOR_nothing))
srcmem = NULL_TREE;
  if (srcmem)
{

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[ramana at gcc dot gnu.org]

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

--- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #3)
 On Thu, 27 Aug 2015, rearnsha at gcc dot gnu.org wrote:
 
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
  
  --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
  (In reply to Richard Biener from comment #1)
   I think this boils down to the fact that memcpy expansion is done too late
   and
   that (with more recent GCC) the inlining done on the GIMPLE level is
   restricted
   to !SLOW_UNALIGNED_ACCESS but arm defines STRICT_ALIGNMENT to 1
   unconditionally.
   
  
  Yep, we have to define STRICT_ALIGNMENT to 1 because not all load 
  instructions
  work with misaligned addresses (ldm, for example).  The only way to handle
  misaligned copies is through the movmisalign API.
 
 Are the movmisalign handled ones reasonably efficient?  That is, more
 efficient than memcpy/memmove?  Then we should experiment with

What do you mean by more efficient here ? they'll end up calling down to the
same unspec block if we implemented them - memcpy / memmove go through the
backend block_move interface.

Will try the patch with a hacked up movmisalign pattern in the backend.

 
 Index: gcc/gimple-fold.c
 ===
 --- gcc/gimple-fold.c   (revision 227252)
 +++ gcc/gimple-fold.c   (working copy)
 @@ -708,7 +708,9 @@ gimple_fold_builtin_memory_op (gimple_st
   /* If the destination pointer is not aligned we must be 
 able
  to emit an unaligned store.  */
(dest_align = GET_MODE_ALIGNMENT (TYPE_MODE (type))
 - || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), 
 dest_align)))
 + || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), 
 dest_align)
 + || (optab_handler (movmisalign_optab, TYPE_MODE 
 (type))
 + != CODE_FOR_nothing)))
 {
   tree srctype = type;
   tree desttype = type;
 @@ -720,7 +722,10 @@ gimple_fold_builtin_memory_op (gimple_st
 srcmem = tem;
   else if (src_align  GET_MODE_ALIGNMENT (TYPE_MODE 
 (type))
 SLOW_UNALIGNED_ACCESS (TYPE_MODE (type),
 -src_align))
 +src_align)
 +   (optab_handler (movmisalign_optab,
 + TYPE_MODE (type))
 +  == CODE_FOR_nothing))
 srcmem = NULL_TREE;
   if (srcmem)
 {

[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-27
 CC||hubicka at gcc dot gnu.org,
   ||y.gribov at samsung dot com
  Component|c++ |ipa
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
  /* Don't inline a function with mismatched sanitization attributes. */
  else if (!sanitize_attrs_match_for_inline_p (caller-decl, callee-decl))
{
  e-inline_failed = CIF_ATTRIBUTE_MISMATCH;
  inlinable = false;

static bool
sanitize_attrs_match_for_inline_p (const_tree caller, const_tree callee)
{
  /* Don't care if sanitizer is disabled */
  if (!(flag_sanitize  SANITIZE_ADDRESS))
return true;

  if (!caller || !callee)
return true;

  return !!lookup_attribute (no_sanitize_address,
  DECL_ATTRIBUTES (caller)) ==
  !!lookup_attribute (no_sanitize_address,
  DECL_ATTRIBUTES (callee));

so it fails on purpose (not sure why though).  And it ignores always-inline.
I wonder if we should, for always-inline functions, inline anyway and output
a warning instead.

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 27 Aug 2015, ramana at gcc dot gnu.org wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
 
 --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
 (In reply to rguent...@suse.de from comment #3)
  On Thu, 27 Aug 2015, rearnsha at gcc dot gnu.org wrote:
  
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
   
   --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
   (In reply to Richard Biener from comment #1)
I think this boils down to the fact that memcpy expansion is done too 
late
and
that (with more recent GCC) the inlining done on the GIMPLE level is
restricted
to !SLOW_UNALIGNED_ACCESS but arm defines STRICT_ALIGNMENT to 1
unconditionally.

   
   Yep, we have to define STRICT_ALIGNMENT to 1 because not all load 
   instructions
   work with misaligned addresses (ldm, for example).  The only way to handle
   misaligned copies is through the movmisalign API.
  
  Are the movmisalign handled ones reasonably efficient?  That is, more
  efficient than memcpy/memmove?  Then we should experiment with
 
 minor nit - missing include of optabs.h - fixing that and adding a
 movmisalignsi pattern in the backend that just generates either an unaligned /
 storesi insn generates the following for me for the above mentioned testcase.
 
 
 read32:
 @ args = 0, pretend = 0, frame = 0
 @ frame_needed = 0, uses_anonymous_args = 0
 @ link register save eliminated.
 ldr r0, [r0]@ unaligned
 bx  lr
 
 
 
 
 I'm on holiday from this evening so don't really want to push something today
 ... 

Sure ;)  When adding the GIMPLE folding I was just careful here as I
don't really have a STRICT_ALIGNMENT machine with movmisalign handling
available.  Thus full testing is appreciated (might turn up some
testcases that need adjustment).  There are more STRICT_ALIGN
guarded cases below in the function, eventually they can be modified
as well (at which point splitting out the alignment check to a separate
function makes sense).

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan ramana at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
(In reply to Richard Earnshaw from comment #2)
 (In reply to Richard Biener from comment #1)
  I think this boils down to the fact that memcpy expansion is done too late
  and
  that (with more recent GCC) the inlining done on the GIMPLE level is
  restricted
  to !SLOW_UNALIGNED_ACCESS but arm defines STRICT_ALIGNMENT to 1
  unconditionally.
  
 
 Yep, we have to define STRICT_ALIGNMENT to 1 because not all load
 instructions work with misaligned addresses (ldm, for example).  The only
 way to handle misaligned copies is through the movmisalign API.

Hmmm, actually that's not completely true - for SImode and HImode objects there
don't appear to be movmisalign interfaces. For things like memcpy this is done
through the memcpy interface where we end up generating copies using
unaligned_loadsi and unaliged_storesi.

We may need to experiment a bit with the movmisalign interface too.


Ramana

[Bug c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |5.3

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[ramana at gcc dot gnu.org]

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

--- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #3)
 On Thu, 27 Aug 2015, rearnsha at gcc dot gnu.org wrote:
 
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
  
  --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
  (In reply to Richard Biener from comment #1)
   I think this boils down to the fact that memcpy expansion is done too late
   and
   that (with more recent GCC) the inlining done on the GIMPLE level is
   restricted
   to !SLOW_UNALIGNED_ACCESS but arm defines STRICT_ALIGNMENT to 1
   unconditionally.
   
  
  Yep, we have to define STRICT_ALIGNMENT to 1 because not all load 
  instructions
  work with misaligned addresses (ldm, for example).  The only way to handle
  misaligned copies is through the movmisalign API.
 
 Are the movmisalign handled ones reasonably efficient?  That is, more
 efficient than memcpy/memmove?  Then we should experiment with

minor nit - missing include of optabs.h - fixing that and adding a
movmisalignsi pattern in the backend that just generates either an unaligned /
storesi insn generates the following for me for the above mentioned testcase.


read32:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r0, [r0]@ unaligned
bx  lr




I'm on holiday from this evening so don't really want to push something today
... 





 
 Index: gcc/gimple-fold.c
 ===
 --- gcc/gimple-fold.c   (revision 227252)
 +++ gcc/gimple-fold.c   (working copy)
 @@ -708,7 +708,9 @@ gimple_fold_builtin_memory_op (gimple_st
   /* If the destination pointer is not aligned we must be 
 able
  to emit an unaligned store.  */
(dest_align = GET_MODE_ALIGNMENT (TYPE_MODE (type))
 - || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), 
 dest_align)))
 + || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), 
 dest_align)
 + || (optab_handler (movmisalign_optab, TYPE_MODE 
 (type))
 + != CODE_FOR_nothing)))
 {
   tree srctype = type;
   tree desttype = type;
 @@ -720,7 +722,10 @@ gimple_fold_builtin_memory_op (gimple_st
 srcmem = tem;
   else if (src_align  GET_MODE_ALIGNMENT (TYPE_MODE 
 (type))
 SLOW_UNALIGNED_ACCESS (TYPE_MODE (type),
 -src_align))
 +src_align)
 +   (optab_handler (movmisalign_optab,
 + TYPE_MODE (type))
 +  == CODE_FOR_nothing))
 srcmem = NULL_TREE;
   if (srcmem)
 {

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[ramana at gcc dot gnu.org]

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

--- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #7)
 On Thu, 27 Aug 2015, ramana at gcc dot gnu.org wrote:
 
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
  
  --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
  (In reply to rguent...@suse.de from comment #3)
   On Thu, 27 Aug 2015, rearnsha at gcc dot gnu.org wrote:
   
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366

--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
 I think this boils down to the fact that memcpy expansion is done too 
 late
 and
 that (with more recent GCC) the inlining done on the GIMPLE level is
 restricted
 to !SLOW_UNALIGNED_ACCESS but arm defines STRICT_ALIGNMENT to 1
 unconditionally.
 

Yep, we have to define STRICT_ALIGNMENT to 1 because not all load 
instructions
work with misaligned addresses (ldm, for example).  The only way to 
handle
misaligned copies is through the movmisalign API.
   
   Are the movmisalign handled ones reasonably efficient?  That is, more
   efficient than memcpy/memmove?  Then we should experiment with
  
  minor nit - missing include of optabs.h - fixing that and adding a
  movmisalignsi pattern in the backend that just generates either an 
  unaligned /
  storesi insn generates the following for me for the above mentioned 
  testcase.
  
  
  read32:
  @ args = 0, pretend = 0, frame = 0
  @ frame_needed = 0, uses_anonymous_args = 0
  @ link register save eliminated.
  ldr r0, [r0]@ unaligned
  bx  lr
  
  
  
  
  I'm on holiday from this evening so don't really want to push something 
  today
  ... 
 
 Sure ;)  When adding the GIMPLE folding I was just careful here as I
 don't really have a STRICT_ALIGNMENT machine with movmisalign handling
 available.  Thus full testing is appreciated (might turn up some
 testcases that need adjustment).  There are more STRICT_ALIGN
 guarded cases below in the function, eventually they can be modified
 as well (at which point splitting out the alignment check to a separate
 function makes sense).

This was the backend hack I was playing with. It needs extension to HImode
values, cleaning up and regression testing and some small amount of
benchmarking to see we're doing the right thing.



diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 288bbb9..eaff494 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -11423,6 +11423,27 @@
   }
 )

+(define_expand movmisalignsi
+  [(match_operand:SI 0 general_operand)
+   (match_operand:SI 1 general_operand)]
+  unaligned_access
+{
+  /* This pattern is not permitted to fail during expansion: if both arguments
+ are non-registers (e.g. memory := constant, which can be created by the
+ auto-vectorizer), force operand 1 into a register.  */
+  if (!s_register_operand (operands[0], SImode)
+   !s_register_operand (operands[1], SImode))
+operands[1] = force_reg (SImode, operands[1]);
+
+  if (MEM_P (operands[1]))
+emit_insn (gen_unaligned_loadsi (operands[0], operands[1]));
+  else
+emit_insn (gen_unaligned_storesi (operands[0], operands[1]));
+
+  DONE;
+})
+
+
 ;; Vector bits common to IWMMXT and Neon
 (include vec-common.md)
 ;; Load the Intel Wireless Multimedia Extension patterns

[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict

[y.gribov at samsung dot com]

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

--- Comment #2 from Yury Gribov y.gribov at samsung dot com ---
(In reply to Richard Biener from comment #1)
 so it fails on purpose (not sure why though).  And it ignores always-inline.
 I wonder if we should, for always-inline functions, inline anyway and output
 a warning instead.

We prohibited this combination during ASan integration to kernel. Both
always_inline and no_sanitize_address are strong requirements for compiler i.e.
dropping any of these in favor of another would have unexpected effects and
hurt usability.

[Bug c++/67370] New: Invalid parameter packs not expanded error in lambda capture

[ldionne.2 at gmail dot com]

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

Bug ID: 67370
   Summary: Invalid parameter packs not expanded error in lambda
capture
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code does not compile with GCC trunk:

template typename ...T
void expand(T const ...);

template typename ...T
void f(T ...t) {
expand([t]{ }...);
}


The error is

[snip]: In function 'void f(T ...)':
[snip]: error: parameter packs not expanded with '...':
 expand([t]{ }...);
 ^
[snip]: note: 't'
[snip]: error: parameter packs not expanded with '...':
 expand([t]{ }...);
  ^


Live example: http://melpon.org/wandbox/permlink/uKHsTOctM4EbNTpi

[Bug c++/67370] Invalid parameter packs not expanded error in lambda capture

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Almost certainly a dup of PR 64488 and PR 47226

[Bug lto/67357] -Wodr warnings from types in anonymous namespace

[rogero at howzatt dot demon.co.uk]

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

--- Comment #3 from Roger Orr rogero at howzatt dot demon.co.uk ---
The following code block also gives an ODR violation with the same versions of
gcc; in this case only a *single* translation unit is involved.

$ cat test.cxx
#include memory

templatetypename T
class D : public T {
using mfn_t = void (D::*)();
std::tuplemfn_t data{D::foo};
public:
void foo() {
std::get0(data);
}
};

namespace {
struct S {};
}

int main() {
DS obj;
}

$ /opt/gcc-5.2.0/bin/g++ -flto -Wodr -std=c++11 test.cxx
test.cxx:5:32: warning: type 'struct mfn_t' violates one definition rule
[-Wodr]
 using mfn_t = void (D::*)();
^
/opt/gcc-5.2.0/include/c++/5.2.0/tuple:764:21: note: a different type is
defined in another translation unit
   typedef _Head type;
 ^
test.cxx:5:32: note: the first difference of corresponding definitions is field
'__pfn'
 using mfn_t = void (D::*)();
^
test.cxx:5:32: note: a field of same name but different type is defined in
another translation unit
lto1: note: type mismatch in parameter 1
test.cxx:4:20: note: type 'struct D' defined in anonymous namespace can not
match type 'struct D'
 class D : public T {
^
test.cxx:4:7: note: the incompatible type defined in anonymous namespace in
another translation unit
 class D : public T {
   ^

(Giving the anonymous namespace a name removes the warnings.)

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
 I think this boils down to the fact that memcpy expansion is done too late
 and
 that (with more recent GCC) the inlining done on the GIMPLE level is
 restricted
 to !SLOW_UNALIGNED_ACCESS but arm defines STRICT_ALIGNMENT to 1
 unconditionally.
 

Yep, we have to define STRICT_ALIGNMENT to 1 because not all load instructions
work with misaligned addresses (ldm, for example).  The only way to handle
misaligned copies is through the movmisalign API.

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-27
 CC||rguenth at gcc dot gnu.org
Version|4.8.2   |6.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
I think this boils down to the fact that memcpy expansion is done too late and
that (with more recent GCC) the inlining done on the GIMPLE level is
restricted
to !SLOW_UNALIGNED_ACCESS but arm defines STRICT_ALIGNMENT to 1
unconditionally.

I guess arm goes through the movmisalign optab for unaligned accesses and the
GIMPLE inlining could be enabled as well if movmisalign is supported.

Note that GCC 4.8 is no longer supported and enhancements will go to GCC 6 at
most.

With current trunk and -O2 -march=armv6 I get for

typedef unsigned int u32;
u32 read32(const void* ptr) { u32 v; __builtin_memcpy(v, ptr, sizeof(v));
return v; }

read32:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r0, [r0]@ unaligned
sub sp, sp, #8
add sp, sp, #8
@ sp needed
bx  lr

so apart from the stack slot not getting removed this has already improved,
but the issue I mention still happens as we expand from

read32 (const void * ptr)
{
  u32 v;
  u32 _4;

  bb 2:
  __builtin_memcpy (v, ptr_2(D), 4);
  _4 = v;
  v ={v} {CLOBBER};
  return _4;

so partially confirmed, for the GIMPLE memory op inlining issue.

[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|r227188 breaks build for|[6 Regression] r227188
   |mingw-w64   |breaks build for mingw-w64

[Bug c++/67368] New: Inlining failed due to no_sanitize_address and always_inline conflict

[wojciech.mula at microgen dot com]

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

Bug ID: 67368
   Summary: Inlining failed due to no_sanitize_address and
always_inline conflict
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wojciech.mula at microgen dot com
  Target Milestone: ---

When compiling program

-- bug.cpp --
#include emmintrin.h

__attribute__((no_sanitize_address))   
 void foo() {
   __m128i z = _mm_setzero_si128();
}
-- eof --

using following command

$ g++ -c -fsanitize=address bug.cpp

GCC reports:

In file included from bug.cpp:1:0:
[...]/x86_64-unknown-linux-gnu/4.9.2/include/emmintrin.h: In function ‘void
foo()’:
[...]/x86_64-unknown-linux-gnu/4.9.2/include/emmintrin.h:749:1: error: inlining
failed in call to always_inline ‘__m128i _mm_setzero_si128()’: function
attribute mismatch
 _mm_setzero_si128 (void)
 ^
bug.cpp:5:36: error: called from here
  __m128i z = _mm_setzero_si128();

Compiler version (built from the sources):

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=[...]/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: [...]/source/gcc-4.9.2/configure --prefix=[...]
--with-local-prefix=[...] --enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.9.2 (GCC)

I've checked the sample program on https://gcc.godbolt.org/ and for versions
5.1.0  5.2.0 there is the same problem. However 4.9.2 from Ubuntu is not
affected.

[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[ubizjak at gmail dot com]

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

Uroš Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #6 from Uroš Bizjak ubizjak at gmail dot com ---
Created attachment 36258
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36258action=edit
Proposed patch

This patch changes expanders of carry-handling builtins to use
addqi3_cconly_overflow and canonicalizes carry hanling insn to what combine can
process:

(define_insn addcarrymode
  [(set (reg:CCC FLAGS_REG)
(compare:CCC
  (plus:SWI48
(plus:SWI48
  (match_operator:SWI48 4 ix86_carry_flag_operator
   [(match_operand 3 flags_reg_operand) (const_int 0)])
  (match_operand:SWI48 1 nonimmediate_operand %0))
(match_operand:SWI48 2 nonimmediate_operand rm))
  (match_dup 1)))
   (set (match_operand:SWI48 0 register_operand =r)
(plus:SWI48 (plus:SWI48 (match_op_dup 4
 [(match_dup 3) (const_int 0)])
(match_dup 1))
(match_dup 2)))]
  ix86_binary_operator_ok (PLUS, MODEmode, operands)
  adc{imodesuffix}\t{%2, %0|%0, %2}
  [(set_attr type alu)
   (set_attr use_carry 1)
   (set_attr pent_pair pu)
   (set_attr mode MODE)])

and

(define_insn subborrowmode
  [(set (reg:CCC FLAGS_REG)
(compare:CCC
  (match_operand:SWI48 1 nonimmediate_operand 0)
  (plus:SWI48
(match_operator:SWI48 4 ix86_carry_flag_operator
 [(match_operand 3 flags_reg_operand) (const_int 0)])
(match_operand:SWI48 2 nonimmediate_operand rm
   (set (match_operand:SWI48 0 register_operand =r)
(minus:SWI48 (minus:SWI48 (match_dup 1)
  (match_op_dup 4
   [(match_dup 3) (const_int 0)]))
 (match_dup 2)))]
  ix86_binary_operator_ok (MINUS, MODEmode, operands)
  sbb{imodesuffix}\t{%2, %0|%0, %2}
  [(set_attr type alu)
   (set_attr use_carry 1)
   (set_attr pent_pair pu)
   (set_attr mode MODE)])

The patch also rewrites expander to fix a bug, where carry-clobbering insns
were emitted inside carry-flag def-use chain.

For the testcase, patched gcc generates:

testcarry_u64:
addq%rdi, %rdx
adcq%rsi, %rcx
movq%rdx, %rax
xorq%rcx, %rax
ret

[Bug c++/67369] New: [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14

[doko at gcc dot gnu.org]

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

Bug ID: 67369
   Summary: [5/6 Regression] ICE (in tsubst_decl, at
cp/pt.c:11302) with -std=c++14
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with the gcc-5-branch r227166, and trunk r227171

$ cat foo.cc 
int main() {
  unsigned const nsz = 0;
  auto repeat_conditional = [](auto) {
auto new_sz = nsz;
  };
  repeat_conditional(1);
}
$ /usr/lib/gcc-snapshot/bin/g++ -std=c++14 -c foo.cc 
foo.cc: In instantiation of 'main()::lambda(auto:1) [with auto:1 = int]':
foo.cc:6:23:   required from here
foo.cc:1:5: internal compiler error: in tsubst_decl, at cp/pt.c:11302
 int main() {
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug libstdc++/67361] std::regex_error::what() should say something about the error_code

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-27
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Yes, that would be even better!

[Bug c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf trippels at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-27
 CC||jason at gcc dot gnu.org,
   ||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Confirmed.

[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[ubizjak at gmail dot com]

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

Uroš Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Target|x86_64-*-*  |x86
 CC|uros at gcc dot gnu.org|
   Target Milestone|--- |5.3

[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h

[bshastry at sec dot t-labs.tu-berlin.de]

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

Bhargava Shastry bshastry at sec dot t-labs.tu-berlin.de changed:

   What|Removed |Added

 CC||bshastry at sec dot 
t-labs.tu-berl
   ||in.de

--- Comment #9 from Bhargava Shastry bshastry at sec dot t-labs.tu-berlin.de 
---
Hi. I just noticed that there are two more instances of the undefined downcast
via static_cast that are not fixed by the said patch.

### Lines borrowed from bits/stl_tree.h [gcc 5.1.0]

883.  iterator
884.  end() _GLIBCXX_NOEXCEPT
885.  { return iterator(static_cast_Link_type(this-_M_impl._M_header));
}
886.
887.  const_iterator
888.  end() const _GLIBCXX_NOEXCEPT
889.  {
890.return const_iterator(static_cast_Const_Link_type
891.  (this-_M_impl._M_header));
892.  }

The undefined casts happen on line 885 and 890--891.

[Bug target/67378] New: PowerPC unrecognizable insn (ICE in in extract_insn, at recog.c:2297)

[anton at samba dot org]

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

Bug ID: 67378
   Summary: PowerPC unrecognizable insn (ICE in in extract_insn,
at recog.c:2297)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
  Target Milestone: ---

Created attachment 36262
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36262action=edit
Testcase

csmith hit another ICE. This testcase is still quite complex even after
reducing it unfortunately.

# gcc -O3 -c testcase.i

testcase4.i: In function 'f3':
testcase4.i:23:1: error: unrecognizable insn:
 }
 ^
(insn 486 484 487 2 (set (mem/c:DI (plus:DI (reg/f:DI 1 1)
(const_int 144 [0x90])) [7 %sfp+144 S8 A64])
(plus:DI (reg:DI 8 8)
(const_int 18 [0x12]))) testcase4.i:19 -1
 (nil))
testcase4.i:23:1: internal compiler error: in extract_insn, at recog.c:2297
0x107894b3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:109
0x10789517 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:117
0x1074cde7 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2297
0x1074ceaf extract_insn_cached(rtx_insn*)
../../gcc/gcc/recog.c:2188
0x104ad837 cleanup_subreg_operands(rtx_insn*)
../../gcc/gcc/final.c:3112
0x107862af reload(rtx_insn*, int)
../../gcc/gcc/reload1.c:1255
0x105fc99b do_reload
../../gcc/gcc/ira.c:5405
0x105fc99b execute
../../gcc/gcc/ira.c:5564