[Bug c++/81721] precompiled header : internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81721 --- Comment #9 from Andrew Pinski --- Author: pinskia Date: Mon May 20 06:59:06 2019 New Revision: 271395 URL: https://gcc.gnu.org/viewcvs?rev=271395&root=gcc&view=rev Log: [PATCH] Fix PR 81721: ICE with PCH and Pragma warning and C++ operator libcpp/ChangeLog: 2019-05-19 Andrew Pinski PR pch/81721 * lex.c (cpp_token_val_index ): If tok->flags has NAMED_OP set, then return CPP_TOKEN_FLD_NODE. gcc/testsuite/ChangeLog: 2019-05-19 Andrew Pinski PR pch/81721 * g++.dg/pch/operator-1.C: New testcase. * g++.dg/pch/operator-1.Hs: New file. Added: trunk/gcc/testsuite/g++.dg/pch/operator-1.C trunk/gcc/testsuite/g++.dg/pch/operator-1.Hs Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/lex.c
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #7 from Alan Modra ---
> The compiler should not require the loader to do this.
Nope. The compiler *does* require a linker to this. eg. compile this:
#include
void __attribute__ ((noclone, noinline))
print (const char *str)
{
puts (str);
}
int
main ()
{
print ("Hello");
return 0;
}
The call to "print" must be adjusted to go to the local entry point.
If you aren't using a final link stage such as when building kernel modules,
then the module loader needs to do the same as the linker.
[Bug c++/81721] precompiled header : internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81721 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #10 from Andrew Pinski --- Fixed.
[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90501
--- Comment #13 from rguenther at suse dot de ---
On Thu, 16 May 2019, ibuclaw at gdcproject dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90501
>
> --- Comment #11 from Iain Buclaw ---
> (In reply to Jakub Jelinek from comment #8)
> > So the first question would be why D passes the return value as
> > DECL_BY_REFERENCE if it doesn't have TREE_ADDRESSABLE type.
>
> Looking at the places where DECL_BY_REFERENCE is set, this mismatch could
> happen when the result should be returned using NRVO.
>
> To memory, using a mixture of DECL_BY_REFERENCE and CALL_EXPR_RETURN_SLOT_OPT
> gives a desired behaviour of eliding a copy.
>
> Two things come to mind as alternatives:
>
> 1. Currently for NRVO, the DECL_RESULT is explicitly set as not addressable.
>
> TREE_TYPE (resdecl) = build_reference_type (TREE_TYPE (resdecl));
> DECL_BY_REFERENCE (resdecl) = 1;
> TREE_ADDRESSABLE (resdecl) = 0;
>
> Is it allowed for the decl to be both DECL_BY_REFERENCE and TREE_ADDRESSABLE
> at
> the same time? Or will that just confuse things further.
I think that's independent - iff DECL_BY_REFERENCE then resdecl
is the pointer to the decl, so whether the pointer has its address
taken isn't known here yet.
> TREE_TYPE (resdecl) = build_reference_type (TREE_TYPE (resdecl));
> DECL_BY_REFERENCE (resdecl) = 1;
> - TREE_ADDRESSABLE (resdecl) = 0;
> + if (TREE_ADDRESSABLE (TREE_TYPE (resdecl))
> + TREE_ADDRESSABLE (resdecl) = 0;
>
>
> 2. Redo handling of NRVO in the D front-end, to enforce a specific semantic
> for
> trivial types that we want to elide a copy for.
>
> i.e: Given,
> ---
> S foo()
> {
> S result;
> result.a = 3;
> return result;
> }
>
> void test()
> {
> S s = foo();
> }
> ---
>
> Generate this explicitly as:
> ---
> S* foo(S* hidden)
> {
> S result;
> result.a = 3;
> *hidden = result;
> return hidden;
> }
>
> void test()
> {
> S tmp;
> S s = *foo(&tmp);
> }
> ---
>
> Obviously, that change would be a bit more involved on my side.
I don't think this would be FE friendly design of the middle-end.
Thus my question would be why we do have the special-casing
of TREE_ADDRESSABLE (TREE_TYPE (..)) on DECL_BY_REFERENCE decls.
That is, why's
Index: gcc/gimple-walk.c
===
--- gcc/gimple-walk.c (revision 271394)
+++ gcc/gimple-walk.c (working copy)
@@ -829,8 +829,7 @@ walk_stmt_load_store_addr_ops (gimple *s
gimple_call_chain (call_stmt), data);
if (visit_addr
&& gimple_call_return_slot_opt_p (call_stmt)
- && gimple_call_lhs (call_stmt) != NULL_TREE
- && TREE_ADDRESSABLE (TREE_TYPE (gimple_call_lhs (call_stmt
+ && gimple_call_lhs (call_stmt) != NULL_TREE)
ret |= visit_addr (stmt, gimple_call_lhs (call_stmt),
gimple_call_lhs (call_stmt), data);
}
not correct? Do we really force a new temporary to be used?
We'd need to be consistent here for inlining as well then.
[Bug middle-end/90518] ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #8 from Alan Modra --- Oh, and .LTHUNK0 is a function symbol with a local entry offset..
[Bug middle-end/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 Richard Biener changed: What|Removed |Added Keywords||build, needs-reduction CC||law at gcc dot gnu.org, ||marxin at gcc dot gnu.org Target Milestone|--- |9.2 Summary|[9,10 Regression] Invalid |[9/10 Regression] Invalid |SUBREG insn generated by|SUBREG insn generated by |reload |reload --- Comment #6 from Richard Biener --- Note the rev. in question can only have made a previously latent issue exposed. It's also not clear to me why this isn't a target issue given there's not enough information on who introduces "bad" RTL? Hope Jeff might be able to help and Martin with reduction.
[Bug middle-end/90518] ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug middle-end/90518] ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon May 20 07:18:10 2019 New Revision: 271396 URL: https://gcc.gnu.org/viewcvs?rev=271396&root=gcc&view=rev Log: 2019-05-20 Richard Biener PR testsuite/90518 * gcc.dg/gimplefe-40.c: Restrict to targets with appropriate vector support. * gcc.dg/gimplefe-41.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/gimplefe-40.c trunk/gcc/testsuite/gcc.dg/gimplefe-41.c
[Bug testsuite/90517] [10 regression] test case gcc.dg/cdce1.c fails (unresolved) starting with r271281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90517 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-20 Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed.
[Bug target/90522] unrecognizable insn (V8SF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90522 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-05-20 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- For me as well. Given we see V8SFmode inputs to -march= are important so please provide the output of -v appended to the compile command line.
[Bug c++/90534] [7/8 Regression] ICE in consteval in GCCs 8.3, 8.2, 8.1, 7.3, 7.2 and 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90534 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Depends on||85569 Target Milestone|--- |7.5 Summary|ICE in consteval in GCCs|[7/8 Regression] ICE in |8.3, 8.2, 8.1, 7.3, 7.2 and |consteval in GCCs 8.3, 8.2, |7.1 |8.1, 7.3, 7.2 and 7.1 --- Comment #2 from Richard Biener --- Eventually a dup then. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85569 [Bug 85569] [8/9/10 Regression] is_invocable(F, decltype(objs)...) fails with "not supported by dump_expr#" unless via indirection
[Bug fortran/90536] Use of -fno-range-check creates warnings or errors when assigning to a byte variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536 --- Comment #9 from Thomas Koenig --- Hi Steve, what I meant is that Program main Integer(kind=1) :: n n = 1 End should not warn with -fno-range-check -Wall, and it does.
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 --- Comment #13 from JunMa --- (In reply to Christophe Lyon from comment #12) > This new test fails on arm: > FAIL: gcc.dg/cdce3.c scan-tree-dump cdce "cdce3.c:9: [^\n\r]* function call > is shrink-wrapped into error conditions." I don't have arm environment. Would you please attach the dump file of cdce pass?
[Bug middle-end/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #7 from Martin Liška --- (In reply to Richard Biener from comment #6) > Note the rev. in question can only have made a previously latent issue > exposed. > > It's also not clear to me why this isn't a target issue given there's not > enough information on who introduces "bad" RTL? Hope Jeff might be able to > help and Martin with reduction. Sure, if Jeff can prepare a sanitity patch that will expose the latent issue, then I'm able to bisect that.
[Bug middle-end/90263] Calls to mempcpy should use memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263 --- Comment #21 from Martin Liška --- Author: marxin Date: Mon May 20 07:55:00 2019 New Revision: 271400 URL: https://gcc.gnu.org/viewcvs?rev=271400&root=gcc&view=rev Log: Come up with hook libc_has_fast_function (PR middle-end/90263). 2019-05-20 Martin Liska PR middle-end/90263 * builtins.c (expand_builtin_memory_copy_args): When having a target with fast mempcpy implementation do now use memcpy. * config/i386/i386.c (ix86_libc_has_fast_function): New. (TARGET_LIBC_HAS_FAST_FUNCTION): Likewise. * doc/tm.texi: Likewise. * doc/tm.texi.in: Likewise. * target.def: * expr.c (emit_block_move_hints): Add 2 new arguments. * expr.h (emit_block_move_hints): Bail out when libcall to memcpy would be used. 2019-05-20 Martin Liska PR middle-end/90263 * gcc.c-torture/compile/pr90263.c: New test. * lib/target-supports.exp: Add check_effective_target_glibc. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr90263.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/config/i386/i386.c trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/expr.c trunk/gcc/expr.h trunk/gcc/target.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug middle-end/90263] Calls to mempcpy should use memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Martin Liška --- Implemented.
[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77513 --- Comment #9 from Jonathan Wakely --- (In reply to Ville Voutilainen from comment #7) > "The macro NULL is an implementation-defined null pointer constant.", says > the C++ standard draft. So it does, maybe I was misremembering something from an older C++0x draft. Either way, 0 is still a valid definition of NULL, and I suspect that defining NULL as nullptr would break a lot of code (albeit bad code that is misusing NULL).
[Bug c/57201] --save-temps shows correct warning about macro in system-header (Wsystem-header)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201
--- Comment #15 from Jonathan Wakely ---
PR 60100 seems to be the opposite case, where a warning disappears when
-save-temps is used. Related, but maybe not a dup.
Anyway, here's another example where -save-temps (or preprocessing and
compiling separately) makes a warning disappear, from
https://gcc.gnu.org/ml/gcc-help/2019-05/msg00073.html
#include
int main()
{
return NULL;
}
g++ -Wconversion-null w.cc
w.cc: In function ‘int main()’:
w.cc:4:8: warning: converting to non-pointer type ‘int’ from NULL
[-Wconversion-null]
return NULL;
^~~~
g++ -Wconversion-null w.cc -save-temps
[no warnings]
g++ -Wconversion-null w.cc -save-temps -Wsystem-headers
w.cc: In function ‘int main()’:
w.cc:4:7: warning: converting to non-pointer type ‘int’ from NULL
[-Wconversion-null]
return NULL;
^~
g++ -E w.cc -o w.ii && g++ -Wconversion-null w.ii
[no warnings]
g++ -E w.cc -o w.ii && g++ -Wconversion-null w.ii -Wsystem-headers
w.cc: In function ‘int main()’:
w.cc:4:7: warning: converting to non-pointer type ‘int’ from NULL
[-Wconversion-null]
return NULL;
^~
So by default we warn, but when using -save-temps (or preprocessing and
compiling separately) the warning is suppressed because GCC thinks it's from a
system header.
Our diagnostics related to macros in system headers are so broken.
[Bug c++/90532] is_constructible_v and is_default_constructible_v should agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-20 CC||ville at gcc dot gnu.org Component|libstdc++ |c++ Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This is also a compiler bug. The only one of the four traits to give the right answer is the one implemented purely in the library. The other three use the __is_constructible or __is_trivially_constructible built-ins, which are wrong for this case. std::is_default_constructible should probably be using the built-in too, even though that would make it wrong (but consistently so, and it would be right after the built-in gets fixed).
[Bug middle-end/89889] worse code compared to clang with alloca()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89889 --- Comment #4 from Richard Biener --- The code we have for promoting __BUILTIN_ALLOCA_WITH_ALIGN should be probably extended to also promote __BUILTIN_ALLOCA (or commented as to why we explicitely do not want to do that). See tree-ssa-ccp.c:fold_builtin_alloca_with_align
[Bug c++/90532] is_constructible_v and is_default_constructible_v should agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532 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 --- I am testing a patch to fix __is_constructible.
[Bug translation/90528] ICE caused b bad format string in gimple-ssa-warn-restrict.c:1803 for 'es' locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90528 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug tree-optimization/90525] Wrong offsets in warning text for -Warray-bounds (with subobject)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90525 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-20 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/85569] [8/9/10 Regression] is_invocable(F, decltype(objs)...) fails with "not supported by dump_expr#" unless via indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85569 Martin Liška changed: What|Removed |Added CC||s_gccbugzilla at nedprod dot com --- Comment #14 from Martin Liška --- *** Bug 90534 has been marked as a duplicate of this bug. ***
[Bug c++/90534] [7/8 Regression] ICE in consteval in GCCs 8.3, 8.2, 8.1, 7.3, 7.2 and 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90534 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 85569 ***
[Bug c++/90538] [9/10 Regression] Redeclaration error when expanding parameter pack multiple times in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90538 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-20 CC||aoliva at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||8.3.0 Summary|Redeclaration error when|[9/10 Regression] |expanding parameter pack|Redeclaration error when |multiple times in a lambda |expanding parameter pack ||multiple times in a lambda Ever confirmed|0 |1 Known to fail||10.0, 9.1.0 --- Comment #1 from Martin Liška --- Started with r268850.
[Bug c++/90529] suggest struct or class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90529 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-20 CC||dmalcolm at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532 Jonathan Wakely changed: What|Removed |Added Known to work||7.4.0 Target Milestone|--- |8.4 Summary|is_constructible_v |[8/9/10 Regression] |and |is_constructible_v |is_default_constructible_v< |and |int[]> should agree |is_default_constructible_v< ||int[]> should agree Known to fail||10.0, 8.1.0, 8.3.0, 9.1.0 --- Comment #3 from Jonathan Wakely --- This is a regression due to the addition of the __is_constructible built-in. Before we had that, this correct test passed: #include static_assert( !std::is_constructible::value, ""); static_assert( !std::is_default_constructible::value, ""); static_assert( !std:: is_trivially_constructible::value, ""); static_assert( !std::is_trivially_default_constructible::value, ""); Now three out of four assertions fail, because they use the built-in. I'm testing this fix: --- a/gcc/cp/method.c +++ b/gcc/cp/method.c @@ -1201,6 +1201,8 @@ is_xible_helper (enum tree_code code, tree to, tree from, bool trivial) expr = assignable_expr (to, from); else if (trivial && from && TREE_CHAIN (from)) return error_mark_node; // only 0- and 1-argument ctors can be trivial + else if (TREE_CODE(to) == ARRAY_TYPE && !TYPE_DOMAIN (to)) +return error_mark_node; // can't construct an array of unknown bound else expr = constructible_expr (to, from); return expr;
[Bug middle-end/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #8 from rguenther at suse dot de --- On Mon, 20 May 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 > > --- Comment #7 from Martin Liška --- > (In reply to Richard Biener from comment #6) > > Note the rev. in question can only have made a previously latent issue > > exposed. > > > > It's also not clear to me why this isn't a target issue given there's not > > enough information on who introduces "bad" RTL? Hope Jeff might be able to > > help and Martin with reduction. > > Sure, if Jeff can prepare a sanitity patch that will expose the latent issue, > then I'm able to bisect that. Testcase reduction, not bisection.
[Bug middle-end/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #9 from Martin Liška --- (In reply to rguent...@suse.de from comment #8) > On Mon, 20 May 2019, marxin at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 > > > > --- Comment #7 from Martin Liška --- > > (In reply to Richard Biener from comment #6) > > > Note the rev. in question can only have made a previously latent issue > > > exposed. > > > > > > It's also not clear to me why this isn't a target issue given there's not > > > enough information on who introduces "bad" RTL? Hope Jeff might be able > > > to > > > help and Martin with reduction. > > > > Sure, if Jeff can prepare a sanitity patch that will expose the latent > > issue, > > then I'm able to bisect that. > > Testcase reduction, not bisection. Ah, working on that..
[Bug go/88406] [9/10 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Ian Lance Taylor --- > Is this still worth investigating given that we've dropped support for Solaris > 10? It depends: this single bug accounts for 91% of all testsuite failures on Solaris 10/SPARC and it's a regression from GCC 8. I'd put it this way: if it's easy to analyze and fix, it would be nice to have it fixed in the last release supporting Solaris 10.
[Bug go/88406] [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406 Rainer Orth changed: What|Removed |Added Summary|[9/10 regression] Many |[9 regression] Many 64-bit |64-bit Solaris 10/SPARC |Solaris 10/SPARC execution |execution tests FAIL|tests FAIL --- Comment #6 from Rainer Orth --- Not a GCC 10 regression: Solaris 10 support already removed.
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #14 from Christophe Lyon ---
Sure, here is the contents of cdce3.c.105t.cdce:
;; Function foo (foo, funcdef_no=0, decl_uid=4197, cgraph_uid=1,
symbol_order=0)
foo (float x)
{
float _4;
[local count: 1073741824]:
_4 = sqrtf (x_2(D));
return _4;
}
[Bug fortran/90536] Spurious (?) warning when using -Wconversion with -fno-range-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536 Dominique d'Humieres changed: What|Removed |Added Summary|Use of -fno-range-check |Spurious (?) warning when |creates warnings or errors |using -Wconversion with |when assigning to a byte|-fno-range-check |variable| --- Comment #10 from Dominique d'Humieres --- The following test program test integer :: b1 = 2_8 end gives no warning when compiled with -Wconversion -Wconversion-extra: % gfc pr90536_1_db.f90 -Wconversion -Wconversion-extra % but a warning when compiled with -Wconversion -fno-range-check: % gfc pr90536_1_db.f90 -Wconversion -fno-range-check pr90536_1_db.f90:2:23: 2 | integer :: b1 = 2_8 | 1 Warning: Conversion from 'INTEGER(8)' to 'INTEGER(4)' at (1) [-Wconversion] I see in fortran/intrinsic.c /* Do nothing. Constants of the same type are range-checked elsewhere. If a value too large for the target type is assigned, an error is generated. Not checking here avoids duplications of warnings/errors. If range checking was disabled, but -Wconversion enabled, a non range checked warning is generated below. */ So the behavior may be intended.
[Bug middle-end/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-05-20
Ever confirmed|0 |1
--- Comment #10 from Martin Liška ---
There's a reduced test-case:
$ cat expmed.ii
void fancy_abort(const char *, int, const char *);
enum machine_mode {
E_QImode,
E_HImodeE_DImode,
E_TImode,
MIN_MODE_INT = E_QImode,
MAX_MODE_INT = E_TImode
};
template void is_a(machine_mode, U);
class A {};
struct B {
bool cheap[2][MAX_MODE_INT + 1];
};
struct C {
int cost[2][MAX_MODE_INT + 1];
};
struct {
B x_sdiv_pow2_cheap;
B x_smod_pow2_cheap;
C x_udiv_cost;
} a;
bool *expmed_op_cheap_ptr(B *p1, bool p2, machine_mode p3) {
return &p1->cheap[p2][p3];
}
int *expmed_op_cost_ptr(C *p1, bool p2, machine_mode p3) {
return &p1->cost[p2][p3];
}
bool *b, *c;
int d;
machine_mode e;
void init_expmed() {
machine_mode f;
int g = 0;
for (;; g++) {
f = MIN_MODE_INT;
for (; f <= MAX_MODE_INT; f = machine_mode(f + 1)) {
int *h = expmed_op_cost_ptr(&(&a)->x_udiv_cost, g, f);
*h = d;
b = expmed_op_cheap_ptr(&(&a)->x_sdiv_pow2_cheap, g, f);
*b = (c = expmed_op_cheap_ptr(&(&a)->x_smod_pow2_cheap, g, f));
*c = 0;
A i;
is_a(f, i);
for (; e;)
fancy_abort("", 9, __FUNCTION__);
}
}
}
$ /dev/shm/objdir2/gcc/xgcc -B/dev/shm/objdir2/gcc/ -c expmed.ii -O2
expmed.ii: In function ‘void init_expmed()’:
expmed.ii:48:1: error: unrecognizable insn:
48 | }
| ^
(insn 177 176 178 2 (set (reg:SI 52 %fr24)
(subreg:SI (reg:DI 51 %fr23) 4)) -1
(nil))
during RTL pass: reload
expmed.ii:48:1: internal compiler error: in extract_insn, at recog.c:2310
0x52bc60 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0x52bc7e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:116
0x52baac extract_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.c:2310
0xa2b29d extract_insn_cached(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.c:2199
0x82540a cleanup_subreg_operands(rtx_insn*)
/home/marxin/Programming/gcc/gcc/final.c:3313
0xa54a49 reload(rtx_insn*, int)
/home/marxin/Programming/gcc/gcc/reload1.c:1235
0x9259c0 do_reload
/home/marxin/Programming/gcc/gcc/ira.c:5528
0x9259c0 execute
/home/marxin/Programming/gcc/gcc/ira.c:5700
[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90501 --- Comment #14 from Richard Biener --- (In reply to rguent...@suse.de from comment #13) > That is, why's > > Index: gcc/gimple-walk.c > === > --- gcc/gimple-walk.c (revision 271394) > +++ gcc/gimple-walk.c (working copy) > @@ -829,8 +829,7 @@ walk_stmt_load_store_addr_ops (gimple *s >gimple_call_chain (call_stmt), data); >if (visit_addr > && gimple_call_return_slot_opt_p (call_stmt) > - && gimple_call_lhs (call_stmt) != NULL_TREE > - && TREE_ADDRESSABLE (TREE_TYPE (gimple_call_lhs (call_stmt > + && gimple_call_lhs (call_stmt) != NULL_TREE) > ret |= visit_addr (stmt, gimple_call_lhs (call_stmt), >gimple_call_lhs (call_stmt), data); > } > > not correct? Do we really force a new temporary to be used? > We'd need to be consistent here for inlining as well then. Tested on x86_64-linux, I see FAIL: gcc.dg/tm/memopt-4.c scan-tree-dump-times tmedge "lala.x[55] = tm_save" 1 FAIL: gcc.dg/tm/memopt-4.c scan-tree-dump-times tmedge "tm_save.[0-9_]+ = lala.x[55]" 1 FAIL: gcc.dg/tm/memopt-5.c scan-tree-dump-times tmedge "ITM_LU[0-9] (&lala.x[55]" 1 FAIL: gcc.dg/tm/memopt-6.c scan-tree-dump-times tmedge "memcpyRtWn (.*, &lacopy" 1 FAIL: gcc.dg/tm/memopt-7.c scan-tree-dump-times tmedge "lala = tm_save" 1 FAIL: gcc.dg/tm/memopt-7.c scan-tree-dump-times tmedge "tm_save.[0-9_]+ = lala" 1 didn't check if caused by the above but TM is probably to blame here (and nobody cares). There's also FAIL: gcc.dg/tree-ssa/tailcall-7.c scan-tree-dump-times tailc "Found tail call" 5 but only for -m32. This likely shows one case that would be pessimized (but then it already is for TREE_ADDRESSABLE types...).
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #15 from JunMa ---
(In reply to Christophe Lyon from comment #14)
> Sure, here is the contents of cdce3.c.105t.cdce:
>
> ;; Function foo (foo, funcdef_no=0, decl_uid=4197, cgraph_uid=1,
> symbol_order=0)
>
> foo (float x)
> {
> float _4;
>
>[local count: 1073741824]:
> _4 = sqrtf (x_2(D));
> return _4;
>
> }
The contents are as same as cdce3.c.104t.stdarg. Would you please dump it whit
-fdump-tree-cdce-details?
Then we can see(in x86_64)
Found conditional dead call: _4 = sqrtf (x_2(D));
cdce3.c:9: note: function call is shrink-wrapped into error conditions.
It seems that gcc thinks arm doesn't support direct internal function (maybe
vsqrt instruction ?) of sqrtf .
[Bug fortran/90539] New: [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 Bug ID: 90539 Summary: [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Since the revision I see a slowdown and the ELF section of the binary is about 6% bigger. Machine: model name : Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz SPEC flags: -Ofast -march=native Note that I see similar slowdown also with -O2 (generic, no -march) on the machine.
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-20 CC||tkoenig at gcc dot gnu.org Known to work||9.1.0 Version|unknown |10.0 Blocks||26163 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #16 from Christophe Lyon ---
That's what I did... (use -fdump-tree-cdce-details).
The assembler code is:
.arm
.fpu softvfp
.type foo, %function
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
b sqrtf
which is a tail call ('b' is a jump instruction on arm, not a call).
[Bug c++/90540] New: Improve diagnostic for forming array of abstract class type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90540
Bug ID: 90540
Summary: Improve diagnostic for forming array of abstract class
type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
struct ABC {
virtual void f() = 0;
};
template struct X { };
X x;
Gives the error:
abc.cc:5:6: error: array of abstract class type 'ABC'
X x;
^
abc.cc:2:16: note: unimplemented pure virtual method 'f' in 'ABC'
virtual void f() = 0;
^
1 error generated.
This isn't very helpful, because there's no attempt to allocate any object of
type ABC. It would be better to say something like arrays of abstract class
types are not valid types (although I don't see where the standard says you
can't even refer to them in this context).
Clang says:
abc.cc:5:6: error: array of abstract class type 'ABC'
X x;
^
abc.cc:2:16: note: unimplemented pure virtual method 'f' in 'ABC'
virtual void f() = 0;
^
1 error generated.
Which is slightly better, but it doesn't actually say what's *wrong* with an
array of abstract class type.
EDG wins here:
"abc.cc", line 5: error: array of abstract class "ABC" is not allowed:
function "ABC::f" is a pure virtual function
X x;
^
1 error detected in the compilation of "abc.cc".
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #17 from JunMa ---
(In reply to Christophe Lyon from comment #16)
> That's what I did... (use -fdump-tree-cdce-details).
>
> The assembler code is:
> .arm
> .fpu softvfp
> .type foo, %function
> foo:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> @ link register save eliminated.
> b sqrtf
>
> which is a tail call ('b' is a jump instruction on arm, not a call).
Hmm... I think the testcase works with -mfpu=vfp -mfloat-abi=hard.
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #18 from Christophe Lyon ---
(In reply to JunMa from comment #17)
> (In reply to Christophe Lyon from comment #16)
> > That's what I did... (use -fdump-tree-cdce-details).
> >
> > The assembler code is:
> > .arm
> > .fpu softvfp
> > .type foo, %function
> > foo:
> > @ args = 0, pretend = 0, frame = 0
> > @ frame_needed = 0, uses_anonymous_args = 0
> > @ link register save eliminated.
> > b sqrtf
> >
> > which is a tail call ('b' is a jump instruction on arm, not a call).
>
> Hmm... I think the testcase works with -mfpu=vfp -mfloat-abi=hard.
Indeed, sorry I wasn't specific enough when I said "arm".
The test fails on arm-none-linux-gnueabi, and passes on
arm-none-linux-gnueabihf.
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530
Richard Biener changed:
What|Removed |Added
Component|middle-end |target
--- Comment #11 from Richard Biener ---
I wonder what the difference to PA is between the reloaded
+(insn 20 181 182 2 (set (reg:DI 50 %fr22 [95])
+(mult:DI (zero_extend:DI (reg:SI 52 %fr24))
+(reg:DI 53 %fr25))) 179 {*pa.md:5338}
and the original
-(insn 20 10 21 2 (set (reg:DI 95)
-(mult:DI (zero_extend:DI (subreg:SI (reg/f:DI 146) 4))
-(const_int 4294967295 [0x]))) 179 {*pa.md:5338}
most definitely a reload as
+(insn 177 176 178 2 (set (reg:SI 52 %fr24)
+(subreg:SI (reg:DI 51 %fr23) 4)) -1
+ (nil))
which isn't recognized isn't good. I don't know PA on what it can
and what not but these kind of sets from subregs appear during RTL
expansion for
;; _26 = _27 * 18446744073709551613;
and RTL opts push them into the mult.
To me it looks like a testcase like
int a;
__SIZE_TYPE__ foo ()
{
return (__SIZE_TYPE__)&a * 18446744073709551613ull;
}
should trigger the same issue. It creates the same RTL with
-O2 -fno-tree-vrp -fdisable-tree-evrp but the doesn't ICE beause
we reload
(insn 16 10 19 2 (set (reg:DI 77)
(mult:DI (zero_extend:DI (subreg:SI (reg:DI 81) 4))
(const_int 4294967293 [0xfffd]))) "t.c":6:14 179 {*pa.md:5338}
via memory as
(insn 47 52 48 2 (set (mem/c:DI (plus:DI (reg/f:DI 30 %r30)
(const_int -56 [0xffc8])) [0 S8 A64])
(reg:DI 19 %r19)) "t.c":6:14 128 {*pa.md:4178}
(nil))
(insn 48 47 16 2 (set (reg:DI 51 %fr23)
(mem/c:DI (plus:DI (reg/f:DI 30 %r30)
(const_int -56 [0xffc8])) [0 S8 A64])) "t.c":6:14
128 {*pa.md:4178}
(nil))
(insn 16 48 53 2 (set (reg:DI 52 %fr24)
(mult:DI (zero_extend:DI (reg:SI 51 %fr23))
(reg:DI 52 %fr24))) "t.c":6:14 179 {*pa.md:5338}
(nil))
not sure if we're just lucky here or what.
Anyhow this is IMHO clearly a target issue.
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #19 from JunMa ---
we can skip the target by adding
/* { dg-skip-if "need hardfp abi" { *-*-* } { "-mfloat-abi=soft" } { "" } } */
to testcase.
[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #4 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01226.html
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #12 from John David Anglin --- Created attachment 46383 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46383&action=edit Patch
[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Mon May 20 11:32:51 2019 New Revision: 271412 URL: https://gcc.gnu.org/viewcvs?rev=271412&root=gcc&view=rev Log: PR c++/90532 Ensure __is_constructible(T[]) is false An array of an unknown bound is an incomplete type, so no object of such a type can be constructed. This means __is_constructible should always be false for an array of unknown bound. This patch also changes the std::is_default_constructible trait to use std::is_constructible, which now gives the right answer for arrays of unknown bound. gcc/cp: PR c++/90532 Ensure __is_constructible(T[]) is false * method.c (is_xible_helper): Return error_mark_node for construction of an array of unknown bound. gcc/testsuite: PR c++/90532 Ensure __is_constructible(T[]) is false * g++.dg/ext/90532.C: New test. libstdc++-v3: PR c++/90532 Ensure __is_constructible(T[]) is false * include/std/type_traits (__do_is_default_constructible_impl) (__is_default_constructible_atom, __is_default_constructible_safe): Remove. (is_default_constructible): Use is_constructible. * testsuite/20_util/is_constructible/value.cc: Check int[] case. * testsuite/20_util/is_default_constructible/value.cc: Likewise. * testsuite/20_util/is_trivially_constructible/value.cc: Likewise. * testsuite/20_util/is_trivially_default_constructible/value.cc: Likewise. Added: trunk/gcc/testsuite/g++.dg/ext/90532.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/is_constructible/value.cc trunk/libstdc++-v3/testsuite/20_util/is_default_constructible/value.cc trunk/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc trunk/libstdc++-v3/testsuite/20_util/is_trivially_default_constructible/value.cc
[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532 --- Comment #6 from Jonathan Wakely --- Fixed on trunk so far.
[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58321 Eric Gallager changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Dominique d'Humieres from comment #3) > Still present at r220301 (see > https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html). Does the > patch in comment 2 makes sense or is there a better fix? cc-ing FX from that
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 --- Comment #3 from Eric Gallager --- is this an ice-on-valid or an ice-on-invalid?
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #1 from Richard Biener --- Haswell as well (https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/recent.html) but only 10% and not bisected.
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 --- Comment #11 from Eric Gallager --- Are you still working on this, Jonathan?
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.0 --- Comment #12 from Jonathan Wakely --- Yes.
[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58321
--- Comment #7 from Iain Sandoe ---
(In reply to Eric Gallager from comment #6)
> (In reply to Dominique d'Humieres from comment #3)
> > Still present at r220301 (see
> > https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html). Does the
> > patch in comment 2 makes sense or is there a better fix?
>
> cc-ing FX from that
I have a local patch for this too, which I'm intending to apply as time
permits. The main difference is explaining the reason that Darwin is different
- and simplifying the condition.
/* { dg-do compile } */
/* { dg-options "-O2 -march=atom
-mmemcpy-strategy=vector_loop:2000:align,libcall:-1:align" } */
-/* { dg-final { scan-assembler-times "memcpy" 2 } } */
+/* one hit comes from the .file directive. */
+/* { dg-final { scan-assembler-times "memcpy" 2 { target { ! *-*-darwin* } } }
} */
+/* but not on Darwin. */
+/* { dg-final { scan-assembler-times "_memcpy" 1 { target *-*-darwin* } } }
*/
char a[2048];
char b[2048];
[Bug c/70378] wrong warning with -Wconversion with explicit cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70378 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #5 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #13 from dave.anglin at bell dot net --- On 2019-05-20 6:26 a.m., rguenth at gcc dot gnu.org wrote: > most definitely a reload as > > +(insn 177 176 178 2 (set (reg:SI 52 %fr24) > +(subreg:SI (reg:DI 51 %fr23) 4)) -1 > + (nil)) > > which isn't recognized isn't good. I don't know PA on what it can > and what not but these kind of sets from subregs appear during RTL > expansion for This isn't recognized because the only way to do it in general is to spill reg:DI 51 to memory and to read it back in SI mode. Maybe we are lucky with the const_int because some values are forced constant pool. There are no convert instructions other than sf<=>df mode and loads don't zero extend as they do to the integer registers. As I said, pa_can_change_mode_class() is written to prevent mode changes in the FP registers: /* There is no way to load QImode or HImode values directly from memory to a FP register. SImode loads to the FP registers are not zero extended. On the 64-bit target, this conflicts with the definition of LOAD_EXTEND_OP. Thus, we can't allow changing between modes with different sizes in the floating-point registers. */ if (MAYBE_FP_REG_CLASS_P (rclass)) return false; My feeling is reload should respect pa_can_change_mode_class(). The left and right halves of the float doubles are separately addressable, so in this particular case the pattern could be implemented using register renaming, but that was never done.
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400 Pekka S changed: What|Removed |Added CC||p...@gcc-bugzilla.mail.kaps ||i.fi --- Comment #3 from Pekka S --- Created attachment 46384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46384&action=edit _Pragma tests These all yield different results, the first two won't compile but fail on different lines, which is a bit strange, as the preprocessor output doesn't appear to change (e.g. if only doing -E). The last one compiles, but obviously just because it omits the pragmas. GCC10 and GCC7 behave both the same with this test setup, so I suspect this is a long standing feature and/or issue. gcc -Wall -Wextra -c pragma.c gcc -Wall -Wextra -save-temps -c pragma.c gcc -Wall -Wextra -save-temps -DNOPRAGMA -c pragma.c
[Bug c/90541] New: Warning not emitted on use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90541
Bug ID: 90541
Summary: Warning not emitted on use of uninitialized variable
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: wingo at igalia dot com
Target Milestone: ---
$ gcc --version
gcc (GCC) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat /tmp/foo.c
#include
uint16_t read_short(void) {
uint16_t *loc = (uint16_t*)loc;
return loc[0];
}
$ gcc -Wall -o /tmp/foo.o -c /tmp/foo.c
I would have expected that "uint16_t *loc = (uint16_t*)loc" issues an
uninitialized variable warning, but no warning is emitted.
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 Richard Biener changed: What|Removed |Added Keywords||ra CC||vmakarov at gcc dot gnu.org --- Comment #14 from Richard Biener --- (In reply to dave.anglin from comment #13) > On 2019-05-20 6:26 a.m., rguenth at gcc dot gnu.org wrote: > > most definitely a reload as > > > > +(insn 177 176 178 2 (set (reg:SI 52 %fr24) > > +(subreg:SI (reg:DI 51 %fr23) 4)) -1 > > + (nil)) > > > > which isn't recognized isn't good. I don't know PA on what it can > > and what not but these kind of sets from subregs appear during RTL > > expansion for > This isn't recognized because the only way to do it in general is to spill > reg:DI 51 to memory > and to read it back in SI mode. Yeah, and for the C testcase it does... > Maybe we are lucky with the const_int > because some values > are forced constant pool. > > There are no convert instructions other than sf<=>df mode and loads don't > zero extend as > they do to the integer registers. > > As I said, pa_can_change_mode_class() is written to prevent mode changes in > the FP registers: > > /* There is no way to load QImode or HImode values directly from memory > to a FP register. SImode loads to the FP registers are not zero > extended. On the 64-bit target, this conflicts with the definition > of LOAD_EXTEND_OP. Thus, we can't allow changing between modes with > different sizes in the floating-point registers. */ > if (MAYBE_FP_REG_CLASS_P (rclass)) > return false; > > My feeling is reload should respect pa_can_change_mode_class(). Maybe it's asking wrong since you have if (GET_MODE_SIZE (from) == GET_MODE_SIZE (to)) return true; and the size of the SUBREG_REG is the same as the FP reg? You'd need to debug here.
[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58321 --- Comment #8 from Iain Sandoe --- Author: iains Date: Mon May 20 12:28:18 2019 New Revision: 271415 URL: https://gcc.gnu.org/viewcvs?rev=271415&root=gcc&view=rev Log: darwin, testsuite - fix PR58321 Darwin doesn't emit a .file directive by default and one of the scan-asm hits for ELF targets comes from this directive. Adjust for Darwin and explain. 2019-05-20 Iain Sandoe PR testsuite/58321 * gcc.target/i386/memcpy-strategy-3.c: Adjust count for Darwin and add a comment as to the reason for the difference. * gcc.target/i386/memset-strategy-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/memcpy-strategy-3.c trunk/gcc/testsuite/gcc.target/i386/memset-strategy-1.c
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #15 from Richard Biener --- (In reply to Richard Biener from comment #14) > (In reply to dave.anglin from comment #13) > > On 2019-05-20 6:26 a.m., rguenth at gcc dot gnu.org wrote: > > > most definitely a reload as > > > > > > +(insn 177 176 178 2 (set (reg:SI 52 %fr24) > > > +(subreg:SI (reg:DI 51 %fr23) 4)) -1 > > > + (nil)) > > > > > > which isn't recognized isn't good. I don't know PA on what it can > > > and what not but these kind of sets from subregs appear during RTL > > > expansion for > > This isn't recognized because the only way to do it in general is to spill > > reg:DI 51 to memory > > and to read it back in SI mode. > > Yeah, and for the C testcase it does... > > > Maybe we are lucky with the const_int > > because some values > > are forced constant pool. > > > > There are no convert instructions other than sf<=>df mode and loads don't > > zero extend as > > they do to the integer registers. > > > > As I said, pa_can_change_mode_class() is written to prevent mode changes in > > the FP registers: > > > > /* There is no way to load QImode or HImode values directly from memory > > to a FP register. SImode loads to the FP registers are not zero > > extended. On the 64-bit target, this conflicts with the definition > > of LOAD_EXTEND_OP. Thus, we can't allow changing between modes with > > different sizes in the floating-point registers. */ > > if (MAYBE_FP_REG_CLASS_P (rclass)) > > return false; > > > > My feeling is reload should respect pa_can_change_mode_class(). > > Maybe it's asking wrong since you have > > if (GET_MODE_SIZE (from) == GET_MODE_SIZE (to)) > return true; > > and the size of the SUBREG_REG is the same as the FP reg? You'd need > to debug here. The only uses of can_change_mode_class are from old reload.c and via REG_CAN_CHANGE_MODE_P (also mostly used from old reload). AFAICS pa is using LRA now.
[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58321 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |7.5
[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Mon May 20 13:02:10 2019 New Revision: 271417 URL: https://gcc.gnu.org/viewcvs?rev=271417&root=gcc&view=rev Log: PR c++/90532 Ensure __is_constructible(T[]) is false An array of an unknown bound is an incomplete type, so no object of such a type can be constructed. This means __is_constructible should always be false for an array of unknown bound. This patch also changes the std::is_default_constructible trait to use std::is_constructible, which now gives the right answer for arrays of unknown bound. gcc/cp: Backported from mainline 2019-05-20 Jonathan Wakely PR c++/90532 Ensure __is_constructible(T[]) is false * method.c (is_xible_helper): Return error_mark_node for construction of an array of unknown bound. gcc/testsuite: Backported from mainline 2019-05-20 Jonathan Wakely PR c++/90532 Ensure __is_constructible(T[]) is false * g++.dg/ext/90532.C: New test. libstdc++-v3: Backported from mainline 2019-05-20 Jonathan Wakely PR c++/90532 Ensure __is_constructible(T[]) is false * include/std/type_traits (__do_is_default_constructible_impl) (__is_default_constructible_atom, __is_default_constructible_safe): Remove. (is_default_constructible): Use is_constructible. * testsuite/20_util/is_constructible/value.cc: Check int[] case. * testsuite/20_util/is_default_constructible/value.cc: Likewise. * testsuite/20_util/is_trivially_constructible/value.cc: Likewise. * testsuite/20_util/is_trivially_default_constructible/value.cc: Likewise. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/ext/90532.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/method.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/include/std/type_traits branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_constructible/value.cc branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_default_constructible/value.cc branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_trivially_default_constructible/value.cc
[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Mon May 20 13:04:39 2019 New Revision: 271418 URL: https://gcc.gnu.org/viewcvs?rev=271418&root=gcc&view=rev Log: PR c++/90532 Ensure __is_constructible(T[]) is false An array of an unknown bound is an incomplete type, so no object of such a type can be constructed. This means __is_constructible should always be false for an array of unknown bound. This patch also changes the std::is_default_constructible trait to use std::is_constructible, which now gives the right answer for arrays of unknown bound. gcc/cp: Backported from mainline 2019-05-20 Jonathan Wakely PR c++/90532 Ensure __is_constructible(T[]) is false * method.c (is_xible_helper): Return error_mark_node for construction of an array of unknown bound. gcc/testsuite: Backported from mainline 2019-05-20 Jonathan Wakely PR c++/90532 Ensure __is_constructible(T[]) is false * g++.dg/ext/90532.C: New test. libstdc++-v3: Backported from mainline 2019-05-20 Jonathan Wakely PR c++/90532 Ensure __is_constructible(T[]) is false * include/std/type_traits (__do_is_default_constructible_impl) (__is_default_constructible_atom, __is_default_constructible_safe): Remove. (is_default_constructible): Use is_constructible. * testsuite/20_util/is_constructible/value.cc: Check int[] case. * testsuite/20_util/is_default_constructible/value.cc: Likewise. * testsuite/20_util/is_trivially_constructible/value.cc: Likewise. * testsuite/20_util/is_trivially_default_constructible/value.cc: Likewise. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/ext/90532.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/method.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/std/type_traits branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_constructible/value.cc branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_default_constructible/value.cc branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_trivially_default_constructible/value.cc
[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- And on the branches too, for 8.4 and 9.2.
[Bug libstdc++/90542] Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90542 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-20 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I haven't confirmed it, but I suspect this is a regression, because these symbols are new in 9.1.0
[Bug libstdc++/90542] New: Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90542 Bug ID: 90542 Summary: Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org CC: ro at gcc dot gnu.org Target Milestone: --- /bin/sh ../../libtool --tag CXX --mode=link /export/home/jwakely/build/./gcc/xgcc -shared-libgcc -B/export/home/jwakely/build/./gcc -nostdinc++ -L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src -L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/bin/ -B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/lib/ -isystem /export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/include -isystem /export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/sys-include -fno-checking-std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:26:0 -Wl,-M,libstdc++-symbols.ver-sun -lm -rpath /export/home/jwakely/gcc/9.1.0/lib/debug compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-c++0x.lo compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo -lrt ../../libsupc++/libsupc++convenience.la ../../src/debug/c++98/libc++98convenience.la ../../src/debug/c++11/libc++11convenience.la ../../src/debug/c++17/libc++17convenience.la libtool: link: /export/home/jwakely/build/./gcc/xgcc -shared-libgcc -B/export/home/jwakely/build/./gcc -nostdinc++ -L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src -L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/bin/ -B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/lib/ -isystem /export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/include -isystem /export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/sys-include -fno-checking -shared -nostdlib /usr/lib/crti.o /export/home/jwakely/build/./gcc/crtbegin.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-z -Wl,allextract ../../libsupc++/.libs/libsupc++convenience.a ../../src/debug/c++98/.libs/libc++98convenience.a ../../src/debug/c++11/.libs/libc++11convenience.a ../../src/debug/c++17/.libs/libc++17convenience.a -Wl,-z -Wl,defaultextract -L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src -L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -lm -lrt -L/export/home/jwakely/build/./gcc -lgcc_s -lc -lgcc_s -lc /export/home/jwakely/build/./gcc/crtend.o /usr/lib/crtn.o -Wl,-M -Wl,libstdc++-symbols.ver-sun -Wl,-h -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.26 ld: fatal: libstdc++-symbols.ver-sun: 5381: symbol 'std::enable_if > const&, std::basic_string_view > >, std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >, std::__not_ > const&, char const*> > >::value, std::__cxx11::basic_string, std::allocator >&>::type std::__cxx11::basic_string, std::allocator >::append > >(std::basic_string_view > const&)': symbol version conflict ld: fatal: libstdc++-symbols.ver-sun: 5382: symbol 'std::enable_if > const&, std::basic_string_view > >, std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >, std::__not_ > const&, char const*> > >::value, std::__cxx11::basic_string, std::allocator >&>::type std::__cxx11::basic_string, std::allocator >::append > >(std::basic_string_view > const&)': symbol version conflict ld: fatal: libstdc++-symbols.ver-sun: 5399: symbol 'std::enable_if > const&, std::basic_string_view > >, std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >, std::__not_ > const&, char const*> > >::value, std::__cxx11::basic_string, std::allocator >&>::type std::__cxx11::basic_string, std::allocator >::assign > >(std::basic_string_view > const&)': symbol version conflict ld: fatal: libstdc++-symbols.ver-sun: 5400: symbol 'std::enable_if > const&, std::basic_string_view > >, std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >, std::__not_ > const&, char const*> > >::value, std::__cxx11::basic_string, std::
[Bug libstdc++/90542] Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90542 --- Comment #2 from Jonathan Wakely --- It looks like the std::e[a-q]* pattern can simply be removed.
[Bug bootstrap/90543] New: Build failure on MINGW for gcc-9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90543
Bug ID: 90543
Summary: Build failure on MINGW for gcc-9.1.0
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: baue.flor.dev at gmail dot com
Target Milestone: ---
Created attachment 46385
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46385&action=edit
Occured error
Hello team,
the following problem (see attatchment GCCBuildError.PNG) occured during a
gcc-9.1.0 build on MINGW. I used 64-bit windows 7 as host system.
host=x86_64-w64-mingw32
build=$host
target=aarch64-elf
targetlocal=mingw32
builddir=/build/${target}_9.1.0_x64
prefix=$builddir/cross-gcc/$target
prefixlocal=$builddir/host
Build commands:
--host=$host --build=$build --prefix=$prefix --target=$target --disable-nls
--enable-multilib --with-multilib-list=lp64,ilp32 --enable-languages=c,c++,d
--disable-decimal-float --with-sysroot=$prefix --without-headers
--disable-shared --disable-threads --disable-lto --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libffi --disable-libstdcxx-pch
--disable-win32-registry '--with-host-libstdcxx=-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-newlib --with-gcc --with-gnu-as
--with-gnu-ld --with-gmp=$prefixlocal --with-mpfr=$prefixlocal
--with-mpc=$prefixlocal --with-isl=$prefixlocal
The file options-save.c contains invalid cast operations. Casting to
(uintptr_t) instead of (unsigned long) may solve the issue.
Info: options-save.c is auto-generated by optc-save-gen.awk.
I used the following fix in my case:
--- options-save.org.c 2019-05-20 12:52:48 +
+++ options-save.c 2019-05-20 11:36:06 +
@@ -3906,7 +3906,7 @@
fprintf (file, "%*s%s (%#lx)\n",
indent, "",
"aarch64_branch_protection_string",
- (unsigned long)ptr->x_aarch64_branch_protection_string);
+ (uintptr_t)ptr->x_aarch64_branch_protection_string);
if (ptr->x_target_flags)
fprintf (file, "%*s%s (%#lx)\n",
@@ -3973,8 +3973,8 @@
fprintf (file, "%*s%s (%#lx/%#lx)\n",
indent, "",
"aarch64_branch_protection_string",
- (unsigned long)ptr1->x_aarch64_branch_protection_string,
- (unsigned long)ptr2->x_aarch64_branch_protection_string);
+ (uintptr_t)ptr1->x_aarch64_branch_protection_string,
+ (uintptr_t)ptr2->x_aarch64_branch_protection_string);
Greetings,
Bauer Florian
[Bug bootstrap/90544] New: Build failure on MINGW for gcc-9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90544
Bug ID: 90544
Summary: Build failure on MINGW for gcc-9.1.0
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: baue.flor.dev at gmail dot com
Target Milestone: ---
Hello team,
the following problem (see attatchment GCCBuildError.PNG) occured during a
gcc-9.1.0 build on MINGW. I used 64-bit windows 7 as host system.
host=x86_64-w64-mingw32
build=$host
target=aarch64-elf
targetlocal=mingw32
builddir=/build/${target}_9.1.0_x64
prefix=$builddir/cross-gcc/$target
prefixlocal=$builddir/host
Build commands:
--host=$host --build=$build --prefix=$prefix --target=$target --disable-nls
--enable-multilib --with-multilib-list=lp64,ilp32 --enable-languages=c,c++,d
--disable-decimal-float --with-sysroot=$prefix --without-headers
--disable-shared --disable-threads --disable-lto --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libffi --disable-libstdcxx-pch
--disable-win32-registry '--with-host-libstdcxx=-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-newlib --with-gcc --with-gnu-as
--with-gnu-ld --with-gmp=$prefixlocal --with-mpfr=$prefixlocal
--with-mpc=$prefixlocal --with-isl=$prefixlocal
The file options-save.c contains invalid cast operations. Casting to
(uintptr_t) instead of (unsigned long) may solve the issue.
Info: options-save.c is auto-generated by optc-save-gen.awk.
I used the following fix in my case:
--- options-save.org.c 2019-05-20 12:52:48 +
+++ options-save.c 2019-05-20 11:36:06 +
@@ -3906,7 +3906,7 @@
fprintf (file, "%*s%s (%#lx)\n",
indent, "",
"aarch64_branch_protection_string",
- (unsigned long)ptr->x_aarch64_branch_protection_string);
+ (uintptr_t)ptr->x_aarch64_branch_protection_string);
if (ptr->x_target_flags)
fprintf (file, "%*s%s (%#lx)\n",
@@ -3973,8 +3973,8 @@
fprintf (file, "%*s%s (%#lx/%#lx)\n",
indent, "",
"aarch64_branch_protection_string",
- (unsigned long)ptr1->x_aarch64_branch_protection_string,
- (unsigned long)ptr2->x_aarch64_branch_protection_string);
+ (uintptr_t)ptr1->x_aarch64_branch_protection_string,
+ (uintptr_t)ptr2->x_aarch64_branch_protection_string);
Greetings,
Bauer Florian
[Bug bootstrap/90544] Build failure on MINGW for gcc-9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90544 --- Comment #1 from Florian Bauer --- Created attachment 46386 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46386&action=edit Occured error
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #9 from Segher Boessenkool --- With a local entry offset? Do you mean it has non-zero top three bits of st_other?
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #10 from Alan Modra --- Yes, just like the function _ZN12Intermediate1vEv. From here: .set.LTHUNK0,_ZN12Intermediate1vEv
[Bug c/90541] Warning not emitted on use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90541 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amonakov at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Alexander Monakov --- Documentation for -Wuninitialized points out that you need -Winit-self to catch such patterns (and you do get a warning in that case). Seems to work exactly as documented.
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #16 from dave.anglin at bell dot net --- On 2019-05-20 8:14 a.m., rguenth at gcc dot gnu.org wrote: >> My feeling is reload should respect pa_can_change_mode_class(). > Maybe it's asking wrong since you have > > if (GET_MODE_SIZE (from) == GET_MODE_SIZE (to)) > return true; > > and the size of the SUBREG_REG is the same as the FP reg? Good point!
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #2 from Thomas Koenig --- I am a bit surprised at this, that the library version of packing seems to be faster than the inlined one. Or maybe some argument is now packed which should not be. Increased code size is sort of expected, copying inline is bigger than calling s library function. This is why this is not done at -Os. Is it possible to get a reduced test case that shows the slowdown?
[Bug rtl-optimization/43147] SSE shuffle merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147 --- Comment #10 from Marc Glisse --- Author: glisse Date: Mon May 20 14:53:29 2019 New Revision: 271422 URL: https://gcc.gnu.org/viewcvs?rev=271422&root=gcc&view=rev Log: [i386] Fold __builtin_ia32_shufpd to VEC_PERM_EXPR 2019-05-20 Marc Glisse PR rtl-optimization/43147 * config/i386/i386.c (ix86_gimple_fold_builtin): Handle IX86_BUILTIN_SHUFPD. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/90522] unrecognizable insn (V8SF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90522 --- Comment #4 from Leo Sandoval --- I cannot reproduced the problem on neither on 10.0.0 nor gcc-9-branch. This time I made sure that I had a clean build folder and starting from this, I did not see the issue (somehow, when sharing the same build folder based on different gcc versions, things go messy...). For completeness, this is the output of gcc -v /home/lsandov1/repos/tools-build/gcc-native/release/usr/gcc-10.0.0-native/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/lsandov1/repos/tools-build/gcc-native/release/usr/gcc-10.0.0-native/bin/gcc COLLECT_LTO_WRAPPER=/home/lsandov1/repos/tools-build/gcc-native/release/usr/gcc-10.0.0-native/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/lsandov1/repos/gcc/configure --with-demangler-in-ld --prefix=/usr/gcc-10.0.0-native --with-local-prefix=/usr/local --enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib --enable-libmpx --with-arch\ =native --with-cpu=native --with-fpmath=sse --enable-languages=c,c++,fortran Thread model: posix gcc version 10.0.0 20190516 (experimental) (GCC) thanks Uros/Richard for your comments.
[Bug target/90522] unrecognizable insn (V8SF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90522 Leo Sandoval changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 --- Comment #20 from Christophe Lyon --- Author: clyon Date: Mon May 20 15:01:46 2019 New Revision: 271424 URL: https://gcc.gnu.org/viewcvs?rev=271424&root=gcc&view=rev Log: [testsuite] PR90106 Fix cdce3.c testcase 2019-05-20 Christophe Lyon PR tree-optimization/90106 * gcc.dg/cdce3.c: Add hard_float effective target. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cdce3.c
[Bug fortran/90536] Spurious (?) warning when using -Wconversion with -fno-range-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536 --- Comment #11 from Steve Kargl --- On Mon, May 20, 2019 at 07:32:09AM +, tkoenig at gcc dot gnu.org wrote: > > what I meant is that > > Program main > Integer(kind=1) :: n > n = 1 > End > > should not warn with -fno-range-check -Wall, and it does. > The warning technically is correct. It is a warning about the type conversion not about the value. d.f90:3:6: 3 | n = 1 | 1 Warning: Conversion from 'INTEGER(4)' to 'INTEGER(1)' at (1) [-Wconversion] Here '1' is INTEGER(4). The assignment converts it to INTEGER(1). Hence, a warning is issued. Preventing range checking causes one to take a different path through the compiler. If -Wconversion is active, then you shockingly might get a warning. If a user doesn't want to see warnings, don't ask for them! In fact, one might argument that if a warning isn't issued with either -Wconversion or especially -Wconversion-extra, then these options are broken. Personally, I think this PR is much ado about nothing as one can simply add -Wno-conversion to the options to suppress a valid warning. I closed the PR. It has now been re-opened, but mysteriously it has not be assigned.
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 --- Comment #4 from Steve Kargl --- On Mon, May 20, 2019 at 11:48:23AM +, egallager at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 > > --- Comment #3 from Eric Gallager --- > is this an ice-on-valid or an ice-on-invalid? > ice-on-valid
[Bug c/90541] Warning not emitted on use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90541 --- Comment #2 from Andy Wingo --- Thanks for the information. For what it's worth, clang issues a warning for this code, and includes this warning under -Wall.
[Bug tree-optimization/90525] Wrong offsets in warning text for -Warray-bounds (with subobject)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90525 Martin Sebor changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0 --- Comment #1 from Martin Sebor --- The warning means to say that the pointers formed by adding the offsets to the starting address are out-of-bounds. Offset 1 from &t.a isn't out-of-bounds -- it points just past the end of t.a (it just isn't dereferenceable). But offsets 2 and 3 definitely are out of the bounds of t.a.
[Bug fortran/90536] Spurious (?) warning when using -Wconversion with -fno-range-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug target/90545] New: [10 regression] gcc.target/powerpc/fold-vec-splats-floatdouble.c fails starting with r271022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90545
Bug ID: 90545
Summary: [10 regression]
gcc.target/powerpc/fold-vec-splats-floatdouble.c fails
starting with r271022
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
This happens on just power 9.
spawn -ignore SIGHUP /home3/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home3/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/fold-vec-splats-floatdouble.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -mvsx -O1 -ffat-lto-objects -fno-ident -S -o
fold-vec-splats-floatdouble.s
PASS: gcc.target/powerpc/fold-vec-splats-floatdouble.c (test for excess errors)
gcc.target/powerpc/fold-vec-splats-floatdouble.c: xxpermdi found 0 times
FAIL: gcc.target/powerpc/fold-vec-splats-floatdouble.c scan-assembler-times
xxpermdi 1
PASS: gcc.target/powerpc/fold-vec-splats-floatdouble.c scan-assembler-times
\\mxscvdpspn?\\M 1
PASS: gcc.target/powerpc/fold-vec-splats-floatdouble.c scan-assembler-times
\\mvspltw\\M|\\mxxspltw\\M 1
test1f before r271022:
test1f:
.LFB1:
.cfi_startproc
xxpermdi 34,1,1,0
blr
After r271022:
test1f:
.LFB1:
.cfi_startproc
mfvsrd 9,1
mtvsrdd 34,9,9
blr
gcc.target/powerpc/fold-vec-splats-floatdouble.c:
/* Verify that overloaded built-ins for vec_splat with float and
double inputs for VSX produce the right code. */
/* { dg-do compile } */
/* { dg-require-effective-target powerpc_vsx_ok } */
/* { dg-options "-mvsx -O1" } */
#include
vector float
test1d (float x)
{
return vec_splats (x);
}
vector double
test1f (double x)
{
return vec_splats (x);
}
// float test generates the permute instruction.
/* { dg-final { scan-assembler-times "xxpermdi" 1 } } */
// double test generates a convert (double to single non-signalling) followed
by a splat.
/* { dg-final { scan-assembler-times {\mxscvdpspn?\M} 1 } } */
/* { dg-final { scan-assembler-times {\mvspltw\M|\mxxspltw\M} 1 } } */
[Bug libstdc++/89732] FAIL: experimental/memory_resource/new_delete_resource.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89732 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- I'm closing this, since the patch that caused it isn't actually committed. *** This bug has been marked as a duplicate of bug 77691 ***
[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #32 from Jonathan Wakely --- *** Bug 89732 has been marked as a duplicate of this bug. ***
[Bug c++/90546] New: [9.1 regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546
Bug ID: 90546
Summary: [9.1 regression] Incorrect template argument deduction
for conversion functions
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ndkrempel at gmail dot com
Target Milestone: ---
The following code deduces T = Foo using gcc 9.1, whereas gcc 8.3 (and clang 7
up) deduced T = const Foo. My reading of the standard (see below) is that T =
const Foo is correct.
struct Foo {};
void test(const Foo&);
struct Bar {
template operator T&&();
};
int main() {
test(Bar{});
}
(compiled with -std=c++2a, but same behaviour with all language versions)
Relevant standards text: http://eel.is/c++draft/temp.deduct.conv
My reading of this applied to the above program is:
P is T&&, A is const Foo&
P is a reference type -> just treat as T from here on
A is not cv-qualified
A is a reference type -> use const Foo for type deduction
Now attempting to match T with const Foo succeeds with T = const Foo, so we
don't even need to consider the four bulleted exceptional cases ("These
alternatives are considered only if type deduction would otherwise fail.")
[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/90547] New: [8/9/10 Regression] ICE in gen_lowpart_general, at rtlhooks.c:63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90547
Bug ID: 90547
Summary: [8/9/10 Regression] ICE in gen_lowpart_general, at
rtlhooks.c:63
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
This is a follow-up of pr89945 :
$ cat z1.c
void
foo ()
{
void *g[] = {&&a, &&b};
for (unsigned c = 0x1F;; c >>= 1)
{
unsigned d = "a"+1;
long e = 8;
while (e)
{
a: goto *g[c&d];
b: e--;
}
}
}
$ gcc-6 -c z1.c -O2
z1.c: In function 'foo':
z1.c:8:20: warning: initialization makes integer from pointer without a cast
[-Wint-conversion]
unsigned d = "a"+1;
^~~
# gcc-10-20190519 -c z1.c also compiles it.
$ gcc-10-20190519 -c z1.c -O2
z1.c: In function 'foo':
z1.c:8:20: warning: initialization of 'unsigned int' from 'char *' makes
integer from pointer without a cast [-Wint-conversion]
8 | unsigned d = "a"+1;
|^~~
during RTL pass: split1
z1.c:17:1: internal compiler error: in gen_lowpart_general, at rtlhooks.c:63
17 | }
| ^
0xa2e978 gen_lowpart_general(machine_mode, rtx_def*)
../../gcc/rtlhooks.c:63
0xf92b0e gen_split_144(rtx_insn*, rtx_def**)
../../gcc/config/i386/i386.md:8529
0x112a34f split_17
../../gcc/config/i386/i386.md:1062
0x112fd4c split_insns(rtx_def*, rtx_insn*)
../../gcc/config/i386/i386.md:13105
0x79c5f2 try_split(rtx_def*, rtx_insn*, int)
../../gcc/emit-rtl.c:3851
0x9f10f1 split_insn
../../gcc/recog.c:2901
0x9f5212 split_all_insns()
../../gcc/recog.c:3005
0x9f5318 execute
../../gcc/recog.c:3905
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/90546] [9.1 regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546 --- Comment #1 from Nick Krempel --- My interpretation of the standard didn't take into account the reference to http://eel.is/c++draft/over.match.ref when determining the type A. It says that A will be "lvalue reference to cv2 T2 ... where cv1 T is reference-compatible with cv2 T2". Here "cv1 T" is "const Foo". This seems to allows cv2 T2 to be either "Foo" or "const Foo", hence A can be either "Foo&" or "const Foo&". It's not clear which is supposed to be picked for use in the template argument deduction in that case! It seems it was expected for there to be a unique type from the wording: "... with the type that is required as the result of the conversion (call it A; ..." (note "*the* type", "call *it* A").
[Bug c++/90548] New: [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90548
Bug ID: 90548
Summary: [9/10 Regression] ICE in tsubst_copy_and_build, at
cp/pt.c:18877
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
This changed between 20190127 and 20190203 :
$ cat z1.cc
struct S { S (void ()); }
foo ([] (auto ...) {});
$ g++-9-20190127 -c z1.cc
$
$ g++-10-20190519 -c z1.cc
z1.cc: In instantiation of 'static decltype (((const*)0)->operator()(static_cast(__lambda0::_FUN::) ...))::_FUN(auto:1 ...) [with auto:1 = {}; decltype (((const*)0)->operator()(static_cast(__lambda0::_FUN::) ...)) = void]':
z1.cc:2:21: required from '::operator decltype
(((const*)0)->operator()(static_cast(__lambda0::_FUN::) ...)) (*)(auto:1 ...)()
const [with auto:1 = {}; decltype (((const*)0)->operator()(static_cast(__lambda0::_FUN::) ...)) = void]'
z1.cc:2:22: required from here
z1.cc:2:21: internal compiler error: Segmentation fault
2 | foo ([] (auto ...) {});
| ^
0xb8ae7f crash_signal
../../gcc/toplev.c:326
0x6dd614 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18877
0x6e6609 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18242
0x6e6609 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17918
0x6e557a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17034
0x6e6291 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17325
0x6e4764 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24755
0x6f9a0b instantiate_pending_templates(int)
../../gcc/cp/pt.c:24871
0x651755 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4819
[Bug middle-end/90549] New: missing -Wreturn-local-addr maybe returning an address of a local array plus offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90549
Bug ID: 90549
Summary: missing -Wreturn-local-addr maybe returning an address
of a local array plus offset
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
While testing the enhancement to -Wreturn-local-addr in PR 71924 I noticed that
of the following two cases only the first one is diagnosed but the second
equivalent case is not.
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-isolate-paths=/dev/stdout a.c
int a[2];
void* f (int i)
{
int b[2];
int *p = i ? &a[1] : &b[1];
return p;// -Wreturn-local-addr (good)
}
void* g (int i)
{
int b[2];
int *p = i ? a : b;
return p + 1;// missing -Wreturn-local-addr
}
;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=1)
a.c: In function ‘f’:
a.c:7:10: warning: function may return address of local variable
[-Wreturn-local-addr]
7 | return p;// -Wreturn-local-addr (good)
| ^
a.c:5:7: note: declared here
5 | int b[2];
| ^
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
iftmp.0_5 -> { iftmp.0_1 }
.MEM_6 -> { .MEM_4 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 2 ( 33%)
Removing basic block 3
f (int i)
{
int b[2];
int * iftmp.0_1;
int * iftmp.0_5;
[local count: 1073741824]:
if (i_2(D) == 0)
goto ; [0.00%]
else
goto ; [100.00%]
[local count: 536870912]:
# iftmp.0_1 = PHI <&a[1](2)>
b ={v} {CLOBBER};
return iftmp.0_1;
[count: 0]:
# iftmp.0_5 = PHI <&b[1](2)>
b ={v} {CLOBBER};
return 0B;
}
;; Function g (g, funcdef_no=1, decl_uid=1912, cgraph_uid=2, symbol_order=2)
g (int i)
{
int b[2];
int * iftmp.1_1;
void * _3;
[local count: 1073741824]:
if (i_2(D) == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
[local count: 1073741824]:
# iftmp.1_1 = PHI <&b(2), &a(3)>
_3 = iftmp.1_1 + 4;
b ={v} {CLOBBER};
return _3;
}
[Bug c++/90550] New: ICE in determine_visibility, at cp/decl2.c:2567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90550
Bug ID: 90550
Summary: ICE in determine_visibility, at cp/decl2.c:2567
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least gcc-4.5 :
$ cat z1.cc
template
void f ()
{
struct S { struct T typedef a; };
struct S::a b;
}
void g ()
{
f ();
}
$ g++-10-20190519 -c z1.cc
z1.cc: In instantiation of 'void f() [with = int]':
z1.cc:9:11: required from here
z1.cc:4:31: internal compiler error: Segmentation fault
4 | struct S { struct T typedef a; };
| ^
0xb8ae7f crash_signal
../../gcc/toplev.c:326
0x64da44 determine_visibility(tree_node*)
../../gcc/cp/decl2.c:2567
0x68d077 do_pushtag
../../gcc/cp/name-lookup.c:6944
0x68d077 pushtag(tree_node*, tree_node*, tag_scope)
../../gcc/cp/name-lookup.c:6956
0x6ef215 lookup_template_class_1
../../gcc/cp/pt.c:9555
0x6ef215 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:9769
0x6efa85 tsubst_aggr_type
../../gcc/cp/pt.c:12777
0x6eacc9 tsubst_decl
../../gcc/cp/pt.c:13768
0x6e0be7 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:14378
0x6e1ccb perform_typedefs_access_check
../../gcc/cp/pt.c:10942
0x6e42b3 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24743
0x6f9a0b instantiate_pending_templates(int)
../../gcc/cp/pt.c:24871
0x651755 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4819
[Bug c++/90546] [9.1 regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546 --- Comment #2 from Nick Krempel --- However it's also worth noting that if you take the original snippet and change the declaration of "test" to accept a const rvalue reference instead: "void test(const Foo&&);", then gcc 9.1 (and all other gcc and clang versions tested) agree that T = const Foo in that case. So even if the standard is ambiguous, gcc is still somewhat inconsistent.
[Bug c++/90548] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90548 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-20 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.2 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- commit 64e3499e2386103c6842ffdf0b8eeae1d3798d29 Author: jason Date: Wed Jan 30 02:43:04 2019 + PR c++/86943 - wrong code converting lambda to function pointer. In this PR, instantiating the static thunk returned from the generic lambda conversion function template was using normal overload resolution, which meant calling an extra constructor when forwarding its argument. Fixed by special-casing thunk calls significantly more. * lambda.c (maybe_add_lambda_conv_op): Use a template-id in the call. Only forward parms for decltype. * pt.c (tsubst_copy_and_build) [CALL_EXPR]: Handle CALL_FROM_THUNK_P specially. * typeck.c (check_return_expr): Don't mess with a thunk call. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@268377 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/90548] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90548 --- Comment #2 from Marek Polacek --- (gdb) p (*call_args).is_empty() $5 = true so tree arg = (*call_args)[i]; where i == 0 won't work.
