[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
Richard Biener 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 ---
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;
:
__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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 Richard Biener 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
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
__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 c++/67369] New: [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14
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():: [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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67361 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-27 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67369 Markus Trippelsdorf 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 --- Confirmed.
[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
--- Comment #6 from Uroš Bizjak ---
Created attachment 36258
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36258&action=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 "addcarry"
[(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, mode, operands)"
"adc{}\t{%2, %0|%0, %2}"
[(set_attr "type" "alu")
(set_attr "use_carry" "1")
(set_attr "pent_pair" "pu")
(set_attr "mode" "")])
and
(define_insn "subborrow"
[(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, mode, operands)"
"sbb{}\t{%2, %0|%0, %2}"
[(set_attr "type" "alu")
(set_attr "use_carry" "1")
(set_attr "pent_pair" "pu")
(set_attr "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 target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317 Uroš Bizjak changed: What|Removed |Added Target|x86_64-*-* |x86 CC|uros at gcc dot gnu.org| Target Milestone|--- |5.3
[Bug lto/67357] -Wodr warnings from types in anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67357
--- Comment #3 from Roger Orr ---
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
template
class D : public T {
using mfn_t = void (D::*)();
std::tuple data{&D::foo};
public:
void foo() {
std::get<0>(data);
}
};
namespace {
struct S {};
}
int main() {
D 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366 --- Comment #2 from Richard Earnshaw --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
--- Comment #3 from 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 ---
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #4 from Ramana Radhakrishnan --- (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 target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
--- Comment #5 from Ramana Radhakrishnan ---
(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 ---
> > (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 c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67369 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.3
[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
Richard Biener 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 ---
/* 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
--- Comment #6 from Ramana Radhakrishnan ---
(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 ---
> > (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366 --- Comment #7 from 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 --- > (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 --- > > > (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
--- Comment #8 from Ramana Radhakrishnan ---
(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 ---
> > (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 ---
> > > > (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368 --- Comment #2 from Yury Gribov --- (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
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
void expand(T const& ...);
template
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67370 --- Comment #1 from Jonathan Wakely --- Almost certainly a dup of PR 64488 and PR 47226
[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
Bhargava Shastry changed:
What|Removed |Added
CC||bshastry at sec dot
t-labs.tu-berl
||in.de
--- Comment #9 from Bhargava Shastry
---
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 libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Jonathan Wakely --- Yes, there are a few remaining. I changed the code on trunk to avoid all those casts completely.
[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- In fact I also already fixed it on the gcc-5 branch, see r223811. The 5.1.0 sources are not current.
[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 --- Comment #12 from Bhargava Shastry --- 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=markup&pathrev=223811#l685 [2]: https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/libstdc%2B%2B-v3/include/bits/stl_tree.h?view=markup&pathrev=223811#l614 [3]: https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/libstdc%2B%2B-v3/include/bits/stl_tree.h?view=markup&pathrev=223811#l604
[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 --- Comment #13 from Jonathan Wakely --- (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 c++/67371] New: Never executed "throw" in constexpr function fails to compile
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 '' 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 target/67356] PowerPC insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67356 --- Comment #2 from Alan Modra --- Author: amodra Date: Thu Aug 27 13:56:39 2015 New Revision: 227260 URL: https://gcc.gnu.org/viewcvs?rev=227260&root=gcc&view=rev Log: [RS6000] Correct constraints for ior_mask ior_mask always splits to rtl matching rotl3_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 ior_mask. PR target/67356 * config/rs6000/rs6000.md (ior_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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67356 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Alan Modra --- fixed
[Bug c++/67372] New: Functions created via cp/decl2.c:start_objects not properly registered
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 target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366 --- Comment #9 from Richard Earnshaw --- 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 target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366 --- Comment #10 from 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 --- > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366 --- Comment #11 from Ramana Radhakrishnan --- (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 --- > > 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. movmisalign has stricter rules compared to mov so we have to handle some of these carefully. The logic in here is essentially from neon.md : movmisalign, 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 tree-optimization/67283] GCC regression over inlining of returned structures
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=227265&root=gcc&view=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 lto/66752] spec2000 255.vortex performance compiled with GCC is ~20% lower than with CLANG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66752 --- Comment #17 from Jeffrey A. Law --- 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 bootstrap/67373] New: Can't compile gcc snapshot for avr target with mingw
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=36259&action=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
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 tree-optimization/67283] GCC regression over inlining of returned structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67283 --- Comment #9 from Xavier Roche --- Created attachment 36260 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36260&action=edit Second test case (might be useful for unit testing)
[Bug tree-optimization/67283] GCC regression over inlining of returned structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67283 --- Comment #10 from Xavier Roche --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67283 --- Comment #11 from Xavier Roche --- 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Thu Aug 27 17:07:35 2015 New Revision: 227268 URL: https://gcc.gnu.org/viewcvs?rev=227268&root=gcc&view=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 middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Fixed.
[Bug libstdc++/67374] std::cbegin can't call valarray range access functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67374 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-27 Ever confirmed|0 |1
[Bug libstdc++/67374] New: std::cbegin can't call valarray range access functions
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
#include
int main()
{
std::valarray v;
std::cbegin(v);
}
The problem is that the begin overloads in are not declared before
the non-member functions in so can't be called from
there.
This works:
namespace std {
template
struct valarray;
template
inline _Tp*
begin(valarray<_Tp>& __va);
/**
* @brief Return an iterator pointing to the first element of
* the const valarray.
* @param __va valarray.
*/
template
inline const _Tp*
begin(const valarray<_Tp>& __va);
}
#include
#include
int main()
{
std::valarray v;
std::cbegin(v);
}
[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
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=227271&root=gcc&view=rev Log: PR target/67317 * config/i386/i386.md (*add3_cc): Remove insn pattern. (addqi3_cc): Ditto. (UNSPEC_ADD_CARRY): Remove. (addqi3_cconly_overflow): New expander. (*add3_doubleword): Split to add3_cconly_overflow. Adjust for changed add3_carry. (*neg2_doubleword): Adjust for changed add3_carry. (*sub3_doubleword): Adjust for changed sub3_carry. (3_carry): Remove expander. (*3_carry): Split insn pattern to add3_carry and sub3_carry. (plusminus_carry_mnemonic): Remove code attribute. (add3_carry): Canonicalize insn pattern. (*addsi3_carry_zext): Ditto. (sub3_carry): Ditto. (*subsi3_carry_zext): Ditto. (adcx3): Remove insn pattern. (addcarry): New insn pattern. (subborrow): Ditto. * config/i386/i386.c (ix86_expand_strlensi_unroll_1): Use gen_addqi3_cconly_overflow instead of gen_addqi3_cc. (ix86_expand_builtin) : 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67374 Jonathan Wakely changed: What|Removed |Added Version|4.9.4 |5.2.1 Target Milestone|--- |5.3 Known to fail||5.2.0, 6.0
[Bug libstdc++/67374] std::cbegin can't call valarray range access functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67374 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Thu Aug 27 19:05:19 2015 New Revision: 227274 URL: https://gcc.gnu.org/viewcvs?rev=227274&root=gcc&view=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 c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164
--- Comment #4 from Louis Dionne ---
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
T declval();
template
struct expand;
template
struct closure {
closure();
template ()))...
>>
closure(Yn ...);
template
closure(closure);
};
int main() {
closure> empty{};
closure> 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 ‘
template
closure::closure(closure) [with Yn = ]’:
test/worksheet.cpp:1573:31: required by substitution of ‘
template
closure::closure(Yn ...) [with Yn = closure >;
= ]’
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
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021 --- Comment #22 from Bill Schmidt --- (In reply to Richard Biener from comment #21) > (In reply to Bill Schmidt from comment #20) .. > > 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
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
#include
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 c++/56958] Spurious set but not used variable warning in empty pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment #4 from Louis Dionne ---
The following code triggers the same warning on GCC trunk:
--
struct Object { int method(int) const { return 0; } };
template void expand(T&&...);
template struct index_sequence { };
template
struct TemplateStruct {
static constexpr Object get_object() { return {}; }
template
static void f(index_sequence) {
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<
>::f(index_sequence) [with int ...i = {};
= {}]’:
[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
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=, > nbyte=) 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/67351] Missed optimisation on 64-bit field compared to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351 Uroš Bizjak 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 --- Adding CC.
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #9 from Chen Gang --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021 --- Comment #23 from Bill Schmidt --- Created attachment 36261 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36261&action=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 c++/67371] Never executed "throw" in constexpr function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 --- Comment #1 from Louis Dionne --- 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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67377 --- Comment #1 from Jürgen Reuter --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66135
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment #2 from Louis Dionne ---
Another test case:
template
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
void f(T) {
[](auto x) -> decltype(x.foo()) { };
}
template void f(int);
[Bug target/67378] New: PowerPC unrecognizable insn (ICE in in extract_insn, at recog.c:2297)
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=36262&action=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
[Bug libstdc++/67362] std::regex("((.)", std::regex_constants::basic) throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362 --- Comment #1 from Tim Shen --- Author: timshen Date: Fri Aug 28 02:35:21 2015 New Revision: 227289 URL: https://gcc.gnu.org/viewcvs?rev=227289&root=gcc&view=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 libstdc++/67362] std::regex("((.)", std::regex_constants::basic) throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362 --- Comment #2 from Tim Shen --- Author: timshen Date: Fri Aug 28 03:03:55 2015 New Revision: 227290 URL: https://gcc.gnu.org/viewcvs?rev=227290&root=gcc&view=rev Log: Backport from mainline 2015-08-28 Tim Shen 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 libstdc++/67362] std::regex("((.)", std::regex_constants::basic) throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362 --- Comment #3 from Tim Shen --- Author: timshen Date: Fri Aug 28 03:39:53 2015 New Revision: 227291 URL: https://gcc.gnu.org/viewcvs?rev=227291&root=gcc&view=rev Log: Backport from mainline 2015-08-28 Tim Shen 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362 Tim Shen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Tim Shen --- Fixed.
[Bug tree-optimization/53852] [4.9/5/6 Regression] -ftree-loop-linear: large compile time / memory usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852 Joost VandeVondele 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 --- since today on trunk this also triggers for options such as -floop-block, which didn't trigger this before.
[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164 --- Comment #5 from Markus Trippelsdorf --- (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 c++/67371] Never executed "throw" in constexpr function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 Markus Trippelsdorf changed: What|Removed |Added CC||rhalbersma at gmail dot com --- Comment #2 from Markus Trippelsdorf --- *** Bug 66026 has been marked as a duplicate of this bug. ***
[Bug c++/66026] C++14] throw-expression is not a valid constant-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66026 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371
Markus Trippelsdorf 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 ---
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 c/67377] gcc 6.0 fails to compile on Darwin 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67377 --- Comment #2 from Jürgen Reuter --- Ok, this was obviously fixed in r227282 2 hours after I checked out and tried to compile ;)
