[Bug bootstrap/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318 --- Comment #1 from Brett Neumeier --- Created attachment 48594 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48594=edit preprocessed source
[Bug c++/95321] Run-time crash on valid destructor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95321
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> I don't think this is valid:
> BY the time operator delete gets called the deconstructor is called and
> therefor the object no longer exists therefor:
> void operator delete (void * ptr)
> {
> if (ptr != nullptr) static_cast(ptr)->Destroy();
> }
>
> Is invalid code as the vtable in ptr is no longer valid.
s/invalid/undefined/
[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 --- Comment #18 from Martin Liška --- @egallager: Why did you add 'deferred' keyword? I sent a patch for it to GCC patches mailing list.
[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318 --- Comment #5 from Andrew Pinski --- The assembler code works for me with binutils 2.33.1. So again which version of binutils are you using for the cross compiler?
[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95211 --- Comment #6 from David Binderman --- (In reply to Uroš Bizjak from comment #5) > This testcase is fixed by [1] > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546408.html Interesting. I've done quite a bit of cooperlake specific testing and found some bugs in gcc trunk. AFAIK cooperlake is recent Intel. Is there a newer -march setting I could usefully test or is cooperlake recent enough ? Also, AFAIK Zen version 2 is a recent AMD -march setting. Is there a newer AMD -march setting I could usefully test ? A complete compile of Fedora Linux, with about 6,700 packages, seems to be a good testcase for recent gcc trunk.
[Bug fortran/95323] New: ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95323 Bug ID: 95323 Summary: ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 48598 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48598=edit fortran source code For the attached Fortran code, recent gfortran trunk does this: $ gfortran -O2 -w -c local.f during GIMPLE pass: lim local.f:1:0: 1 | SUBROUTINE LOCAL(C,MDIM,NOCC,EIG) | internal compiler error: in compute_live_loop_exits, at tree-ssa-loop-manip.c:247 0xef51a9 compute_live_loop_exits(bitmap_head*, bitmap_head*, bitmap_head**, basic_block_def*) ../../trunk.git/gcc/tree-ssa-loop-manip.c:247 0xef51a9 add_exit_phis_var(tree_node*, bitmap_head*, bitmap_head**) ../../trunk.git/gcc/tree-ssa-loop-manip.c:334 0xef51a9 add_exit_phis(bitmap_head*, bitmap_head**, bitmap_head**) ../../trunk.git/gcc/tree-ssa-loop-manip.c:356 0xef51a9 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*) ../../trunk.git/gcc/tree-ssa-loop-manip.c:678 The bug first seems to occur sometime between 20200521 and 20200522
[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318 --- Comment #6 from Brett Neumeier --- The host binutils (used to compile the cross-toolchain): $ as --version GNU assembler (GNU Binutils) 2.34.0.20200507 Copyright (C) 2020 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-pc-linux-gnu'. The cross-binutils is: $ ./aarch64-cbl-linux-gnu-as --version GNU assembler (GNU Binutils) 2.34.0.20200517 Copyright (C) 2020 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `aarch64-cbl-linux-gnu'. So, pretty much the same, the cross-toolchain has more updates from the binutils 2.34 branch. I can try again with 2.33.1 and see if I get different results, if that would help?
[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053 --- Comment #8 from Segher Boessenkool --- I see no conversion there? But, why does it it store to memory at all?
[Bug c++/95317] New: [7 regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95317
Bug ID: 95317
Summary: [7 regression] ICE on valid C++14 code, in
tsubst_copy, at cp/pt.c:15649
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
ICE on valid C++14 code:
$ cat b.C
#include
template
struct num
{
enum { value = I };
};
#define VALUEOFNUM(x) std::remove_reference_t::value
template
void foo()
{
auto test = [&](auto i)
{
enum { VALUE = VALUEOFNUM(i) };
std::cout << VALUE;
};
test(num<0>());
test(num<1>());
}
int main()
{
foo();
}
$ g++-9 b.C
b.C: In instantiation of 'void foo() [with TYPE = void]':
b.C:27:15: required from here
b.C:18:22: internal compiler error: in tsubst_copy, at cp/pt.c:15649
18 | std::cout << VALUE;
| ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Works fine with GCC up to version 6, but regresses at 7 and later.
[Bug ipa/95320] [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95320 Tobias Burnus changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- Forgot to mention: That's still the cc1 compiler (libexec/gcc/x86_64-none-linux-gnu/11.0.0/cc1) not yet an offloading LTO. The problem seems to be the followingat ipa-utils.h:246: /* We do not have this information when not in LTO, but we do not need to care, since it is used only for type merging. */ gcc_checking_assert (in_lto_p || flag_lto); Here, we do not compile with LTO but write LTO for offloading. That code is called by local_tree_p which was added by r11-525-g03d90a20a1afcbb9c30da8d4adf4922b0685061f , Honza's "Avoid SCC hashing on unmergeable trees" patch of May 20, 2020.
[Bug c++/95321] Run-time crash on valid destructor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95321 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #3 from Francois-Xavier Coudert --- I don't have certainty it's not undefined behaviour, sorry. Closing.
[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318 --- Comment #8 from Andrew Pinski --- Note I think it is related to the fixes that was done for https://sourceware.org/bugzilla/show_bug.cgi?id=2 which was fixed in 2.34.
[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95089
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
Obvious fix:
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index b7712dc74d1..99844812505 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2836,9 +2836,10 @@ copy_derived_types:
&& (c->attr.allocatable || c->attr.pointer)
&& !derived->attr.is_class)
{
- char caf_name[GFC_MAX_SYMBOL_LEN];
+ /* Provide sufficient space to hold "_caf_symbol". */
+ char caf_name[GFC_MAX_SYMBOL_LEN + 6];
gfc_component *token;
- snprintf (caf_name, GFC_MAX_SYMBOL_LEN, "_caf_%s", c->name);
+ snprintf (caf_name, sizeof (caf_name), "_caf_%s", c->name);
token = gfc_find_component (derived, caf_name, true, true, NULL);
gcc_assert (token);
c->caf_token = token->backend_decl;
[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252 Jim Wilson changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-25 Status|UNCONFIRMED |NEW --- Comment #1 from Jim Wilson --- It appears to be failing in the rename register (rnreg) pass. This is because the unspec patterns for the save/restore calls don't mention the registers that they use/modify. This confuses rename reg into thinking that live regs are dead, and it accidentally clobbers them before the save call. This worked OK when save/restore calls could only be at the beginning or end of a function. But now that this works with tail calls and shrink wrapping, we can get them in inner blocks. Since the different save/restore calls use/modify different sets of registers, fixing this gets a little complicated. Maybe we can just use the max list of registers because listing extra ones shouldn't matter? Another solution is to disable the rename register pass when -msave-restore is used. This isn't doing any checking for whether regs can be used in compressed instructions or not. This is currently encoded in REG_ALLOC_ORDER which this pass doesn't use. The result is that this is probably increasing code size which is undesirable when -msave-restore it used. Disabling this would reduce code size and fix the -msave-restore problem. The rename register pass does use the PREFERRED_RENAME_CLASS hook that we haven't defined. We should try defining this to convert registers classes to subsets that only include the regs that can be used in compressed instructions. This might result in a code size decrease. If this works, then the rename reg pass should not be disabled, and we should find a way to fix the save/restore pattern register lists instead. I need to do some builds and experiments to verify this info.
[Bug c++/90212] [8 Regression] by-ref capture of constexpr class object rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212 Jason Merrill changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8 Regression] by-ref |by-ref capture of constexpr |capture of constexpr class |class object rejected |object rejected --- Comment #5 from Jason Merrill --- Fixed for 9.4/10.2/11. Is this important to fix in GCC 8?
[Bug fortran/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95323 --- Comment #2 from David Binderman --- Created attachment 48599 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48599=edit Fortran header file
[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95089 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-05-25 Priority|P3 |P4 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|ICE in |[Coarray] ICE in |gfc_get_derived_type, at|gfc_get_derived_type, at |fortran/trans-types.c:2843 |fortran/trans-types.c:2843 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- All versions from 7 to 11 (master) ICE. Confirmed.
[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95089 --- Comment #3 from anlauf at gcc dot gnu.org --- Patch submmitted for review: https://gcc.gnu.org/pipermail/fortran/2020-May/054385.html
[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318 Brett Neumeier changed: What|Removed |Added Resolution|--- |INVALID CC||bneumeier at gmail dot com Status|WAITING |RESOLVED --- Comment #9 from Brett Neumeier --- Confirmed, the issue does not occur with 2.33.1. Thank you for your attention and help!
[Bug c++/90212] [8/9/10/11 Regression] by-ref capture of constexpr class object rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0296697cf9893dc9509cdcd8e3fd4ba9fe422527 commit r9-8623-g0296697cf9893dc9509cdcd8e3fd4ba9fe422527 Author: Jason Merrill Date: Mon May 25 18:38:09 2020 -0400 c++: constexpr and lambda capture [PR90212] This is the same issue as PR86429, just in potential_constant_expression_1 rather than cxx_eval_constant_expression. As in that case, when we're trying to evaluate a constant expression within a lambda, we don't have a constant closure object to refer to, but we can try to refer directly to the captured variable. gcc/cp/ChangeLog 2020-05-05 Jason Merrill PR c++/90212 * constexpr.c (potential_constant_expression_1): In a lambda function, consider a captured variable directly.
[Bug target/90479] gcc-arm-none-eabi-8-2018-q4-major [c99 plus -pg not working]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90479 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e153e0ef3a35c2c72e8bf89bd905fe27f8877852 commit r9-8622-ge153e0ef3a35c2c72e8bf89bd905fe27f8877852 Author: Jason Merrill Date: Mon May 25 18:38:09 2020 -0400 c++: Local class DMI using local static [PR90479] For default member initializers in templates it's important to push into the right context during get_nsdmi. But for a local class that's not possible, and trying leaves the function context we need to be in, so don't try. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/90479 * init.c (get_nsdmi): Don't push_to_top_level for a local class.
[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93822 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:91664c43c0acf56fd86643530e4b0be78a06446c commit r9-8620-g91664c43c0acf56fd86643530e4b0be78a06446c Author: Jason Merrill Date: Mon May 25 18:38:09 2020 -0400 c++: generic lambda and -fsanitize=vla-bound [PR93822] Within the generic lambda the VLA capture proxy VAR_DECL has DECL_VALUE_EXPR which is a NOP_EXPR to the VLA type of the proxy. The problem here was that when instantiating we were tsubsting that type twice, once for the type of the DECL and once for the type of the NOP_EXPR, and getting two different (though equivalent) types. Then gimplify_type_sizes fixed up the type of the DECL, but that didn't affect the type of the NOP_EXPR, leading to sadness. Fixed by directly reusing the type from the DECL. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/93822 * pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have the same type as the variable.
[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91529 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f76202e096fc0be4db21761399b55f10cd09b20d commit r9-8621-gf76202e096fc0be4db21761399b55f10cd09b20d Author: Jason Merrill Date: Mon May 25 18:38:09 2020 -0400 c++: -fmerge-all-constants vs. destructors [PR91529] cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that have non-constant construction or destruction, but -fmerge-all-constants was converting an automatic variable to static while leaving TREE_READONLY set. Fixed by clearing the flag in cp_finish_decl in the presence of -fmerge-all-constants. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/91529 * decl.c (cp_finish_decl): Also clear TREE_READONLY if -fmerge-all-constants.
[Bug c++/95222] [10/11 Regression] GCC 10.1 x86 issue with function pointers with calling convention attribute and template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95222 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93822 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed for 8.5/9.4/10.2/11.
[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 --- Comment #1 from bouanto at zoho dot com --- A similar error happens for the builtin "memcpy": error: unimplemented primitive type for builtin: 38
[Bug fortran/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95323 --- Comment #3 from David Binderman --- (In reply to anlauf from comment #1) > local.f90:3: Error: Can't open included file 'SIZES' > > Please include everything needed to reproduce. Done. > Are you sure this is a fortran bug, rather than tree-optimization? Not using -O2 makes the code compile, so something in the optimiser is going wrong, triggered by Fortran source code.
[Bug tree-optimization/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95323 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Component|fortran |tree-optimization Status|WAITING |NEW --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to David Binderman from comment #3) > (In reply to anlauf from comment #1) > > local.f90:3: Error: Can't open included file 'SIZES' > > > > Please include everything needed to reproduce. > > Done. > > > Are you sure this is a fortran bug, rather than tree-optimization? > > Not using -O2 makes the code compile, so something in the optimiser > is going wrong, triggered by Fortran source code. OK, using -O0, -Og, or -Os makes the code compile, -O1, -O2 or higher ICEs. This looks fishy. I'd prefer someone with better middle-end knowledge to look at it.
[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318 --- Comment #10 from Andrew Pinski --- (In reply to Brett Neumeier from comment #9) > Confirmed, the issue does not occur with 2.33.1. Thank you for your > attention and help! Please CC me on the binutils bug (just so I can keep track of it).
[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91529 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:09831707ce65606f951c97632d882f083ad3ed02 commit r8-10273-g09831707ce65606f951c97632d882f083ad3ed02 Author: Jason Merrill Date: Mon May 25 18:38:09 2020 -0400 c++: -fmerge-all-constants vs. destructors [PR91529] cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that have non-constant construction or destruction, but -fmerge-all-constants was converting an automatic variable to static while leaving TREE_READONLY set. Fixed by clearing the flag in cp_finish_decl in the presence of -fmerge-all-constants. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/91529 * decl.c (cp_finish_decl): Also clear TREE_READONLY if -fmerge-all-constants.
[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93822 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:487f16a7f2a6f849497a0d2f8fff61225e2270f6 commit r8-10272-g487f16a7f2a6f849497a0d2f8fff61225e2270f6 Author: Jason Merrill Date: Mon May 25 18:38:09 2020 -0400 c++: generic lambda and -fsanitize=vla-bound [PR93822] Within the generic lambda the VLA capture proxy VAR_DECL has DECL_VALUE_EXPR which is a NOP_EXPR to the VLA type of the proxy. The problem here was that when instantiating we were tsubsting that type twice, once for the type of the DECL and once for the type of the NOP_EXPR, and getting two different (though equivalent) types. Then gimplify_type_sizes fixed up the type of the DECL, but that didn't affect the type of the NOP_EXPR, leading to sadness. Fixed by directly reusing the type from the DECL. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/93822 * pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have the same type as the variable.
[Bug c++/90749] [8/9/10 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90749 --- Comment #4 from CVS Commits --- The releases/gcc-8 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:bc721725161c6ee3813870a734c0b0c18429a922 commit r8-10274-gbc721725161c6ee3813870a734c0b0c18429a922 Author: Jason Merrill Date: Mon May 25 18:38:09 2020 -0400 c++: Local class DMI using local static [PR90749] For default member initializers in templates it's important to push into the right context during get_nsdmi. But for a local class that's not possible, and trying leaves the function context we need to be in, so don't try. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/90749 * init.c (get_nsdmi): Don't push_to_top_level for a local class.
[Bug jit/95325] New: Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 Bug ID: 95325 Summary: Support 128-bit integers Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. Would it be possible to add support for 128-bit integers in libgccjit? Thanks.
[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318 --- Comment #7 from Andrew Pinski --- (In reply to Brett Neumeier from comment #6) > I can try again with 2.33.1 and see if I get different results, if that > would help? If it works with 2.33.1, can you report this directly to binutils: https://sourceware.org/bugzilla ? Since this is a bug in binutils as far as I can tell.
[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91529 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Fixed for 8.5/9.4/10.2/11.
[Bug c++/90749] [8/9/10 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90749 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jason Merrill --- Fixed for 8.5/9.4/10.2/11.
[Bug c++/95324] New: Segmentation fault when using variadic lambda template in concept definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95324
Bug ID: 95324
Summary: Segmentation fault when using variadic lambda template
in concept definition
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ivan.pogrebnyak at gmail dot com
Target Milestone: ---
Created attachment 48600
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48600=edit
gcc version, output, and -save-temps
Definition of the following concept (using C++20) causes segmentation fault in
GCC 10.1.0.
template
concept Applyable =
[](std::index_sequence) {
return std::is_invocable_v...>;
}(std::make_index_sequence>{});
Refactoring the definition into a `constexpr bool` and using it in the concept
definition works.
See the attachment for details.
[Bug fortran/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95323 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-25 Status|UNCONFIRMED |WAITING --- Comment #1 from anlauf at gcc dot gnu.org --- local.f90:3: Error: Can't open included file 'SIZES' Please include everything needed to reproduce. Are you sure this is a fortran bug, rather than tree-optimization?
[Bug c++/90212] [8/9/10/11 Regression] by-ref capture of constexpr class object rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:aa613a81831bdc044840a95a7a7803a235608503 commit r10-8183-gaa613a81831bdc044840a95a7a7803a235608503 Author: Jason Merrill Date: Mon May 25 18:04:39 2020 -0400 c++: constexpr and lambda capture [PR90212] This is the same issue as PR86429, just in potential_constant_expression_1 rather than cxx_eval_constant_expression. As in that case, when we're trying to evaluate a constant expression within a lambda, we don't have a constant closure object to refer to, but we can try to refer directly to the captured variable. gcc/cp/ChangeLog 2020-05-05 Jason Merrill PR c++/90212 * constexpr.c (potential_constant_expression_1): In a lambda function, consider a captured variable directly.
[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91529 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:01ff88c5619897198117b1a460d48774cfcdf396 commit r10-8181-g01ff88c5619897198117b1a460d48774cfcdf396 Author: Jason Merrill Date: Mon May 25 18:04:39 2020 -0400 c++: -fmerge-all-constants vs. destructors [PR91529] cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that have non-constant construction or destruction, but -fmerge-all-constants was converting an automatic variable to static while leaving TREE_READONLY set. Fixed by clearing the flag in cp_finish_decl in the presence of -fmerge-all-constants. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/91529 * decl.c (cp_finish_decl): Also clear TREE_READONLY if -fmerge-all-constants.
[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93822 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:4cee81365ad32ef947f500e4cf4b3514d88236c9 commit r10-8180-g4cee81365ad32ef947f500e4cf4b3514d88236c9 Author: Jason Merrill Date: Mon May 25 18:04:39 2020 -0400 c++: generic lambda and -fsanitize=vla-bound [PR93822] Within the generic lambda the VLA capture proxy VAR_DECL has DECL_VALUE_EXPR which is a NOP_EXPR to the VLA type of the proxy. The problem here was that when instantiating we were tsubsting that type twice, once for the type of the DECL and once for the type of the NOP_EXPR, and getting two different (though equivalent) types. Then gimplify_type_sizes fixed up the type of the DECL, but that didn't affect the type of the NOP_EXPR, leading to sadness. Fixed by directly reusing the type from the DECL. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/93822 * pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have the same type as the variable.
[Bug target/90479] gcc-arm-none-eabi-8-2018-q4-major [c99 plus -pg not working]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90479 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c79e664b153bd4cfdeec77b495d595e50b97c752 commit r10-8182-gc79e664b153bd4cfdeec77b495d595e50b97c752 Author: Jason Merrill Date: Mon May 25 18:04:39 2020 -0400 c++: Local class DMI using local static [PR90749] For default member initializers in templates it's important to push into the right context during get_nsdmi. But for a local class that's not possible, and trying leaves the function context we need to be in, so don't try. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/90479 * init.c (get_nsdmi): Don't push_to_top_level for a local class.
[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95211 --- Comment #7 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:9d0dc47de6ed9609fe7445ea0941a6a822c80f88 commit r11-621-g9d0dc47de6ed9609fe7445ea0941a6a822c80f88 Author: liuhongt Date: Tue May 26 11:14:31 2020 +0800 Fix non-comforming expander for floatv2div2sf2,floatunsv2div2sf2,fix_truncv2sfv2di,fixuns_truncv2sfv2di. 2020-05-26 Hongtao Liu Uroš Bizjak gcc/ChangeLog: PR target/95211 PR target/95256 * config/i386/sse.md (v2div2sf2): New expander. (fix_truncv2sfv2di2): Ditto. (avx512dq_floatv2div2sf2): Renaming from floatv2div2sf2. (avx512dq_fix_truncv2sfv2di2): Renaming from fix_truncv2sfv2di2. (vec_pack_float_): Adjust icode name. (vec_unpack_fix_trunc_lo_): Ditto. (vec_unpack_fix_trunc_hi_): Ditto. * config/i386/i386-builtin.def: Ditto. * emit-rtl.c (validate_subreg): Allow use of *paradoxical* vector subregs when both omode and imode are vector mode and have the same inner mode. gcc/testsuite/ChangeLog * gcc.target/i386/pr95211.c: New test.
[Bug target/95256] [11 Regression] ICE in convert_move, at expr.c:278 since r11-263-g7c355156aa20eaec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95256 --- Comment #4 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:9d0dc47de6ed9609fe7445ea0941a6a822c80f88 commit r11-621-g9d0dc47de6ed9609fe7445ea0941a6a822c80f88 Author: liuhongt Date: Tue May 26 11:14:31 2020 +0800 Fix non-comforming expander for floatv2div2sf2,floatunsv2div2sf2,fix_truncv2sfv2di,fixuns_truncv2sfv2di. 2020-05-26 Hongtao Liu Uroš Bizjak gcc/ChangeLog: PR target/95211 PR target/95256 * config/i386/sse.md (v2div2sf2): New expander. (fix_truncv2sfv2di2): Ditto. (avx512dq_floatv2div2sf2): Renaming from floatv2div2sf2. (avx512dq_fix_truncv2sfv2di2): Renaming from fix_truncv2sfv2di2. (vec_pack_float_): Adjust icode name. (vec_unpack_fix_trunc_lo_): Ditto. (vec_unpack_fix_trunc_hi_): Ditto. * config/i386/i386-builtin.def: Ditto. * emit-rtl.c (validate_subreg): Allow use of *paradoxical* vector subregs when both omode and imode are vector mode and have the same inner mode. gcc/testsuite/ChangeLog * gcc.target/i386/pr95211.c: New test.
[Bug c++/95326] New: UBsan can not detect signed-integer-overflow correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95326
Bug ID: 95326
Summary: UBsan can not detect signed-integer-overflow correctly
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This case example.cpp
#include
volatile wchar_t g_volatile_wchar = 2082494266;
volatile unsigned short g_volatile_ushort = 31503U;
int main () {
unsigned long l_var_ulong = 526562505494506029UL;
const wchar_t l_const_wchar = 1188246531;
g_volatile_ushort = l_var_ulong + l_const_wchar * g_volatile_wchar;
std::cout << "hello" << std::endl;
return 0;
}
can not detect signed-integer-overflow runtime error in gcc-trunk
$g++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
hello
But in clang-trunk
$clang++ -fsanitize=signed-integer-overflow test.cc ; ./a.out
example.cpp:9:53: runtime error: signed integer overflow: 1188246531 *
2082494266 cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior example.cpp:9:53 in
hello
godbolt clang-trunk : https://godbolt.org/z/s4-AqW
godbolt gcc-trunk : https://godbolt.org/z/k7NhG6
[Bug c++/95326] GCC can not detect signed-integer-overflow correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95326
Haoxin Tu changed:
What|Removed |Added
Version|11.0|10.0
--- Comment #1 from Haoxin Tu ---
I also found another case example.cpp
#include
unsigned short g_var_ushort = 52781U;
const unsigned int g_const_uint = 2331271054U;
int main () {
//test_function();
short l_var_short = -14674;
volatile unsigned char l_volatile_uchar = 151U;
long l_var_long = 572469544701421587L;
g_var_ushort = l_volatile_uchar - l_var_short % g_const_uint * l_var_long;
std::cout << "hello" << std::endl;
return 0;
}
$g++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
hello
$clang++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
example.cpp:12:66: runtime error: signed integer overflow: 1963681568 *
572469544701421587 cannot be represented in type 'long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior example.cpp:12:66 in
hello
My g++ version is
$g++ --version
g++ (GCC) 10.0.1 20200420 (experimental)
Copyright (C) 2020 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.
I have tested all GCC versions including GCC-8, GCC-9, GCC-10, and GCC-Trunk in
Godbolt, they can not detect this UB as well.
