[Bug target/80468] New: [7 Regression] ICE on invalid AVX512 code with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80468
Bug ID: 80468
Summary: [7 Regression] ICE on invalid AVX512 code with -m32
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at redhat dot com
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Starting from r246965, we ICE on:
$ cat ice.i
void
a ()
{
__attribute__ ((__vector_size__ (4 * sizeof (unsigned __int128 b;
0 != b;
}
$ gcc ice.i -m32
ice.i: In function ‘a’:
ice.i:4:61: error: ‘__int128’ is not supported on this target
__attribute__ ((__vector_size__ (4 * sizeof (unsigned __int128 b;
^~~~
ice.i:5:3: internal compiler error: Segmentation fault
0 != b;
^
0xc0f12f crash_signal
../../gcc/toplev.c:337
0xededb1 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3193
0xededb1 make_vector_type
../../gcc/tree.c:10065
0xedf6ec build_opaque_vector_type(tree_node*, int)
../../gcc/tree.c:11034
0x6aa4bf build_binary_op(unsigned int, tree_code, tree_node*, tree_node*, int)
../../gcc/c/c-typeck.c:11461
0x6ac7f6 parser_build_binary_op(unsigned int, tree_code, c_expr, c_expr)
../../gcc/c/c-typeck.c:3637
0x6c9dca c_parser_binary_expression
../../gcc/c/c-parser.c:6830
0x6ca265 c_parser_conditional_expression
../../gcc/c/c-parser.c:6470
0x6ca9c0 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6387
0x6cac42 c_parser_expression
../../gcc/c/c-parser.c:8588
0x6cd4c9 c_parser_expression_conv
../../gcc/c/c-parser.c:8621
0x6e0f79 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5405
0x6e2d47 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:4919
0x6e349e c_parser_compound_statement
../../gcc/c/c-parser.c:4752
0x6de8dc c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2125
0x6e68ab c_parser_external_declaration
../../gcc/c/c-parser.c:1469
0x6e7309 c_parser_translation_unit
../../gcc/c/c-parser.c:1349
0x6e7309 c_parse_file()
../../gcc/c/c-parser.c:18176
0x745b22 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107
[Bug c++/80469] New: Undefined symbol for abstract class impl with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80469
Bug ID: 80469
Summary: Undefined symbol for abstract class impl with
-fvisibility=hidden
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: theubik at mail dot ru
Target Milestone: ---
Created attachment 41231
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41231&action=edit
example
When building with gcc 5.4 two libs (used option -fvisibility=hidden), first
has undefined symbol. With gcc 4.9 (4.9.3) not reproduced.
>> # uname -a
>> Linux vbox-ubuntu16 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC
>> 2017 x86_64 x86_64 x86_64 GNU/Linux
>> #gcc --version
>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Example:
// main.cpp
#include "subimpl.h"
class XXX
{
IA* p;
public:
~XXX()
{
p->a();
}
};
XXX xxx;
// subimpl.h
#pragma once
struct IA
{
virtual void a() = 0;
};
class A : public IA
{
public:
void dothis();
void a()
{
dothis();
}
};
// subimpl.cpp
#include "subimpl.h"
void A::dothis() {}
>> # ldd -r libexperiments.so | grep undefined
>> undefined symbol: _ZN1A6dothisEv (./libexperiments.so)
[Bug target/80468] [7 Regression] ICE on invalid AVX512 code with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80468 Jakub Jelinek changed: What|Removed |Added Keywords|ice-on-invalid-code |error-recovery Priority|P3 |P4 CC||jakub at gcc dot gnu.org Target Milestone|--- |7.0
[Bug c++/80469] Undefined symbol for abstract class impl with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80469 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- You need to provide the definition of dothis() somewhere. Not a bug.
[Bug c++/80469] Undefined symbol for abstract class impl with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80469 --- Comment #2 from Markus Trippelsdorf --- In other words, don't use -fvisibility=hidden when you build subimpl.cpp.
[Bug c++/80469] Undefined symbol for abstract class impl with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80469
--- Comment #3 from Ubikovich ---
>> You need to provide the definition of dothis() somewhere.
There is the definition:
// subimpl.cpp
#include "subimpl.h"
void A::dothis() {}
[Bug c++/80469] Undefined symbol for abstract class impl with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80469
--- Comment #4 from Markus Trippelsdorf ---
(In reply to Ubikovich from comment #3)
> >> You need to provide the definition of dothis() somewhere.
>
> There is the definition:
>
> // subimpl.cpp
> #include "subimpl.h"
> void A::dothis() {}
Yeah, put "__attribute__ ((visibility("default")))" above it and you're done.
[Bug debug/80453] [7 Regression] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-20 CC||aoliva at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Jakub Jelinek --- I think the bug is that sccvn uses DECL_UIDs in hash computations, so in some cases we end up with different hashcodes, different collisions and if unlucky enough, e.g. vn_phi_lookup can find a different value based on that. If I instrument: @@ -3120,6 +3120,9 @@ vn_phi_insert (gimple *phi, tree result) vp1->result = result; vp1->hashcode = vn_phi_compute_hash (vp1); +fprintf (stderr, "vn_phi_insert %08x %d %d\n", vp1->hashcode, TREE_CODE (result) == SSA_NAME ? SSA_NAME_VERSION (result) : -1); +extern void debug_gimple_stmt (gimple *); +debug_gimple_stmt (phi); slot = current_info->phis->find_slot_with_hash (vp1, vp1->hashcode, INSERT); /* Because we iterate over phi operations more than once, it's I see: vn_phi_insert 127d0253 12 146 .MEM_12 = PHI <.MEM_13(D)(2), .MEM_26(3)> -vn_phi_insert e38159ce 29 146 -_29 = PHI <&D.834312(2), &D.834311(3)> -vn_phi_insert e38159ce 29 146 -_29 = PHI <&D.834312(2), &D.834311(3)> +vn_phi_insert 851182e7 29 146 +_29 = PHI <&D.834716(2), &D.834715(3)> +vn_phi_insert 851182e7 29 146 +_29 = PHI <&D.834716(2), &D.834715(3)> vn_phi_insert 77edc47d 9 146 .MEM_9 = PHI <.MEM_13(4), .MEM_14(3)> While -g vs. -g0 guarantees the bbs and SSA_NAME_VERSIONs etc. are always the same, we don't have any such a guarantee for DECL_UIDs, there is just a guarantee that the corresponding DECL_UIDs in between -g and -g0 compare the same, but they can have different gaps in between them. Not really sure what is the way out of this (nor does this really look like a recent regression, it is just something really hard to reproduce, one has to be unlucky enough). Perhaps in inchash::add_expr optionally use a DECL_UID -> uid hash map if the caller asks for it, which would map DECL_UIDs (only if seen in non-debug stmts) to say visit #s. Or try to guarantee identical DECL_UIDs between -g and -g0 (we'd need to have some flag for decl creation in "debug only" contexts and use say negative uids, dunno if we'd need to be prepared to bump those "debug only" uids into normal uids if they are looked up in non-"debug only" contexts later on.
[Bug debug/80453] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 Markus Trippelsdorf changed: What|Removed |Added Summary|[7 Regression] another |another compare-debug |compare-debug failure |failure --- Comment #8 from Markus Trippelsdorf --- I've seen the same issue with gcc-6, so it is not a trunk regression.
[Bug inline-asm/80470] New: Can't compile wait4 implementation on i586 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80470
Bug ID: 80470
Summary: Can't compile wait4 implementation on i586 target
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Host: i586-linux-gnu
Target: i586-linux-gnu
Following comes from gperftools, where I can't compile with GCC 7 attach
test-case. It's implementation of wait4 syscall and it used to work with GCC6.
It's quite tricky to do the set-up, I had to use a qemu i686 machine with GCC
configured with:
../configure --prefix=/home/marxin/bin/gcc --disable-bootstrap
--disable-libsanitizer --enable-languages=c,c++ --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=i586-suse-linux
--host=i586-suse-linux
Problematic command line is:
$ ./xg++ -B. asm.ii -c -fPIC -fomit-frame-pointer -O
asm.ii: In function ‘void h()’:
asm.ii:15:44: error: ‘asm’ operand has impossible constraints
: "esp", "memory");
^
Where the problematic insn looks as follows:
1449 if (asm_noperands (PATTERN (insn)) >= 0)
(gdb) p debug_rtx(insn)
(insn 20 69 66 4 (parallel [
(set (reg:SI 105 [orig:96 __res ] [96])
(asm_operands/v:SI ("push %%ebx
movl %2,%%ebx
int $0x80
pop %%ebx
") ("=a") 0 [
(reg:SI 105 [orig:96 __res ] [96])
(reg:SI 102 [orig:89 _8 ] [89])
(reg/f:SI 108 [orig:91 j$d ] [91])
(reg:SI 106 [orig:88 j$e ] [88])
(reg:SI 107)
]
[
(asm_input:SI ("0") asm.ii:15)
(asm_input:SI ("ri") asm.ii:15)
(asm_input:SI ("c") asm.ii:15)
(asm_input:SI ("d") asm.ii:15)
(asm_input:SI ("S") asm.ii:15)
]
[] asm.ii:15))
(clobber (mem:BLK (scratch) [0 A8]))
(clobber (reg/f:SI 7 sp))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) "asm.ii":15 -1
(expr_list:REG_DEAD (reg/f:SI 108 [orig:91 j$d ] [91])
(expr_list:REG_DEAD (reg:SI 106 [orig:88 j$e ] [88])
(expr_list:REG_DEAD (reg:SI 107)
(expr_list:REG_DEAD (reg:SI 102 [orig:89 _8 ] [89])
(expr_list:REG_UNUSED (reg:CCFP 18 fpsr)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
$1 = void
I also tried to add registers 'c', 'd', 'S' to clobber argument, but it's still
not possible.
Thanks,
Martin
[Bug inline-asm/80470] Can't compile wait4 implementation on i586 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80470 --- Comment #1 from Martin Liška --- Created attachment 41232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41232&action=edit test-case
[Bug inline-asm/80470] Can't compile wait4 implementation on i586 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80470 --- Comment #2 from Uroš Bizjak --- You should not clobber esp.
[Bug inline-asm/80470] Can't compile wait4 implementation on i586 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80470 --- Comment #3 from Martin Liška --- (In reply to Uroš Bizjak from comment #2) > You should not clobber esp. Works for me, thanks. Can you please explain me why it makes problem? Is it because not enough registers or?
[Bug inline-asm/80470] Can't compile wait4 implementation on i586 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80470
--- Comment #4 from Uroš Bizjak ---
(In reply to Martin Liška from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > You should not clobber esp.
>
> Works for me, thanks. Can you please explain me why it makes problem? Is it
> because not enough registers or?
Register allocator can't omit frame pointer (%ebp) to stack pointer (%esp) when
the latter is clobbered in the asm.
BTW, gcc7 allows you to use %ebx directly through "b" constraint, so:
__asm__ __volatile__("int $0x80"
: "=a"(__res)
: "0"(114), "b"((long)(p)), "c"((long)(s)),
"d"((long)(o)), "S"((long)(r))
: "memory");
[Bug inline-asm/80470] Can't compile wait4 implementation on i586 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80470 --- Comment #5 from Jakub Jelinek --- I think we have other PRs that ICE or do bad things if "esp"/"rsp" is clobbered in inline-asm, e.g. PR80367 recently.
[Bug inline-asm/80470] Can't compile wait4 implementation on i586 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80470 --- Comment #6 from Martin Liška --- Thanks both. Better error than a strange behavior. Well, would it worth for somehow more explicitly document that clobbering stack pointer is a wrong think/invalid?
[Bug target/66334] cleanup block fails to initialize EBX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66334 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Uroš Bizjak --- (In reply to Andrew Pinski from comment #14) > Fixed for 6.1.
[Bug debug/80453] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 --- Comment #9 from Richard Biener --- So the issue is that vn_phi_eq depends on cond_stmts_equal_p which may change if we value-number the controlling condition after the PHI itself which can trivially happen with SCC based value-numbering as controlling conditions are not part of the SCC. Index: gcc/tree-ssa-sccvn.c === --- gcc/tree-ssa-sccvn.c(revision 246964) +++ gcc/tree-ssa-sccvn.c(working copy) @@ -2941,10 +2941,12 @@ cond_stmts_equal_p (gcond *cond1, gcond else return false; +#if 0 lhs1 = vn_valueize (lhs1); rhs1 = vn_valueize (rhs1); lhs2 = vn_valueize (lhs2); rhs2 = vn_valueize (rhs2); +#endif return ((expressions_equal_p (lhs1, lhs2) && expressions_equal_p (rhs1, rhs2)) || (commutative_tree_code (code1) would fix this (and pessimize PHI VN of course).
[Bug middle-end/80423] [7 Regression] GC related -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80423 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Thu Apr 20 09:18:02 2017 New Revision: 247014 URL: https://gcc.gnu.org/viewcvs?rev=247014&root=gcc&view=rev Log: PR middle-end/80423 * tree.h (build_array_type): Add typeless_storage default argument. * tree.c (type_cache_hasher::equal): Also compare TYPE_TYPELESS_STORAGE flag for ARRAY_TYPEs. (build_array_type): Add typeless_storage argument, set TYPE_TYPELESS_STORAGE to it, if shared also hash it, and pass to recursive call. (build_nonshared_array_type): Adjust build_array_type_1 caller. (build_array_type): Likewise. Add typeless_storage argument. c-family/ * c-common.c (complete_array_type): Preserve TYPE_TYPELESS_STORAGE. cp/ * tree.c (build_cplus_array_type): Call build_array_type with the intended TYPE_TYPELESS_STORAGE flag value, instead of calling build_array_type and modifying later TYPE_TYPELESS_STORAGE on the shared type. testsuite/ * g++.dg/other/pr80423.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/pr80423.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h
[Bug libstdc++/69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769 --- Comment #6 from Jonathan Wakely --- (In reply to Wolfgang Roehrl from comment #0) > The compiler accepts this programm despite of performing an arithmetic > operation on pointer to a function. Arithmetic on (non-atomic) function pointers is supported by GCC: https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html So this is consistent with the built-in types.
[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56950 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Uroš Bizjak --- Works OK with gcc-7.
[Bug tree-optimization/54077] Bytemark FP EMULATION 9%-15% slower than with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #20 from Uroš Bizjak --- Assuming fixed due to PR55286 fix, please retest with newer gcc version if not.
[Bug middle-end/80423] [7 Regression] GC related -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80423 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/79534] [7 Regression] tree-ifcombine aarch64 performance regression with trunk@245151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534 --- Comment #10 from James Greenhalgh --- The most striking improvement was in libquantum, for which we saw a 15% performance improvement on Cortex-A72 (3% on cortex-A57) directly attributable to basic block ordering after this patch. Otherwise, I don't have a direct before/after comparison for just Honza's patch across a wider set of benchmarks, but our nightly runs show general improvements in benchmarks from Spec which are sensitive to block reordering after the day of the patch. I don't see any large regressions in this time.
[Bug target/53877] __lzcnt_u16/__lzcnt_u32/__lzcnt_u64 aren't implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53877 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Uroš Bizjak --- (In reply to Yukhin Kirill from comment #3) > Done.
[Bug inline-asm/80470] Can't compile wait4 implementation on i586 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80470 --- Comment #7 from Martin Liška --- Created attachment 41233 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41233&action=edit Another test-case There's another test-case which is sensible to -O, which causes an inlining to happen and after that a constraint can't be satisfied.
[Bug c++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-20 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The new-expression comes from where we check if the pair members are constructible. I'm not sure whether we'd want to suppress this warning in a SFINAE context, or if the library should use a placement new-expression there instead.
[Bug c++/51222] [C++11][SFINAE] Unevaluated combined delete new expression completely broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51222
--- Comment #8 from Jonathan Wakely ---
We should revisit the library traits now this is fixed:
// Implementation for non-reference types. To meet the proper
// variable definition semantics, we also need to test for
// is_destructible in this case.
// This form should be simplified by a single expression:
// ::delete ::new _Tp(declval<_Arg>()), see c++/51222.
struct __do_is_direct_constructible_impl
{
template()))>
static true_type __test(int);
[Bug debug/80453] [6/7 Regression] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|7.0 |6.4 Summary|another compare-debug |[6/7 Regression] another |failure |compare-debug failure
[Bug debug/80453] [6/7 Regression] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 --- Comment #10 from Richard Biener --- Created attachment 41234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41234&action=edit patch Patch I am testing that is less pessimizing (we need to remember valueized controlling condition args).
[Bug target/71607] [5/6/7 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607 --- Comment #12 from Prakhar Bahuguna --- (In reply to Christophe Monat from comment #10) > (In reply to Ramana Radhakrishnan from comment #9) > > Hello Ramana, > > Is there a plan to have this patch delivered upstream at some point in the > near future ? > > Best regards, > --C Hi Christophe, The patch has now been posted to the mailing list: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00872.html Regards, Prakhar
[Bug rtl-optimization/30455] i386 generates unnecessary TEST instructions for arithmetic ops on memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30455 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Uroš Bizjak --- gcc-7 generates for the original testcase: add_zf: addl%esi, (%rdi) movl%ecx, %eax cmove %edx, %eax ret So, fixed.
[Bug tree-optimization/80426] [6 Regression] wrong manipulation of range based on INT_MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80426 Richard Biener changed: What|Removed |Added Priority|P1 |P2 Target Milestone|7.0 |6.4
[Bug middle-end/80421] [5 Regression] Case dispatch is scrambled in switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80421 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/80429] -fcompare-debug failure on ppc64le with LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80429 Richard Biener changed: What|Removed |Added Known to work||7.0.1 Known to fail|7.0 | --- Comment #3 from Richard Biener --- Fixed on trunk (sofar)?
[Bug rtl-optimization/80429] -fcompare-debug failure on ppc64le with LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80429 --- Comment #4 from Markus Trippelsdorf --- (In reply to Richard Biener from comment #3) > Fixed on trunk (sofar)? Yes.
[Bug rtl-optimization/80429] -fcompare-debug failure on ppc64le with LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80429 --- Comment #5 from Segher Boessenkool --- Yes sorry, fixed on trunk. Backports pending.
[Bug tree-optimization/80430] Vectorizer undervalues cost of alias checking for versioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80430 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-20 Blocks||53947 Target Milestone|8.0 |--- Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. One trivial improvement would be to use scalar_stmt (there's no vector code emitted). Another issue is that we combine the runtime cost model check with the alias checks rather than emitting a separate gimple-cond for this. Plus for a loop nest we should eventually version the whole nest (even if only vectorizing the innermost loop) in case the versioning conditions are invariant in the outer loop. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/80450] -std=c99 breaks -frounding-math on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80450 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #1 from Richard Biener --- I think unless you use long double you can't rely on -O2 -frounding-math behavior. -std=c99 enables -fexcess-precision=standard. I think the unconditional zero is correct here.
[Bug other/71250] -Wmissing-field-initializers documentation is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71250
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #7 from Alexander Monakov ---
Fixed (the checked in text is different from my suggestion in comment #2,
because in the documentation there are further examples, and the C++ treatment
of '{ }' was already explained).
[Bug libstdc++/80451] [6/7 Regression] return implicit type conversion to std::experimental::optional does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80451 Richard Biener changed: What|Removed |Added Target Milestone|7.0 |6.4
[Bug other/71250] -Wmissing-field-initializers documentation is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71250
--- Comment #6 from Alexander Monakov ---
Author: amonakov
Date: Thu Apr 20 10:23:38 2017
New Revision: 247018
URL: https://gcc.gnu.org/viewcvs?rev=247018&root=gcc&view=rev
Log:
doc: mention handling of {0} in -Wmissing-field-initializers (PR 71250)
PR other/71250
* doc/invoke.texi (-Wmissing-field-initializers): Mention that warning
is suppressed for '{ 0 }' in C.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
[Bug c++/80439] __attribute__((target("xxx"))) not applied to lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80439 --- Comment #1 from Richard Biener --- Hmm, I think it would make sense if lambdas (and nested functions) "inherit" both target and optimize attributes from their parents.
[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 --- Comment #3 from Richard Biener --- How is the C++ abstract machine defined in this case? I don't think you can constexpr evaluate any volatile load -- but of course in this case 'this' shouldn't be considered volatile in that sense?
[Bug tree-optimization/80457] vectorizable_condition does not update the vectorizer cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80457 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|7.0 |---
[Bug target/80450] -std=c99 breaks -frounding-math on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80450 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Joseph S. Myers --- This is just the same bug as any other constant truncation wrongly ignoring the rounding mode (as if 0x1p-2000L were being converted - the semantics with standard excess precision being that 0x1p-2000L gets computed then converted to double). *** This bug has been marked as a duplicate of bug 57245 ***
[Bug target/71991] Inconsistency for __attribute__ ((__always_inline__)) among LTO and non-LTO compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71991 --- Comment #3 from Martin Liška --- Ok, the first test-case started to fail w/ LTO from r217659. Honza, can you please take a look and provide hint what to do?
[Bug tree-optimization/57245] Floating-point constant truncation ignores -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57245 Joseph S. Myers changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #2 from Joseph S. Myers --- *** Bug 80450 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/80463] [5/6/7 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 Known to work||4.5.0 Target Milestone|7.0 |5.5
[Bug target/80464] [7 regression] S/390: ICE failed to split vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80464 Richard Biener changed: What|Removed |Added Priority|P4 |P2
[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 --- Comment #4 from Jonathan Wakely --- Yeah, it doesn't need to evaluate 'this' in that declaration, it's calling a static member function.
[Bug tree-optimization/57245] Floating-point constant truncation ignores -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57245
--- Comment #3 from nsz at gcc dot gnu.org ---
note that this may cause the omission of underflow, overflow and inexact
exceptions too (so in principle it's an invalid transformation even
without -frounding-math but with -ftrapping-math ):
float x,y;
void f(void)
{
x = 0x1p-1000; // truncated to 0
y = 0x1p1000; // truncated to inf
}
[Bug c++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- Created attachment 41235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41235&action=edit avoid over-aligned new in is_constructible Daniel, does this seem like a reasonable simplification of __is_direct_constructible? The idea is to declare an operator new for internal use in unevaluated contexts, and then use that for the new-expression that tests direct-constructibility. We can also combine it with the delete check, because PR 51222 is fixed.
[Bug libstdc++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390 Jonathan Wakely changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com Component|c++ |libstdc++ --- Comment #3 from Jonathan Wakely --- Daniel, please see above.
[Bug libstdc++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390 --- Comment #4 from Daniel Krügler --- (In reply to Jonathan Wakely from comment #3) > Daniel, please see above. Sorry for the late response. I would like to shortly double-check, can you await a definitive response until tomorrow?
[Bug libstdc++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390 --- Comment #5 from Jonathan Wakely --- Of course. Your response is not late, I just couldn't CC you and attach the patch at the same time, so mentioned you in a follow-up :-)
[Bug c/80468] [7/8 Regression] ICE on invalid AVX512 code with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80468 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-04-20 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 41236 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41236&action=edit gcc7-pr80468.patch Untested fix.
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820 Jonathan Wakely changed: What|Removed |Added Resolution|WONTFIX |FIXED Target Milestone|4.4.5 |5.0 Known to fail|| --- Comment #24 from Jonathan Wakely --- This started working again with 5.1.0 ap.cc: In function ‘int main()’: ap.cc:7:9: warning: ‘template class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] std::auto_ptr p( (S*) 1234 ); ^ In file included from /home/jwakely/gcc/5.1.0/include/c++/5.1.0/memory:81:0, from ap.cc:1: /home/jwakely/gcc/5.1.0/include/c++/5.1.0/bits/unique_ptr.h:49:28: note: declared here template class auto_ptr; ^
[Bug c++/80469] Undefined symbol for abstract class impl with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80469
--- Comment #5 from Ubikovich ---
(In reply to Markus Trippelsdorf from comment #4)
> (In reply to Ubikovich from comment #3)
> > >> You need to provide the definition of dothis() somewhere.
> >
> > There is the definition:
> >
> > // subimpl.cpp
> > #include "subimpl.h"
> > void A::dothis() {}
>
> Yeah, put "__attribute__ ((visibility("default")))" above it and you're done.
Why if move implement of A::a() to subimpl.cpp it not reproduced?
[Bug c++/80472] New: cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
Bug ID: 80472
Summary: cannot use push/pop with #pragma GCC diagnostic
warning "-Wsystem-headers"
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 58876, 69769, 70692
Target Milestone: ---
Given the following header:
#pragma GCC system_header
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wsystem-headers"
// want warnings here despite being in a system header
#pragma GCC diagnostic pop
// But don't want warnings here
int missing_return() { }
A file including it will warn with -Wreturn-type (or -Wall):
In file included from dep.cc:1:0:
dep.h: In function ‘int missing_return()’:
dep.h:8:24: warning: no return statement in function returning non-void
[-Wreturn-type]
int missing_return() { }
^
The warning should be disabled again by the "pop", but -Wsystem-headers stays
active once enabled.
This makes it very difficult for libstdc++ to selectively enable important
warnings, e.g. Bug 58876
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
[Bug 58876] No non-virtual-dtor warning in std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769
[Bug 69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692
[Bug 70692] No warning when std::function binds a reference to
a temporary
[Bug c++/80469] Undefined symbol for abstract class impl with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80469
--- Comment #6 from Markus Trippelsdorf ---
(In reply to Ubikovich from comment #5)
> (In reply to Markus Trippelsdorf from comment #4)
> > (In reply to Ubikovich from comment #3)
> > > >> You need to provide the definition of dothis() somewhere.
> > >
> > > There is the definition:
> > >
> > > // subimpl.cpp
> > > #include "subimpl.h"
> > > void A::dothis() {}
> >
> > Yeah, put "__attribute__ ((visibility("default")))" above it and you're
> > done.
>
> Why if move implement of A::a() to subimpl.cpp it not reproduced?
Because then the compiler sees the definition of A::dothis in the same TU.
And it doesn't generate a undefined symbol for main.cpp.
But this is not the right place to discuss this.
Read https://www.akkadia.org/drepper/dsohowto.pdf if you need more info.
[Bug c++/80452] [DR 1579] incorrect value category deduced for return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80452 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-20 Ever confirmed|0 |1
[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed :(.
[Bug c++/80380] misleading behavior with designated initializers for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80380 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-20 Ever confirmed|0 |1
[Bug c++/69967] #pragma GCC diagnostic ignored being ignored for -Wunused-variable in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69967 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Closing.
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #13 from Jonathan Wakely --- Author: redi Date: Thu Apr 20 13:04:28 2017 New Revision: 247021 URL: https://gcc.gnu.org/viewcvs?rev=247021&root=gcc&view=rev Log: PR79862 check macro for type aliases that depend on PR libstdc++/79862 * include/std/atomic [!_GLIBCXX_USE_C99_STDINT_TR1] (atomic_int8_t) (atomic_uint8_t, atomic_int16_t, atomic_uint16_t, atomic_int32_t, (atomic_uint32_t, atomic_int64_t, atomic_uint64_t) (atomic_int_least8_t, atomic_uint_least8_t, atomic_int_least16_t) (atomic_uint_least16_t, atomic_int_least32_t, atomic_uint_least32_t) (atomic_int_least64_t, atomic_uint_least64_t, atomic_int_fast8_t) (atomic_uint_fast8_t, atomic_int_fast16_t, atomic_uint_fast16_t) (atomic_int_fast32_t, atomic_uint_fast32_t, atomic_int_fast64_t) (atomic_uint_fast64_t, atomic_intmax_t, atomic_uintmax_t): Don't define. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/atomic
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #14 from Jonathan Wakely --- Fix for gcc 8. I'm not going to backport this, as systems without are weird and broken.
[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- The test() call is represented as *(volatile struct A *) this, A::test () and the *this dereference in that case is what triggers the error (well, this itself). This is created by: 8827 /* In an expression of the form `a->f()' where `f' turns 8828 out to be a static member function, `a' is 8829 none-the-less evaluated. */ 8830 if (TREE_CODE (TREE_TYPE (fn)) != METHOD_TYPE 8831 && !is_dummy_object (instance) 8832 && TREE_SIDE_EFFECTS (instance)) 8833call = build2 (COMPOUND_EXPR, TREE_TYPE (call), 8834 instance, call); So shall we have some exception of *this if it is volatile and still ignore it?
[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 --- Comment #6 from Jakub Jelinek --- Oops, sorry Marek, seems you've said all that already, ignore my comment... :(.
[Bug libstdc++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390
--- Comment #6 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #2)
> Created attachment 41235 [details]
> avoid over-aligned new in is_constructible
>
> [..]. We can also combine it
> with the delete check, because PR 51222 is fixed.
It seems that PR 51222 didn't cover private destructors. Using this test class
struct PS
{
PS(int);
private:
~PS() = default;
};
The attempt to evaluate the revised __is_direct_constructible_impl
produces a compiler error (so not SFINAE-friendly), but the current
implementation (using std::is_destructible) works nicely.
Do you recommend to reopen 51222 or should I open a separate bug? I'm inclined
to create a new one at the moment.
Another question I have is the following: What is you main motivation to
introduce the idiom
struct __uneval_new_t;
inline void* operator new(std::size_t, std::__uneval_new_t*);
decltype(::delete ::new((__uneval_new_t*)0) _Tp(std::declval<_Arg>()))
compared to the seemingly simpler alternative
decltype(::delete ::new _Tp(std::declval<_Arg>()))
?
[Bug libstdc++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390 --- Comment #7 from Jonathan Wakely --- (In reply to Daniel Krügler from comment #6) > Do you recommend to reopen 51222 or should I open a separate bug? I'm > inclined to create a new one at the moment. Agreed, let's have a new bug for that. > Another question I have is the following: What is you main motivation to > introduce the idiom > > struct __uneval_new_t; > inline void* operator new(std::size_t, std::__uneval_new_t*); > decltype(::delete ::new((__uneval_new_t*)0) _Tp(std::declval<_Arg>())) > > compared to the seemingly simpler alternative > > decltype(::delete ::new _Tp(std::declval<_Arg>())) > > ? It's to solve the problem reported in this PR: for over-aligned types we get several lines of output telling us that aligned-new isn't supported without -faligned-new. That isn't useful in this context, because we're not actually trying to allocate it, just test the validity of the expression. It's certainly not useful to the end user, because the new-expression is an implementation detail deep inside libstdc++. By introducing the new overload we avoid that problem, but still test whether the type can be constructed. I could have simply used ::new((void*)0) to use the predefined placement new, but that isn't declared in , so I would have had to add a declaration for it (and that isn't supposed to be declared by ).
[Bug libstdc++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390 --- Comment #8 from Jonathan Wakely --- Maybe we should just ask Jason to suppress the notes in a SFINAE context.
[Bug c++/80473] New: [7/8 Regression] notes about over-aligned new not suppressed in system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80473
Bug ID: 80473
Summary: [7/8 Regression] notes about over-aligned new not
suppressed in system-headers
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct alignas(64) A { int i; };
constexpr bool b = std::is_constructible::value;
With -Wall this produces unhelpful output referring to an unevaluated
new-expression inside libstdc++ internals:
In file included from a2.cc:1:0:
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits: In substitution of
‘template struct
std::__is_direct_constructible_impl<_Tp, _Arg, decltype (::new _Tp)> [with _Tp
= A; _Arg = A]’:
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:143:12: required from
‘struct std::__and_,
std::__is_direct_constructible_impl >’
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:995:12: required from
‘struct std::__is_direct_constructible_new_safe’
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:1077:12: required from
‘struct std::__is_direct_constructible_new’
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:1085:12: required from
‘struct std::__is_direct_constructible’
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:1125:12: required from
‘struct std::__is_constructible_impl’
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:1136:12: required from
‘struct std::is_constructible’
a2.cc:3:47: required from here
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:990:16: note: uses ‘void*
operator new(long unsigned int)’, which does not have an alignment parameter
decltype(::new _Tp(std::declval<_Arg>()))>
^~~
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:990:16: note: use
‘-faligned-new’ to enable C++17 over-aligned new support
The actual -Waligned-new warning is suppressed due to being in a system header,
but the note is not.
It's debatable whether warning about the new-expression as an unevaluated
operand is useful anyway, but the note should not be printed if the warning is
suppressed.
[Bug libstdc++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390 --- Comment #9 from Daniel Krügler --- (In reply to Jonathan Wakely from comment #8) > Maybe we should just ask Jason to suppress the notes in a SFINAE context. Yes, that sounds like a preferred direction to me.
[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80473 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-04-20 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This is easy to fix, I have a patch.
[Bug debug/80453] [6/7/8 Regression] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 --- Comment #11 from Richard Biener --- Author: rguenth Date: Thu Apr 20 14:23:10 2017 New Revision: 247024 URL: https://gcc.gnu.org/viewcvs?rev=247024&root=gcc&view=rev Log: 2017-04-20 Richard Biener PR tree-optimization/80453 * tree-ssa-sccvn.h (struct vn_phi_s): Add cclhs and ccrhs members. * tree-ssa-sccvn.c (cond_stmts_equal_p): Use recorded lhs and rhs from the conditions. (vn_phi_eq): Pass them down. (vn_phi_lookup): Record them. (vn_phi_insert): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-ssa-sccvn.h
[Bug debug/80453] [6/7 Regression] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[6/7/8 Regression] another |[6/7 Regression] another |compare-debug failure |compare-debug failure --- Comment #12 from Richard Biener --- Fixed on trunk sofar.
[Bug target/57796] AVX2 gather vectorization: code bloat and reduction of performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796 --- Comment #11 from Richard Biener --- Author: rguenth Date: Thu Apr 20 14:26:26 2017 New Revision: 247026 URL: https://gcc.gnu.org/viewcvs?rev=247026&root=gcc&view=rev Log: 2017-04-20 Richard Biener PR tree-optimization/57796 * tree-vect-stmts.c (vect_model_store_cost): Cost scatters as N scalar stores. (vect_model_load_cost): Cost gathers as N scalar loads. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80473 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.2
[Bug rtl-optimization/80474] New: ipa-cp wrongly adding LO(symbol) twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474
Bug ID: 80474
Summary: ipa-cp wrongly adding LO(symbol) twice
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.smets at nokia dot com
Target Milestone: ---
On MIPS, O32
GCC 6.3.1 (does not happen on GCC5, but there it's not similarly optimized by
ipa-cp)
I wasn't yet successful at producing a minimized testcase.
A function is called and one of the arguments is a function pointer.
On mips the symbol is loaded in two steps, the HI and the LO part.
The LO part is an increment and is happening twice, resulting in a bogus
pointer being passed.
409 INITEVENT (PP_MASK_QX, T01, OUTRESEG_DRAM_DATA_ECC_UNCORRECTABLE_0,
0,1,
"OUTRESEG_DRAM_DATA_ECC_UNCORRE CTABLE_0", ERROR_EVENT,
&decay_ext_dram_unc_err, myFunce);
0x04431644 <+11384>: beqzt4,0x4431730
0x04431648 <+11388>: addiu s1,s1,-9260
t4 is zero, so branches to 0x4431730
# BLOCK 530 freq:156 seq:526
# PRED: 543 [69.5%]
$L599:
#(jump_insn 4608 4607 4691 (set (pc)
#(if_then_else (eq (reg:SI 12 $12 [orig:1564 _4488 ] [1564])
#(const_int 0 [0]))
#(label_ref 4678)
#(pc))) myfile.c:409 472 {*branch_equalitysi}
# (int_list:REG_BR_PROB 5000 (nil))
# -> 4678)
beq $12,$0,$L592 # 4608 *branch_equalitysi [length = 4]
#(insn 4691 4608 27788 (set (reg/f:SI 17 $17 [6100])
#(lo_sum:SI (reg/f:SI 17 $17 [6102])
#(symbol_ref:SI ("myFunce") [flags 0x3] ))) 300 {*lowsi}
# (expr_list:REG_EQUAL (symbol_ref:SI ("myFunce") [flags 0x3]
)
#(nil)))
addiu $17,$17,%lo(myFunce)# 4691 *lowsi [length = 4]
s1 is now 0x442dbd4 , which is myFunce()
77370x04431730 <+11620>: bnezt2,0x4439a0c
77380x04431734 <+11624>: addiu s1,s1,-9260
t2 is 0x2000, so branches to 0x4439a0c and changes s1 from 0x442dbd4 (correct)
to 0x442b7a8 (incorrect)
# BLOCK 545 freq:78 seq:541
# PRED: 530 [50.0%]
$L592:
#(jump_insn 4680 4679 15195 (set (pc)
#(if_then_else (ne (reg:SI 10 $10 [orig:456 prephitmp_915 ] [456])
#(const_int 0 [0]))
#(label_ref 15192)
#(pc))) myfile.c:409 472 {*branch_equalitysi}
# (int_list:REG_BR_PROB 7002 (nil))
# -> 15192)
bne $10,$0,$L601 # 4680 *branch_equalitysi [length = 4]
#(insn/s 15195 4680 4681 (set (reg/f:SI 17 $17 [6100])
#(lo_sum:SI (reg/f:SI 17 $17 [6102])
#(symbol_ref:SI ("myFunce") [flags 0x3] ))) 300 {*lowsi}
# (expr_list:REG_EQUAL (symbol_ref:SI ("myFunce") [flags 0x3]
)
#(nil)))
addiu $17,$17,%lo(myFunce)# 15195*lowsi [length = 4]
[Bug target/71617] rs6000.c:8483:32: warning: comparison is always true due to limited range of data type [-Wtype-limits]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71617 --- Comment #1 from Segher Boessenkool --- This does not seem to warn with trunk anymore.
[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80473
--- Comment #2 from Jonathan Wakely ---
This doesn't even depend on system headers, the following prints 18 lines of
notes and location info (but no warnings) when -w is used:
template T&& declval();
template
struct is_constructible { enum { value = 0 }; };
template
struct is_constructible()), void())>
{ enum { value = 1 }; };
struct alignas(64) A { int i; };
constexpr bool b = is_constructible::value;
a3.cc: In substitution of ‘template struct
is_constructible [with T = A; U = A]’:
a3.cc:12:42: required from here
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
struct is_constructible()), void())>
^
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
a3.cc: In instantiation of ‘struct is_constructible’:
a3.cc:12:42: required from here
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
[Bug tree-optimization/80457] vectorizable_condition does not update the vectorizer cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80457 --- Comment #1 from Bill Schmidt --- Patch here: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00808.html This is being held for GCC 8.
[Bug libstdc++/68397] std::tr1::expint fails in __expint_En_cont_frac for some long double arguments due to low __max_iter value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68397 --- Comment #3 from emsr at gcc dot gnu.org --- Author: emsr Date: Thu Apr 20 15:41:59 2017 New Revision: 247027 URL: https://gcc.gnu.org/viewcvs?rev=247027&root=gcc&view=rev Log: 2017-04-20 Edward Smith-Rowland <3dw...@verizon.net> PR libstdc++/68397 std::tr1::expint fails ... long double arguments. * include/tr1/exp_integral.tcc: Increase iteration limits. * testsuite/tr1/5_numerical_facilities/special_functions/15_expint/ pr68397.cc: New test. * testsuite/special_functions/14_expint/pr68397.cc: New test. Added: trunk/libstdc++-v3/testsuite/special_functions/14_expint/pr68397.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/15_expint/pr68397.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1/exp_integral.tcc
[Bug target/78090] [x86_64]: GCC allows integer register for inter unit conversion under -mtune-ctrl=^inter_unit_conversions .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78090 Uroš Bizjak changed: What|Removed |Added Keywords|ra | Status|NEW |ASSIGNED Component|rtl-optimization|target Version|unknown |7.0 Target Milestone|--- |8.0 --- Comment #3 from Uroš Bizjak --- I have a patch in testing.
[Bug c++/79078] Warnings from deprecated attribute are too noisy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79078
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #8 from Marek Polacek ---
One thing we should do is to
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -12643,7 +12643,7 @@ grokparms (tree parmlist, tree *parms)
if (deprecated_state != DEPRECATED_SUPPRESS)
{
tree deptype = type_is_deprecated (type);
- if (deptype)
+ if (deptype && !TYPE_BEING_DEFINED (deptype))
warn_deprecated_use (deptype, NULL_TREE);
}
i.e. don't warn if the deprecated type is being defined. For the out of class
definition like
void D::f(const D&) { }
it'd be nice if we could somehow walk the qualifying scopes and if DEPTYPE
here:
12643 if (deprecated_state != DEPRECATED_SUPPRESS)
12644 {
12645 tree deptype = type_is_deprecated (type);
12646 if (deptype && !TYPE_BEING_DEFINED (deptype))
12647 warn_deprecated_use (deptype, NULL_TREE);
12648 }
is the same as one of the scopes, don't warn.
[Bug c++/80475] New: Unevaluated combined delete new expression doesn't handle access error in class template SFINAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80475
Bug ID: 80475
Summary: Unevaluated combined delete new expression doesn't
handle access error in class template SFINAE
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
The following code, compiled with gcc 7.0.1 20170419 (experimental) using the
flags
-Wall -Wextra -std=c++11 -pedantic
or - alternatively -
-Wall -Wextra -std=c++1z -pedantic
//---
struct true_type
{
static const bool value = true;
};
struct false_type
{
static const bool value = false;
};
template
T&& declval();
template
struct is_direct_constructible_impl : false_type
{ };
template
struct is_direct_constructible_impl()))>
: true_type
{ };
struct S
{
S(int);
};
struct DCS
{
DCS(int) = delete;
};
struct PCS
{
private:
PCS(int);
};
struct DDS
{
DDS(int);
~DDS() = delete;
};
struct PDS
{
PDS(int);
private:
~PDS() = default;
};
int main()
{
static_assert(is_direct_constructible_impl::value, "Ouch");
static_assert(!is_direct_constructible_impl::value, "Ouch");
static_assert(!is_direct_constructible_impl::value, "Ouch");
static_assert(!is_direct_constructible_impl::value, "Ouch");
static_assert(!is_direct_constructible_impl::value, "Ouch");
}
//---
is rejected with the following diagnostics:
prog.cc: In instantiation of 'struct is_direct_constructible_impl':
prog.cc:57:56: required from here
prog.cc:20:25: error: 'PCS::PCS(int)' is private within this context
decltype(::delete ::new T(declval()))>
^~~
prog.cc:37:3: note: declared private here
PCS(int);
^~~
prog.cc:20:25: error: 'PCS::PCS(int)' is private within this context
decltype(::delete ::new T(declval()))>
^~~
prog.cc:37:3: note: declared private here
PCS(int);
^~~
prog.cc: In function 'int main()':
prog.cc:57:3: error: static assertion failed: Ouch
static_assert(!is_direct_constructible_impl::value, "Ouch");
^
prog.cc:57:18: error: 'PCS::PCS(int)' is private within this context
static_assert(!is_direct_constructible_impl::value, "Ouch");
^~
prog.cc:37:3: note: declared private here
PCS(int);
^~~
prog.cc: In instantiation of 'struct is_direct_constructible_impl':
prog.cc:59:56: required from here
prog.cc:22:1: error: 'PDS::~PDS()' is private within this context
{ };
^
prog.cc:50:3: note: declared private here
~PDS() = default;
^
prog.cc:22:1: error: 'PDS::~PDS()' is private within this context
{ };
^
prog.cc:50:3: note: declared private here
~PDS() = default;
^
prog.cc:59:3: error: static assertion failed: Ouch
static_assert(!is_direct_constructible_impl::value, "Ouch");
^
prog.cc:59:18: error: 'PDS::~PDS()' is private within this context
static_assert(!is_direct_constructible_impl::value, "Ouch");
^~
prog.cc:50:3: note: declared private here
~PDS() = default;
^
This code example is somewhat different from PR 51222 because it uses "class
template SFINAE" and is maybe related to PR 61806.
This example occurred while discussing a possible alternative implementation of
is_constructible, see PR 80390.
[Bug libstdc++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390 --- Comment #10 from Daniel Krügler --- (In reply to Jonathan Wakely from comment #7) > (In reply to Daniel Krügler from comment #6) > > Do you recommend to reopen 51222 or should I open a separate bug? I'm > > inclined to create a new one at the moment. > > Agreed, let's have a new bug for that. I have just created DR 80475.
[Bug c++/61806] [C++11] Expression sfinae w/o access gives hard error in partial template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61806 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2014-12-14 00:00:00 |2017-4-20 --- Comment #2 from Jonathan Wakely --- EDG accepts it too.
[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80473 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Thu Apr 20 18:02:05 2017 New Revision: 247033 URL: https://gcc.gnu.org/viewcvs?rev=247033&root=gcc&view=rev Log: PR c++/80473 allow suppressing notes about over-aligned new gcc/cp: PR c++/80473 * init.c (build_new_1): Suppress notes about over-aligned new when the warning is suppressed. gcc/testsuite: PR c++/80473 * g++.dg/diagnostic/pr80473.C: New test. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr80473.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80473 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Thu Apr 20 18:36:27 2017 New Revision: 247035 URL: https://gcc.gnu.org/viewcvs?rev=247035&root=gcc&view=rev Log: PR c++/80473 allow suppressing notes about over-aligned new Backport from mainline r247033 gcc/cp: PR c++/80473 * init.c (build_new_1): Suppress notes about over-aligned new when the warning is suppressed. gcc/testsuite: PR c++/80473 * g++.dg/diagnostic/pr80473.C: New test. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/diagnostic/pr80473.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/init.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80473 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed for gcc 7
[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80473 Jonathan Wakely changed: What|Removed |Added CC||m...@sven-woop.de --- Comment #6 from Jonathan Wakely --- *** Bug 80390 has been marked as a duplicate of this bug. ***
[Bug libstdc++/80390] std::pair of aligned type gives bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Jonathan Wakely --- This has been fixed by PR 80473 (I probably should have just changed the component for this bug rather than create another one). We can revisit simplifying the traits once Daniel's new bug is fixed, but for now there's nothing more to be done. *** This bug has been marked as a duplicate of bug 80473 ***
[Bug target/78090] [x86_64]: GCC allows integer register for inter unit conversion under -mtune-ctrl=^inter_unit_conversions .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78090 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Thu Apr 20 19:04:36 2017 New Revision: 247036 URL: https://gcc.gnu.org/viewcvs?rev=247036&root=gcc&view=rev Log: PR target/78090 * config/i386/constraints.md (Yc): New register constraint. * config/i386/i386.md (*float2_mixed): Use Yc constraint for alternative 2 of operand 0. Remove preferred_for_speed attribute. testsuite/ChangeLog: PR target/78090 * gcc.target/i386/conversion-2.c: Remove obsolete test. Removed: trunk/gcc/testsuite/gcc.target/i386/conversion-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/constraints.md trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/54924] Warn for std::string constructor with wrong size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54924
--- Comment #6 from Martin Sebor ---
As a heads up, with the patch for bug 79234 applied and with -Wsystem-headers
explicitly specified GCC issues the warnings below (the -Warray-bounds is
printed even without the patch). Unfortunately, with the default
-Wno-system-headers, warnings from std::string and the rest of libstdc++
headers are suppressed.
$ cat t.C && /build/gcc-79234/gcc/xg++ -B /build/gcc-79234/gcc -nostdinc++ -I
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I /build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include -I
/src/gcc/79234/libstdc++-v3/libsupc++ -I
/src/gcc/79234/libstdc++-v3/include/backward -I
/src/gcc/79234/libstdc++-v3/testsuite/util -L
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -O2 -S -Wall
-Wsystem-headers t.C
#include
std::string s ("abc", 5);
In file included from
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:66:0,
from
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:39,
from
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/string:40,
from t.C:1:
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_iterator_base_funcs.h:
In function ‘(static initializers for t.C)’:
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_iterator_base_funcs.h:104:21:
warning: array subscript is above array bounds [-Warray-bounds]
return __last - __first;
~~~^
In file included from
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/string:40:0,
from t.C:1:
In static member function ‘static std::char_traits::char_type*
std::char_traits::copy(std::char_traits::char_type*, const
char_type*, std::size_t)’,
inlined from ‘static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy(_CharT*, const _CharT*, std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::size_type) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’ at
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:324:21,
inlined from ‘void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_construct(_InIterator, _InIterator, std::forward_iterator_tag)
[with _FwdIterator = const char*; _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’,
inlined from ‘void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_construct(_InIterator, _InIterator) [with _InIterator = const
char*; _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:220:23,
inlined from ‘std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(const _CharT*, std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’ at
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:486:21,
inlined from ‘void __static_initialization_and_destruction_0(int, int)’ at
t.C:3:24,
inlined from ‘(static initializers for t.C)’ at t.C:3:25:
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:292:66:
warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’
reading 5 bytes from a region of size 4 [-Wstringop-overflow=]
return static_cast(__builtin_memcpy(__s1, __s2, __n));
^
[Bug target/78090] [x86_64]: GCC allows integer register for inter unit conversion under -mtune-ctrl=^inter_unit_conversions .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78090 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Uroš Bizjak --- Fixed.
[Bug tree-optimization/79534] [7/8 Regression] tree-ifcombine aarch64 performance regression with trunk@245151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534 --- Comment #11 from Brian Rzycki --- HI James, if you don't see any major regressions and some good uplifts I understand if this case is considered marginal. From my perspective I think it's best to close this ticket and move on to more pressing issues. Thank you for analyzing this.
[Bug libstdc++/80251] Is the is_aggregate meta function missing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80251 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Author: ville Date: Mon Apr 3 15:57:06 2017 New Revision: 246651 URL: https://gcc.gnu.org/viewcvs?rev=246651&root=gcc&view=rev Log: Implement std::is_aggregate. * include/std/type_traits (is_aggregate, is_aggregate_v): New. * testsuite/20_util/is_aggregate/requirements/explicit_instantiation.cc: New. * testsuite/20_util/is_aggregate/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_aggregate/value.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/20_util/is_aggregate/ trunk/libstdc++-v3/testsuite/20_util/is_aggregate/requirements/ trunk/libstdc++-v3/testsuite/20_util/is_aggregate/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/is_aggregate/requirements/typedefs.cc trunk/libstdc++-v3/testsuite/20_util/is_aggregate/value.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits
[Bug rtl-optimization/80425] Extra inter-unit register move with zero-extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80425
--- Comment #2 from Vladimir Makarov ---
We have the following fragment:
8: r96:DI=zero_extend(r93:SI)
REG_DEAD r93:SI
13: r91:V8DI#0=r95:V16SI>>r96:DI
REG_DEAD r96:DI
REG_DEAD r95:V16SI
IRA allocates general regs to r96 and r93. And it means insn 8
alternative (0) r (1) rmWz {*zero_extendsidi2} as requiring no any
reload.
So why does IRA choose general regs for r96 instead of SSE ones. For insn 8 we
have the following alternatives:
"=...r ,...,?*Ym,..."
"... rmWz,...,r ,..."
Alternative '?*Ym, r' discourages usage of SSE regs as Y has *
(exluded from pseudo class consideration). It is also discouraged in
LRA as it has ?
So I don't know how to fix it in IRA or in LRA. I am pretty sure the
old RA and reload would have had the same problem.
Probably the issue should be fixed in machine dependent code. But the fix
might create more problems.
