[Bug c++/90947] [9 Regression] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Thu Oct 31 07:10:57 2019 New Revision: 277656 URL: https://gcc.gnu.org/viewcvs?rev=277656&root=gcc&view=rev Log: PR c++/90947 * tree.h (type_initializer_zero_p): Remove. * tree.c (type_initializer_zero_p): Remove. cp/ * cp-tree.h (type_initializer_zero_p): Declare. * decl.c (reshape_init_array_1): Formatting fix. * tree.c (type_initializer_zero_p): New function. Moved from ../tree.c, use next_initializable_field, formatting fix. Return false for TYPE_NON_AGGREGATE_CLASS types. Added: trunk/gcc/testsuite/g++.dg/init/array54.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/tree.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 gnzlbg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from gnzlbg --- > Note that the situation for zero-sized structs isn't very clear in most ABIs, these included. This is incorrect: zero-sized types are well-defined and efficient on most ABIs (most ABIs have a rule for small sizes, and these rules cover zero-sized types). AFAICT, these two (MSP430 and PPC32) are some of the very few ABIs in which zero-sized types waste one register and one instruction for no reason. > You must have an unusual program if this ever matters ;-) This bug / question was spawned due to a PR that attempted to fix a bug in Rust for these ABIs when zero-sized types are involved. Rust has first-class support for ZSTs and they are widely used, so the unusual situation where this happens is essentially "all Rust programs". While ZSTs are "free" on most ABIs, on these particular two, the ABI spec does not cover them, making "what GCC does" essentially the only documented behavior for these. Hence the question, is wasting one register and one instruction for ZSTs on these platforms a GCC bug, or part of the intended ABI for these? It appears that the answer is that this is intended: these ABIs always pass structs and unions indirectly, even if they are zero-sized, and that just means that a register and an instruction must be used when ZSTs are passed, even if those registers will never be read by anything. These ABIs know about this and find it an acceptable trade-off, so that's what Rust will do.
[Bug libstdc++/92300] New: Useless allocator call in std::map, when insert does not perform any insertion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300 Bug ID: 92300 Summary: Useless allocator call in std::map, when insert does not perform any insertion. Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: antonio.di.monaco at sap dot com Target Milestone: --- Created attachment 47142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47142&action=edit code example The fix related to the bug 78595 introduced a regression in the std::map insert call. When a key already exists, an allocation is performed anyway. std::map< int, int, std::less< int >, MyAlloc< std::pair< const int, int > > > a; assert(a.insert(std::make_pair(1, 1)).second); assert(a.insert(std::make_pair(2, 2)).second); assert(!a.insert(std::make_pair(1, 3)).second); GCC 6: map: allocate 1 element(s) of size 40 allocated at: 0x13d8c20 allocate 1 element(s) of size 40 allocated at: 0x13d8c50 GCC >= 7.4.0: map: allocate 1 element(s) of size 40 allocated at: 0x14f1c20 allocate 1 element(s) of size 40 allocated at: 0x14f1c50 allocate 1 element(s) of size 40 allocated at: 0x14f1c80 Other associative containers have not been affected by the change.
[Bug bootstrap/92301] New: bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301 Bug ID: 92301 Summary: bootstrap internal compiler error: Aborted free(): invalid next size (fast) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jan at jki dot io Target Milestone: --- gcc bootstrapped with -O3 seems to be broken at the moment. flags are: "-march=skylake -g1 -O2" latest trunk If I compile with -O2 it works COLLECT_GCC_OPTIONS='-B' '/var/tmp/portage/sys-devel/gcc-10.0.0_pre/work/build/./gcc/' '-B' '/usr/x86_64-pc-linux-gnu/bin/' '-B' '/usr/x86_64-pc-linux-gnu/lib/' '-isystem' '/usr/ /var/tmp/portage/sys-devel/gcc-10.0.0_pre/work/build/./gcc/cc1 -fpreprocessed conftest.i -quiet -dumpbase conftest.c -march=skylake -auxbase conftest -g -g1 -O2 -O3 -version -fn GNU C17 (Gentoo 10.0.0_pre) version 10.0.0-pre 20191031 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 10.0.0-pre 20191031 (experimental), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C17 (Gentoo 10.0.0_pre) version 10.0.0-pre 20191031 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 10.0.0-pre 20191031 (experimental), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: fa416f315144141f16c1f6d6e3d5dca9 free(): invalid next size (fast) during RTL pass: ree conftest.c: In function 'main': conftest.c:16:1: internal compiler error: Aborted 16 | } | ^ 0x7fa14496770f ??? /var/tmp/portage/sys-libs/glibc-2.30/work/glibc-2.30/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x7fa14496766a __GI_raise ../sysdeps/unix/sysv/linux/raise.c:51 0x7fa14491855b __GI_abort /var/tmp/portage/sys-libs/glibc-2.30/work/glibc-2.30/stdlib/abort.c:79 0x7fa1449a682c __libc_message ../sysdeps/posix/libc_fatal.c:181 0x7fa1449ae519 malloc_printerr /var/tmp/portage/sys-libs/glibc-2.30/work/glibc-2.30/malloc/malloc.c:5341 0x7fa144939c20 _int_free /var/tmp/portage/sys-libs/glibc-2.30/work/glibc-2.30/malloc/malloc.c:4252 0x7fa144939c20 __GI___libc_free /var/tmp/portage/sys-libs/glibc-2.30/work/glibc-2.30/malloc/malloc.c:3127 0x7fa1449495eb __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug libstdc++/78595] Unnecessary copies in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78595 Antonio Di Monaco changed: What|Removed |Added CC||antonio.di.monaco at sap dot com --- Comment #18 from Antonio Di Monaco --- This change introduced a regression in the allocator calls. I've created a new bug for it: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300
[Bug tree-optimization/14799] [tree-ssa] convert a sequence of "if"s to a "switch" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14799 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- I'm working on the optimization.
[Bug target/92295] Inefficient vector constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92295
--- Comment #1 from Hongtao.liu ---
Created attachment 47143
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47143&action=edit
This patch can fix this issue
In ix86_expand_vector_init_concat, vector are initialized per 2 elements,
that's why it failed to generate vpbroadcast, any purpose of this code???
--
13784 /* FIXME: We process inputs backward to help RA. PR 36222. */
13785 i = n - 1;
13786 j = (n >> 1) - 1;
13787 for (; i > 0; i -= 2, j--)
13788{
13789 first[j] = gen_reg_rtx (cmode);
13790 v = gen_rtvec (2, ops[i - 1], ops[i]);
13791 ix86_expand_vector_init (false, first[j],
13792 gen_rtx_PARALLEL (cmode, v));
13793}
13794
13795 n >>= 1;
13796 if (n > 4)
it can be implemented like
---
13776 /* FIXME: We process inputs backward to help RA. PR 36222. */
13777 i = n - 1;
13778 for (j = 1; j != -1; j--)
13779{
13780 half[j] = gen_reg_rtx (half_mode);
13781 switch (n >> 1)
13782{
13783case 2:
13784 v = gen_rtvec (2, ops[i-1], ops[i]);
13785 i -= 2;
13786 break;
13787case 4:
13788 v = gen_rtvec (4, ops[i-3], ops[i-2], ops[i-1], ops[i]);
13789 i -= 4;
13790 break;
13791case 8:
13792 v = gen_rtvec (8, ops[i-7], ops[i-6], ops[i-5], ops[i-4],
13793 ops[i-3], ops[i-2], ops[i-1], ops[i]);
13794 i -= 8;
13795 break;
13796default:
13797 gcc_unreachable ();
13798}
13799 ix86_expand_vector_init (false, half[j],
13800 gen_rtx_PARALLEL (half_mode, v));
13801}
13802
13803 ix86_expand_vector_init_concat (mode, target, half, 2);
13804 break;
---
Bootstrap and regression test is ok.
[Bug ipa/88702] [7/8/9/10 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-31 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|7.5 |8.5 Ever confirmed|0 |1
[Bug middle-end/92231] [9/10 Regression] ICE in gimple_fold_stmt_to_constant_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92231 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Oct 31 10:04:47 2019 New Revision: 277660 URL: https://gcc.gnu.org/viewcvs?rev=277660&root=gcc&view=rev Log: PR middle-end/92231 * tree.h (fndecl_built_in_p): Use fndecl_built_in_p instead of DECL_BUILT_IN in comment. Remove redundant ()s around return argument. * tree.c (free_lang_data_in_decl): Check if var is FUNCTION_DECL before calling fndecl_built_in_p. * gimple-fold.c (gimple_fold_stmt_to_constant_1): Check if TREE_OPERAND (fn, 0) is a FUNCTION_DECL before calling fndecl_built_in_p on it. lto/ * lto-lang.c (handle_const_attribute): Don't call fndecl_built_in_p on *node that is not FUNCTION_DECL. testsuite/ * gcc.c-torture/compile/pr92231.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr92231.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-lang.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h
[Bug fortran/92277] [10 Regression] ICE with assumed rank in gfc_conv_gfc_desc_to_cfi_desc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92277 --- Comment #2 from Tobias Burnus --- Author: burnus Date: Thu Oct 31 10:06:19 2019 New Revision: 277661 URL: https://gcc.gnu.org/viewcvs?rev=277661&root=gcc&view=rev Log: Fortran] PR92277 - Fix assumed-rank array with bind(C) gcc/fortran/ PR fortran/92277 * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Fix DECL_ARTIFICIAL checking. gcc/testsuite/ PR fortran/92277 * fortran.dg/pr92277.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pr92277.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 --- Comment #6 from Tobias Burnus --- Author: burnus Date: Thu Oct 31 10:12:55 2019 New Revision: 277663 URL: https://gcc.gnu.org/viewcvs?rev=277663&root=gcc&view=rev Log: Fortran] PR92284 – gfc_desc_to_cfi_desc fixes gcc/fortran/ PR fortran/92284. * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Free CFI descriptor at the end; partial revised revert of Rev. 277502. libgfortran/ PR fortran/92284. * runtime/ISO_Fortran_binding.c (gfc_desc_to_cfi_desc): gcc/testsuite/ PR fortran/92284. * gfortran.dg/bind-c-intent-out.f90: Update expected dump; extend comment. * gfortran.dg/bind_c_array_params_3.f90: New. * gfortran.dg/bind_c_array_params_3_aux.c: New. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_array_params_3.f90 trunk/gcc/testsuite/gfortran.dg/bind_c_array_params_3_aux.c Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bind-c-intent-out.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/ISO_Fortran_binding.c
[Bug middle-end/92231] [9 Regression] ICE in gimple_fold_stmt_to_constant_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92231 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |gimple_fold_stmt_to_constan |gimple_fold_stmt_to_constan |t_1 |t_1 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/91272] [SVE] Use fully-masked loops for CLASTB reductions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91272 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug libstdc++/92300] Useless allocator call in std::map, when insert does not perform any insertion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-31 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- make_pair(1, 2) creates a std::pair which is not the same type as the value_type. That means there's a conversion from pair to pair, which gets done by allocating a node, constructing the value_type into the node, then checking if the key exists. That's the expected behaviour when inserting something that is not the same type as the value_type, so I don't think this is a bug. We could special-case pair to avoid that step, because we can use the non-const key directly. Converting it to a const key isn't needed to check if it exists. In fact we could special-case pair. Confirming as an enhancement request.
[Bug bootstrap/92301] bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-31 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I see the problem as well with a bit different back-trace. I'll work on that.
[Bug bootstrap/92301] bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug c/92296] [10 Regression] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek ---
This actually isn't specific to __has_builtin, any of the following builtin
macros ICE when used in #pragma push_macro ("MACRO"):
__TIMESTAMP__
__TIME__
__DATE__
__FILE__
__BASE_FILE__
__LINE__
__INCLUDE_LEVEL__
__COUNTER__
__has_attribute
__has_cpp_attribute
__has_builtin
_Pragma
Surprisingly __STDC__ builtin macro doesn't ICE.
I guess the ICE started with r164729.
[Bug libstdc++/92300] Useless allocator call in std::map, when insert does not perform any insertion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300 --- Comment #2 from Antonio Di Monaco --- Well, I tried, but nothing changes. assert(a.insert(std::make_pair< const int, int >(1, 1)).second); assert(a.insert(std::make_pair< const int, int >(2, 2)).second); assert(!a.insert(std::make_pair< const int, int >(1, 3)).second); still allocates three times, while GCC6 two times. Even changing K to const int in the map does not produce any different behavior.
[Bug rtl-optimization/92281] Inconsistent canonicalization of (minus (minus A B) C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281 --- Comment #2 from Richard Earnshaw --- (In reply to Segher Boessenkool from comment #1) > (In reply to Richard Earnshaw from comment #0) > > > Failed to match this instruction: > > (set (reg:SI 125 [+4 ]) > > (minus:SI (minus:SI (reg:SI 127) > > (reg:SI 121 [ b+4 ])) > > (ltu:SI (reg:CC 100 cc) > > (const_int 0 [0] > > > (set (reg:SI 125 [+4 ]) > > (minus:SI (minus:SI (reg:SI 127) > > (reg:SI 121 [ b+4 ])) > > (ltu:SI (reg:CC 100 cc) > > (const_int 0 [0] > > That is > > (set D (minus (minus A B) (X C 0))) > > > Successfully matched this instruction: > > (set (reg:SI 125 [+4 ]) > > (minus:SI (minus:SI (reg:SI 119 [ a+4 ]) > > (ltu:SI (reg:CC 100 cc) > > (const_int 0 [0]))) > > (reg:SI 129))) > > And this is > > (set D (minus (minus A (X C 0)) B)) > Yes, but since (A - B) - C = A - B - C = A - C - B = (A - C) - B we can clearly swap the order of the two RHS operands here. This would be a special rule similar to the rules that we have that rewrite A - (B + C) as (A - B) - C. My suggestion would be that we should have a rule here that re-orders things so that B is the most 'complex' operation and C the simplest, using the normal precedence ordering (complex > REG > CONST). > There are no rules for that afaics. > > > These are mathematically equivalent, but because we do not produce > > consistent RTL for them we need two patterns if we are to match both > > alternatives. > > Yes; the same is true for quite a few other unusual combinations. Or > not even so very unusual: > (ior (ashift X N) (lshiftrt Y M)) > vs. > (ior (lshiftrt Y M) (ashift X N)) > is one nasty example, but also reg+reg+reg where one of the regs is > "special" can appear in multiple forms. > > > I think both should be canonicalized with the LTU inside the inner MINUS > > expression, but I wouldn't mind if the other were chosen, as long as we were > > consistent. > > What would the rule become? See suggestion above. I think we might also have a rule that within 'complex' the ordering might be by RTX code number, but that's somewhat arbitrary; thought it is likely to be fairly stable. It would produce a strict canonical ordering for your IOR case above, however. > What targets would it break, and how? Hard to tell, until we try it. Mostly the 'breakage' would be some combine patterns might no-longer match if the target only had one and the ordering were not canonical (leading to some missed optimizations). On targets that have both orderings, some patterns might become redundant and never match unless directly generated by the back-end. > > What makes combine come up with something else for these two cases? Sorry, I don't understand what you're asking here? Why does it produce these two separate canoncializations in one compilation? I've no idea, hence the bug report.
[Bug rtl-optimization/92281] Inconsistent canonicalization of (minus (minus A B) C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281 --- Comment #3 from Richard Earnshaw --- As for 'special' regs and their ordering, I'm not sure. I would suggest that if we have a commutative operation with two registers and one of the registers is marked as a pointer, then it should appear first. But other than that, I don't have any other suggestions here.
[Bug c++/83732] wrong warning about non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732 --- Comment #7 from Jonathan Wakely --- (In reply to Kenman Tsang from comment #6) > Sorry for bring this topic back again. That's OK, the bug is still open. > But I think there are some > inconsistancy with the std::is_pod and the error messages. Yes, that's what I said in comment 1 and comment 3. > Refers to my example. A1 is a POD, but the error message said it is > "non-POD". Should we either include more detail to the message (like C++98 > POD) or to relax the POD checking? See comment 4. > I tried the same case with clang. clang successfully compiles and return the > correct size. And I cannot found anyway to unify their behavior, hence I > cannot have a compiler independent code base Using the non-standard packed attribute already makes the code non-portable.
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 --- Comment #11 from Jonathan Wakely --- Yes those tests exercise some weird, contrived corner cases. I messed some up and will fix them (and remove my workaround for this bug - thanks!)
[Bug libstdc++/92300] Useless allocator call in std::map, when insert does not perform any insertion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300 --- Comment #3 from Jonathan Wakely --- (In reply to Antonio Di Monaco from comment #2) > Well, I tried, but nothing changes. > > assert(a.insert(std::make_pair< const int, int >(1, 1)).second); > assert(a.insert(std::make_pair< const int, int >(2, 2)).second); > assert(!a.insert(std::make_pair< const int, int >(1, 3)).second); > > still allocates three times, while GCC6 two times. Because make_pair(1, 2) still returns pair, so you're still not inserting the value_type. (Using make_pair with an explicit template argument list is dumb, the whole point is to deduce the argument types so if you specify the types there's no deduction and no point using make_pair.) > Even changing K to const int in the map does not produce any different > behavior. Because that doesn't change anything either. The value type is still pair either way, and you're still inserting pair. This inserts the correct value type, and doesn't perform an addition allocation: assert(a.insert(std::pair(1, 1)).second); assert(a.insert(std::pair(2, 2)).second); assert(!a.insert(std::pair(1, 3)).second);
[Bug c++/83732] wrong warning about non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732 --- Comment #8 from Stas Sergeev --- (In reply to Jonathan Wakely from comment #7) > Using the non-standard packed attribute already makes the code non-portable. It may be non-standard, but its still portable as long as all compilers agree on implementing the particular extension. And the "packed" extension is AFAIK the very old one and most widely used. Unsupporting it is far from good decision. Non-standard things should not be automatically treated as "non-portable" IMO. Kenman Tsang: This bug was initially not about the wrong object size. It was about the wrong diagnostic that says "ignoring packed attribute" but actually packs an object perfectly well. Your example demonstrates the case where the "packed" attribute is really ignored (and the diagnostic is in line with that), so this is a different problem. For which I opened another ticket: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84194 You may want to join that ticket, leaving this one just for the diagnostic problem.
[Bug preprocessor/92296] [10 Regression] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-31 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #10 from Jakub Jelinek --- Created attachment 47144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47144&action=edit gcc10-pr92296.patch Untested fix.
[Bug c++/84194] fails to pack structs with template members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84194
Kenman Tsang changed:
What|Removed |Added
CC||kentsangkm at gmail dot com
--- Comment #1 from Kenman Tsang ---
Hi, here is another example that the GCC cannot pack a struct correctly.
Refers to the ticket 83732
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732), this is not only related
to the diagnostic message, but how we pack POD.
Because the A1 is not a C++98 pod ( but it is a POD according to C++11 ), B1
should be able to process the pack (and the result should be sizeof(B1) == 10)
Compared with Clang-4.0 or above, clang can pack this structure correctly
>From the ticket 83732, my best guess is gcc pack a struct only if it fulfill
C++98 pod, but not the pod in general
-
main.cpp:34:8: warning: ignoring packed attribute because of unpacked non-POD
field ‘A1 B1::b’
A1 b;
^
main.cpp:39:1: error: static assertion failed
static_assert(sizeof(B1) == 10, "");
^
-
#include
struct A1
{
A1() = default;
constexpr A1(const int& value) noexcept
: value(value)
{
}
constexpr A1(int&& value) noexcept
: value(std::move(value))
{
}
int value;
};
static_assert(std::is_pod::value,"Pass");
static_assert(sizeof(A1)==4, "Pass");
struct A2
{
A2() = default;
int value;
};
static_assert(std::is_pod::value,"Pass");
static_assert(sizeof(A2)==4, "Pass");
struct B1
{
char a;
A1 b;
char c;
int d;
} __attribute__((__packed__));
static_assert(std::is_pod::value,"Pass");
static_assert(sizeof(B1)==10, "This is failed");
struct B2
{
char a;
A2 b;
char c;
int d;
} __attribute__((__packed__));
static_assert(std::is_pod::value,"Pass");
static_assert(sizeof(B2)==10, "Pass");
int main()
{
std::cout << sizeof(A1) << std::endl;
std::cout << sizeof(A2) << std::endl;
}
[Bug c++/92297] The expression 0 / X is simplified to 0 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297 Luca Rocca changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Luca Rocca --- Division by 0 is always undefined, regardless of the numerator. So, 0 / X should not be simplified if we cannot exclude that X = 0. Then if X = 0 we should expect an exception triggered at runtime, as we have for example for 1 / 0. Consider the relevant section of the file gcc-9.2.0/gcc/match.pd: /* 0 / X is always zero. */ (simplify (div integer_zerop@0 @1) /* But not for 0 / 0 so that we can get the proper warnings and errors. */ (if (!integer_zerop (@1)) @0)) It seems that the intention is in fact to perform the simplification except for the case 0 / 0, but for some reason this is not implemented correctly. Consider also for comparison the approach of GCC up to gcc-6.4.0, reading this comment from the corresponding file gcc-6.4.0/gcc/match.pd: /* Make sure to preserve divisions by zero. This is the reason why we don't simplify x / x to 1 or 0 / x to 0. */ For the same code, GCC up to 6.4.0 does not perform the simplification and when X = 0 we have an exception raised at runtime as expected
[Bug c++/92299] The expression X / abs (X) is simplified to 1 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299 Luca Rocca changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Luca Rocca --- Division by 0 is always undefined, regardless of the numerator. So, 0 / X should not be simplified if we cannot exclude that X = 0. Then if X = 0 we should expect an exception triggered at runtime, as we have for example for 1 / 0. Consider for comparison the approach of gcc up to gcc-6.4.0, reading this comment from the corresponding file gcc-6.4.0/gcc/match.pd: /* Make sure to preserve divisions by zero. This is the reason why we don't simplify x / x to 1 or 0 / x to 0. */
[Bug c++/92298] The expression X / X is simplified to 1 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92298
Luca Rocca changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #2 from Luca Rocca ---
Division by 0 is always undefined, regardless of the numerator.
So, X / X should not be simplified if we cannot exclude that X = 0.
Then if X = 0 we should expect an exception triggered at runtime,
as we have for example for 1 / 0.
Consider the relevant section of the file gcc-9.2.0/gcc/match.pd:
/* X / X is one. */
(simplify
(div @0 @0)
/* But not for 0 / 0 so that we can get the proper warnings and errors.
And not for _Fract types where we can't build 1. */
(if (!integer_zerop (@0) && !ALL_FRACT_MODE_P (TYPE_MODE (type)))
{ build_one_cst (type); }))
It seems that the intention is in fact to perform the simplification
except for the case 0 / 0, but for some reason this is not implemented
correctly.
Consider also for comparison the approach of gcc up to gcc-6.4.0,
reading this comment from the corresponding file gcc-6.4.0/gcc/match.pd:
/* Make sure to preserve divisions by zero. This is the reason why
we don't simplify x / x to 1 or 0 / x to 0. */
For the same code, GCC up to 6.4.0 does not perform the simplification and when
X = 0 we have an exception raised at runtime as expected
[Bug c++/92297] The expression 0 / X is simplified to 0 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- (In reply to Luca Rocca from comment #2) > Division by 0 is always undefined, regardless of the numerator. > So, 0 / X should not be simplified if we cannot exclude that X = 0. No. You don't need to exclude X=0 because if X=0 the behaviour is undefined and so any result is valid (including the result of simplifying it). > Then if X = 0 we should expect an exception triggered at runtime, > as we have for example for 1 / 0. No, that's not what undefined behaviour means. You are wrong to expect a runtime error, that would be *defined* behaviour.
[Bug c++/92298] The expression X / X is simplified to 1 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92298 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- See what I wrote in Bug 92297 comment 3 *** This bug has been marked as a duplicate of bug 92297 ***
[Bug c++/92297] The expression 0 / X is simplified to 0 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297 --- Comment #4 from Jonathan Wakely --- *** Bug 92298 has been marked as a duplicate of this bug. ***
[Bug c++/92299] The expression X / abs (X) is simplified to 1 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- See what I wrote in Bug 92297 comment 3 *** This bug has been marked as a duplicate of bug 92297 ***
[Bug c++/92297] The expression 0 / X is simplified to 0 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297 --- Comment #5 from Jonathan Wakely --- *** Bug 92299 has been marked as a duplicate of this bug. ***
[Bug c++/92297] The expression 0 / X is simplified to 0 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297 --- Comment #6 from Jonathan Wakely --- (In reply to Luca Rocca from comment #2) > Consider also for comparison the approach of GCC up to gcc-6.4.0, > reading this comment from the corresponding file gcc-6.4.0/gcc/match.pd: > > /* Make sure to preserve divisions by zero. This is the reason why >we don't simplify x / x to 1 or 0 / x to 0. */ > > For the same code, GCC up to 6.4.0 does not perform the simplification and > when > X = 0 we have an exception raised at runtime as expected And that was changed intentionally by r242636. The code is undefined, so GCC is not required to always compile it the same way.
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Thu Oct 31 13:17:48 2019 New Revision: 277667 URL: https://gcc.gnu.org/viewcvs?rev=277667&root=gcc&view=rev Log: Remove PR 92268 workaround and fix new test failures With the compiler bug fixed we can simplify the __sizable concept to use a return-type-requirement again. I also realised it was redundantly re-checking a subset of the sized_sentinel_for requirements. The compiler fix also revealed bugs in two tests which started to fail and are fixed by this patch. * include/bits/range_access.h (__sizable): Rename to __sentinel_size. Remove workaround for PR c++/92268 and remove redundant requirements that are already checked by sized_sentinel_for. * testsuite/std/ranges/access/cend.cc: Fix failures. * testsuite/std/ranges/access/end.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/range_access.h trunk/libstdc++-v3/testsuite/std/ranges/access/cend.cc trunk/libstdc++-v3/testsuite/std/ranges/access/end.cc
[Bug target/92302] New: [10 regression] gcc.target/sparc/sparc-ret-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302 Bug ID: 92302 Summary: [10 regression] gcc.target/sparc/sparc-ret-3.c FAILs Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org, rsandifo at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-solaris2.11 Between 20190930 (r276306) and 20191001 (r276415), the gcc.target/sparc/sparc-ret-3.c test regressed on Solaris/SPARC: +FAIL: gcc.target/sparc/sparc-ret-3.c scan-assembler ld[ \\t]*[%i5+8], %i0\\n[^\\n]*return[ \\t]*%i7+8 The only difference in the assembler output is --- /var/gcc/regression/gcc-9-branch/11.5-gcc/build/gcc/testsuite/gcc/sparc-ret-3.s 2019-10-31 14:15:19.895733250 + +++ sparc-ret-3.s 2019-10-31 14:14:57.673941380 + @@ -20,7 +20,7 @@ mov %i1, %o1 callcrypto_shash_update, 0 mov%i5, %o0 - ld [%i5+8], %i0 + ld [%sp+104], %i0 return %i7+8 nop .size bug, .-bug This might well be related to 2019-10-01 Richard Sandiford gcc/ * regs.h (HARD_REGNO_CALLER_SAVE_MODE): Update call to choose_hard_reg_mode. * config/sparc/sparc.h (HARD_REGNO_CALLER_SAVE_MODE): Likewise.
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #2 from Andrew Sutton --- This is tricky because the condition reduces to true/false before the static assertion evaluates it. We could introduce a new binary expression that stores the original expression and it's computed value, and use that to hook into diagnostics from the static assert.
[Bug target/92302] [10 regression] gcc.target/sparc/sparc-ret-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug target/92303] New: [10 regression] gcc.target/sparc/ultrasp12.c times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303 Bug ID: 92303 Summary: [10 regression] gcc.target/sparc/ultrasp12.c times out Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-solaris2.11 Between 20190626 (r272695) and 20190627 (r272755), gcc.target/sparc/ultrasp12.c compilation began to time out on Solaris/SPARC: +WARNING: gcc.target/sparc/ultrasp12.c (test for excess errors) program timed out. +FAIL: gcc.target/sparc/ultrasp12.c (test for excess errors) With the 7.1.0/8.1.0/9.1.0 release compilers, the testcase compiles in about 1 sec. The timeout also happens on the gcc-8 and gcc-9 branches now. Maybe due to different checking options? Checking the running cc1 with pstack shows it running somewhere in LRA: 0093c0d4 update_lives(int, bool) (131, 0, 1717088, 1a08898, 607c, 4d3) + b4 (lra-assigns.c:393) 00940b4c lra_assign(bool&) (17170a8, 1715800, 274b, 16f3414, 7260, 131) + 310c (lra-assigns.c:1160) 0093a9dc lra(__FILE*) (1715800, 16f0800, 1751cd0, 17170d4, 16e1e80, 17159f0) + 6d4 (lra.c:2482) 008ec2f4 (anonymous namespace)::pass_reload::execute(function*) (178f820, fa8b6000, 16dac00, 1747800, 16dac00, 16f0800) + e0 (ira.c:5511) 00940b4c lra_assign(bool&) (17170a8, 1715800, 274b, 16f3414, 7260, 131) + 310c (lra-assigns.c:1160) 0093a9dc lra(__FILE*) (1715800, 16f0800, 1751cd0, 17170d4, 16e1e80, 17159f0) + ro@colima 89 > pstack 28239|gc++filt 28239: ./cc1 -fpreprocessed ultrasp12.i -mptr64 -mstack-bias -mno-v8plus -qui 0095ad4c lra_create_live_ranges_1(bool, bool) (fa2ac8e8, 0, 2cdee14, 2d1e62, fa8c09c0, 1) + 678 (lra-int.h:483) 0095d738 lra_create_live_ranges(bool, bool) (1, 0, 2d3ba0, 789f, 0, 1718000) + 8 (lra-lives.c:1446) 0093a964 lra(__FILE*) (1715800, 16f0800, 1751cd0, 17170d4, 16e1e80, 17159f0) + 65c (lra.c:2471) 00956608 update_reg_eliminate(bitmap_head*) [clone .constprop.0] (0, 1, 0, 16e1e80, 1715800, fa1d8528) + 75c (rtl.h:882) 009587c8 lra_eliminate(bool, bool) (0, 0, fa8c09c0, 1747800, fa8c09c0, 1717400) + 38c (lra-eliminations.c:1357) 0093a930 lra(__FILE*) (1715800, 16f0800, 1751cd0, 17170d4, 16e1e80, 1) + 628 (lra.c:2441)
[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug ipa/92304] New: [10 regression] r277615 causes ICE compiling gcc.target/powerpc/p9-splat-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92304 Bug ID: 92304 Summary: [10 regression] r277615 causes ICE compiling gcc.target/powerpc/p9-splat-1.c Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- on LE only Executing on host: /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/p9-splat-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -mdejagnu-cpu=power9 -O2 -ffat-lto-objects -fno-ident -S -o p9-splat-1.s(timeout = 300) 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/p9-splat-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -mdejagnu-cpu=power9 -O2 -ffat-lto-objects -fno-ident -S -o p9-splat-1.s during IPA pass: icf /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-splat-1.c: In function 'foo_r2': /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-splat-1.c:23:1: internal compiler error: in verify_hash_value, at fold-const.c:3864 0x1061713f operand_compare::verify_hash_value(tree_node const*, tree_node const*, unsigned int, bool*) /home/seurer/gcc/gcc-test/gcc/fold-const.c:3864 0x1164608f ipa_icf_gimple::func_checker::operand_equal_p(tree_node const*, tree_node const*, unsigned int) /home/seurer/gcc/gcc-test/gcc/ipa-icf-gimple.c:406 0x11641883 ipa_icf_gimple::func_checker::compare_operand(tree_node*, tree_node*) /home/seurer/gcc/gcc-test/gcc/ipa-icf-gimple.c:472 0x11641a2b ipa_icf_gimple::func_checker::compare_memory_operand(tree_node*, tree_node*) /home/seurer/gcc/gcc-test/gcc/ipa-icf-gimple.c:321 0x11642a3f ipa_icf_gimple::func_checker::compare_gimple_assign(gimple*, gimple*) /home/seurer/gcc/gcc-test/gcc/ipa-icf-gimple.c:791 0x116455af ipa_icf_gimple::func_checker::compare_bb(ipa_icf_gimple::sem_bb*, ipa_icf_gimple::sem_bb*) /home/seurer/gcc/gcc-test/gcc/ipa-icf-gimple.c:638 0x1163d9ff ipa_icf::sem_function::equals_private(ipa_icf::sem_item*) /home/seurer/gcc/gcc-test/gcc/ipa-icf.c:883 0x1163de3b ipa_icf::sem_function::equals(ipa_icf::sem_item*, hash_map, ipa_icf::sem_item*> >&) /home/seurer/gcc/gcc-test/gcc/ipa-icf.c:806 0x1162cccf ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool) /home/seurer/gcc/gcc-test/gcc/ipa-icf.c:2813 0x1163e4e3 ipa_icf::sem_item_optimizer::execute() /home/seurer/gcc/gcc-test/gcc/ipa-icf.c:2582 0x1164040f ipa_icf_driver /home/seurer/gcc/gcc-test/gcc/ipa-icf.c:3679 0x1164040f ipa_icf::pass_ipa_icf::execute(function*) /home/seurer/gcc/gcc-test/gcc/ipa-icf.c:3726 r277615 | marxin | 2019-10-30 07:01:25 -0500 (Wed, 30 Oct 2019) | 14 lines Integrate that for IPA ICF. 2019-10-30 Martin Liska * ipa-icf-gimple.c (func_checker::hash_operand): New. (func_checker::compare_cst_or_decl): Remove handling of FIELD_DECL. (func_checker::compare_operand): Transform to ... (func_checker::operand_equal_p): ... this. * ipa-icf-gimple.h (class func_checker): Add operand_equal_p and hash_operand. * ipa-icf.c (sem_function::equals_private): Fix pushing and popping of cfun.
[Bug ipa/92304] [10 regression] r277615 causes ICE compiling gcc.target/powerpc/p9-splat-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92304 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-31 Known to work||9.2.0 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Mine.
[Bug libstdc++/88322] Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322 Bug 88322 depends on bug 89022, which changed state. Bug 89022 Summary: Implement P0202R3 - C++20 Constexpr Modifiers to Functions in and Headers. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/89022] Implement P0202R3 - C++20 Constexpr Modifiers to Functions in and Headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022 emsr at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from emsr at gcc dot gnu.org --- We can declare victory on this one.
[Bug libstdc++/88339] Implement P0515R3, C++20 three-way comparison operator support .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88339 --- Comment #2 from emsr at gcc dot gnu.org --- -// std::initializer_list support -*- C++ -*- +// Three-way comparison support -*- C++ -*-
[Bug libstdc++/88339] Implement P0515R3, C++20 three-way comparison operator support .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88339 --- Comment #3 from Jonathan Wakely --- Yeah, I already noticed that :-) I have some more changes locally too.
[Bug c/77328] incorrect caret location in -Wformat calling printf via a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77328 --- Comment #5 from Martin Sebor --- The GCC 10 output looks almost correct. I think two things should change: 1) the warning should underline the directive (like the second note), not the whole format string 2) the second note should be dropped when it's on the same line as the warning 77328.c:9:8: warning: format '%i' expects argument of type 'int', but argument 4 has type 'double' [-Wformat=] 9 | P (d, "%i %i", 1, 2.0); |^~~ ~~~ || |double 77328.c:5:45: note: in definition of macro 'P' 5 | #define P(d, f, a, b) __builtin_sprintf (d, f, a, b) | ^ 77328.c:9:13: note: format string is defined here 9 | P (d, "%i %i", 1, 2.0); |~^ | | | int |%f
[Bug target/92302] [10 regression] gcc.target/sparc/sparc-ret-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-31 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Then change looks benign and I'm skeptical about the purported cause.
[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-31 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- In my experience, LRA is getting slower and slower since GCC 8.
[Bug c++/92297] The expression 0 / X is simplified to 0 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297 --- Comment #7 from Andrew Pinski --- > Then if X = 0 we should expect an exception triggered at runtime, as we have > for example for 1 / 0. No undefined does not mean trap at runtime, it means anything can happen ...
[Bug ipa/92304] [10 regression] r277615 causes ICE compiling gcc.target/powerpc/p9-splat-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92304 --- Comment #2 from Martin Liška --- I've got a patch candidate.
[Bug libgomp/92305] New: [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92305 Bug ID: 92305 Summary: [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.fortran/use_device_addr-1.f90 -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs/ -O0 -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs/ -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -lgfortran -foffload=-lgfortran -lquadmath -lm -o ./use_device_addr-1.exe PASS: libgomp.fortran/use_device_addr-1.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs:.:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64 Execution timeout is: 300 spawn [open ...] STOP 1 FAIL: libgomp.fortran/use_device_addr-1.f90 -O0 execution test
[Bug bootstrap/92301] bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||rguenth at gcc dot gnu.org --- Comment #2 from Martin Liška --- If I see correctly, it's caused by r277566.
[Bug bootstrap/92301] bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92305
--- Comment #1 from Tobias Burnus ---
Technically, this patch only adds '{ dg-do run }' which has the effect that the
code is not only run once but multiple times with different compiler options
(-O1, -O2 etc.).
Your code fails to execute with -O0 and a timeout of 300 (seconds, I guess,
which is then 5min). – I think your system does not do any offloading to a GPU.
Hence, it would be a host-only run.
It runs here with -O0 in 0.620s and compiles in 2.194s (cold run, re-run:
1.062s). And that's while bootstapping GCC in parallel on this laptop.
As you could nail it down to a single commit, I assume, you could reproduce the
problem – still, I am completely lost why it fails for you at -O0. Can you try
to debug it a bit more?
[Bug bootstrap/92301] bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301 --- Comment #3 from Martin Liška --- One can reproduce that by using df-scan.o from stage2 and libgcc ICEs with -g.
[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92305 --- Comment #2 from Tobias Burnus --- (In reply to Tobias Burnus from comment #1) > As you could nail it down to a single commit, I assume, you could reproduce > the problem – still, I am completely lost why it fails for you at -O0. Can > you try to debug it a bit more? Was mislead by the time out message. When updating the patch (changing abort to stop), I missed to enumerate the stops through, hence, there is more than one 'stop 1'. Can you pin-point it to a certain stop/fail, e.g. by running it in the debugger? [I will update the test to have disjunct stop numbers.] [Still, as the patch only added 'dg-do run', it still does not explain why it worked before and fails now.]
[Bug bootstrap/92301] bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301
--- Comment #4 from Martin Liška ---
Created attachment 47145
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47145&action=edit
Reproduce patch
Ok, steps to reproduce that:
1) install latest GCC trunk and use it as compiler
2) apply the patch
3) build df-scan.o with -O3 -march=skylake
4) echo 'int foo() {}' | ./xgcc -B. -x c -g -O2 -
during RTL pass: stv
: In function ‘foo’:
:1:1: internal compiler error: in df_reorganize_refs_by_reg_by_reg, at
df-scan.c:1350
0x620205 df_reorganize_refs_by_reg_by_reg
/home/marxin/Programming/gcc/gcc/df-scan.c:1350
0x9cbac4 df_reorganize_refs_by_reg
/home/marxin/Programming/gcc/gcc/df-scan.c:1563
0x9cbac4 df_maybe_reorganize_def_refs(df_ref_order)
/home/marxin/Programming/gcc/gcc/df-scan.c:1717
0x9c077f df_rd_local_compute
/home/marxin/Programming/gcc/gcc/df-problems.c:401
0x9ba6a1 df_analyze_problem(dataflow*, bitmap_head*, int*, int)
/home/marxin/Programming/gcc/gcc/df-core.c:1170
0x9ba799 df_analyze_1
/home/marxin/Programming/gcc/gcc/df-core.c:1227
0x1160cfa convert_scalars_to_vector
/home/marxin/Programming/gcc/gcc/config/i386/i386-features.c:1621
0x1160cfa execute
/home/marxin/Programming/gcc/gcc/config/i386/i386-features.c:1909
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug bootstrap/92301] bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301 --- Comment #5 from Martin Liška --- > 3) build df-scan.o with -O3 -march=skylake same happens for -march=haswell.
[Bug preprocessor/92306] New: stringize linux cut off the word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92306 Bug ID: 92306 Summary: stringize linux cut off the word Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: amarchini at kcftech dot com Target Milestone: --- Created attachment 47146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47146&action=edit this is the file used to test the pre-processor While setting up defines for various folders I found that the preprocessor will truncate the word linux . I am enclosing two files from the following the gcc command line. gcc -E exp.c | grep -v ^# > preprocessed.c gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1) Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix
[Bug preprocessor/92306] stringize linux cut off the word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92306 --- Comment #1 from A Guy --- Created attachment 47147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47147&action=edit this is the pre processed output
[Bug ipa/92304] [10 regression] r277615 causes ICE compiling gcc.target/powerpc/p9-splat-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92304 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Liška --- Patch candidate: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02232.html
[Bug preprocessor/92306] stringize linux cut off the word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92306 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- linux is a predefined macro. If you don't want it, you can use -std=c99 or -std=c11 which will then not define the macro in the non-implementation identifier space
[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91930 Hannes Hauswedell changed: What|Removed |Added CC||h2+bugs at fsfe dot org --- Comment #5 from Hannes Hauswedell --- Created attachment 47148 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47148&action=edit intermediate code I am still seeing: /home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/iterator/basic_iterator.hpp:463:23: internal compiler error: in lazily_declare_fn, at cp/method.c:2372 463 | Cur>::readable_iterator_associated_types_base; | ^~~ in the snapshot from 20191027. Was the fix merged later or is my issue different? Intermediate code is attached. Build with -std=c++17 -fconcepts Thank you for your help!
[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91930 --- Comment #6 from Hannes Hauswedell --- I can confirm that my problem is not fixed by the patch from this PR. Do you want me to open a new issue or will this be reopened?
[Bug bootstrap/92301] bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301 --- Comment #6 from Martin Liška --- Easier way how to bisect that is to use only these dbg-cnt options: -O3 -march=haswell -fdbg-cnt=vect_slp:0 -fdbg-cnt=vect_loop:3 which is first bad, vect_loop:2 is fine.
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055
--- Comment #5 from Georg-Johann Lay ---
Created attachment 47149
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47149&action=edit
double64-6.diff: Support --with-double={|32|64|32,64|64,32}
--with-long-double={|32|64|32,64|64,32,double}
gcc/
Support 64-bit double and 64-bit long double configurations.
PR target/92055
* config.gcc (tm_defines) [avr]: Set from --with-double=,
--with-long-double=.
* config/avr/t-multilib: Remove.
* config/avr/t-avr: Output of genmultilib.awk is now fully
dynamically generated and no more part of the repo.
(HAVE_DOUBLE_MULTILIB, HAVE_LONG_DOUBLE_MULTILIB): New variables.
Pass them down to...
* config/avr/genmultilib.awk: ...here and handle them.
* gcc/config/avr/avr.opt (-mdouble=, avr_double). New option and var.
(-mlong-double=, avr_long_double). New option and var.
* common/config/avr/avr-common.c (opts.h): Include.
(diagnostic.h): Include.
(TARGET_OPTION_OPTIMIZATION_TABLE) <-mdouble=>: Set default as
requested by --with-double=.
<-mlong-double=>: Set default as requested by --with-long-double=.
(TARGET_OPTION_OPTIMIZATION_TABLE) <-mdouble=, -mlong-double=>:
Set default as requested by --with-double=
(TARGET_HANDLE_OPTION): Define to this...
(avr_handle_option): ...new hook worker.
* config/avr/avr.h (DOUBLE_TYPE_SIZE): Define to avr_double.
(LONG_DOUBLE_TYPE_SIZE): Define to avr_long_double.
(avr_double_lib): New proto for spec function.
(EXTRA_SPEC_FUNCTIONS) : Add.
(DRIVER_SELF_SPECS): Call %:double-lib.
* config/avr/avr.c (avr_option_override): Assert
sizeof(long double) >= sizeof(double) for the target.
* config/avr/avr-c.c (avr_cpu_cpp_builtins)
[__HAVE_DOUBLE_MULTILIB__, __HAVE_LONG_DOUBLE_MULTILIB__]
[__HAVE_DOUBLE64__, __HAVE_DOUBLE32__, __DEFAULT_DOUBLE__=]
[__HAVE_LONG_DOUBLE64__, __HAVE_LONG_DOUBLE32__]
[__HAVE_LONG_DOUBLE_IS_DOUBLE__, __DEFAULT_LONG_DOUBLE__=]:
New built-in defined depending on --with-double=, --with-long-double=.
* config/avr/driver-avr.c (avr_double_lib): New spec function.
* doc/invoke.tex (AVR Options) <-mdouble=,-mlong-double=>: Doc.
libgcc/
Support 64-bit double and 64-bit long double configurations.
PR target/92055
* config/avr/t-avr (HOST_LIBGCC2_CFLAGS): Only add -DF=SF if
long double is a 32-bit type.
* config/avr/t-avrlibc: Copy double64 and long-double64
multilib(s) from the vanilla one.
* config/avr/t-copy-libgcc: New Makefile snip.
[Bug bootstrap/81883] bootstrap-lto build fails with undefined reference to `_Unwind_Resume'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81883 JD changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from JD --- I ran into the same issue for 9.2 and realized that the build succeeds if -flto is not specified in CFLAGS and CXXFLAGS. So when letting the build throw that flag only when needed lets it succeed.
[Bug bootstrap/81883] bootstrap-lto build fails with undefined reference to `_Unwind_Resume'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81883 --- Comment #3 from JD --- and using --with-build-config=bootstrap-lto
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 89427, which changed state. Bug 89427 Summary: missing -Warray-bounds on a MEM_REF of array plus offset https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89427 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/89427] missing -Warray-bounds on a MEM_REF of array plus offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89427
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|tree-optimization |middle-end
Known to work||10.0
Resolution|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Target Milestone|--- |10.0
Known to fail||7.3.0, 8.3.0, 9.2.0
--- Comment #2 from Martin Sebor ---
This is now diagnosed thanks to r273783 as follows:
$ cat pr89427.c && gcc -O2 -S -Wall pr89427.c
char a[8];
void f (int i)
{
char *p = a + sizeof a;
if (i < 5)
i = 5;
p[i] = 0; // missing -Warray-bounds
}
pr89427.c: In function ‘f’:
pr89427.c:8:8: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
8 | p[i] = 0; // missing -Warray-bounds
| ~^~~
pr89427.c:1:6: note: destination object declared here
1 | char a[8];
| ^
[Bug middle-end/92307] New: missing -Wstringop-overflow on a memcpy into an array with out-of-bounds variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92307
Bug ID: 92307
Summary: missing -Wstringop-overflow on a memcpy into an array
with out-of-bounds variable 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: ---
Even with PR89427 resolved, GCC still fails to detect the invalid accesses in
the functions below (_FORTIFY_SOURCE doesn't help because it doesn't try to
detect sizes from pointers involving variable offsets):
$ cat x.c && gcc -O2 -S -Wall x.c
char a[2];
void f (int i, const char *s)
{
if (i < 1 || 2 < i) i = 1;
char *p = &a[i] - 9;
__builtin_memcpy (p, s, 2); // writing before the beginning of a
}
void g (int i, const char *s)
{
if (i < 1 || 2 < i) i = 1;
char *p = &a[i] + 9;
__builtin_memcpy (p, s, 2); // writing past the end of a
}
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Thu Oct 31 16:37:55 2019 New Revision: 277679 URL: https://gcc.gnu.org/viewcvs?rev=277679&root=gcc&view=rev Log: PR fortran/92284 * gfortran.dg/bind_c_array_params_3_aux.c: Include ../../../libgfortran/ISO_Fortran_binding.h rather than ISO_Fortran_binding.h. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bind_c_array_params_3_aux.c
[Bug lto/66029] Build error compiling gcc5.1 using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029 JD changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #12 from JD --- Use --with-build-config=bootstrap-lto and to not include -flto flag in CFLAGS and CXXFLAGS (and LDFLAGS). The build succeeds for gcc 9.2.0
[Bug lto/66029] Build error compiling gcc5.1 using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029 --- Comment #13 from postmas...@trippelsdorf-de.bounceio.net --- Your email was bounced... - ... because something went wrong between you and your recipient. Ugh! What to do next? Well, your specific problem was a *5.1.2 * error. Which means you should: Check the "trippelsdorf.de" part of "mar...@trippelsdorf.de" for misspellings or missing letters. If you find an error, correct it in your contacts list or address book for next time. Or further: It is possible that the domain is temporarily inactive. If the spelling looks correct, contact your mail provider and if necessary, contact your recipient another way (e.g., phone or text message). Get more Bounce Intelligence ™ on 5.1.2 errors here![1] Thanks, have a lovely day. Yours truly, betterbounces.net[2] Rate this email: Helpful[3] :) or... Not Helpful[4] :( Advertisement | Prefer no ads?[5] YOU MIGHT LIKE [6] [7] [8] Learn more about RevenueStripe...[9] - © 2017 betterbounces.net, All rights reserved. Privacy[10] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] 1. https://www.betterbounces.net/email-error/5.1.2?utm_source=7o9&utm_medium=direct&utm_campaign=trippelsdorf.de&utm_content=SeretV2 2. http://bit.ly/1AqkgOr 3. https://www.surveygizmo.com/s3/1609211/rtm01?tv=SeretV2&esc=5.1.2&t=ED7B2D27-9A1E-4018-BE61-EB6A1EF9AB63.1&s=7o9&r=Helpful 4. https://www.surveygizmo.com/s3/1609211/rtm01?tv=SeretV2&esc=5.1.2&t=ED7B2D27-9A1E-4018-BE61-EB6A1EF9AB63.1&s=7o9&r=Not%20helpful 5. https://betterbounces.net/b/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7titT91WI150sPs4r2y2APILF5Fb_KY7JnWSvrTPQ_RLqzm5WLiQf9amSPLQH7QgR6_a6RIlCfV._Xhvwqy2q.z9dQ00NXL0mSalBv3xSACPwVCv3jHytkmh263ygxAzj 6. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac&cs_sendid=1572539947393&cs_esp=threatwave&cs_offset=0&cs_stripeid=2454 7. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac&cs_sendid=1572539947393&cs_esp=threatwave&cs_offset=1&cs_stripeid=2454 8. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac&cs_sendid=1572539947393&cs_esp=threatwave&cs_offset=2&cs_stripeid=2454 9. http://branding.rs-1117-a.com/?utm_source=contentstripe&utm_medium=email&utm_campaign=rs_2454&utm_content=animatedlogo 10. https://www.betterbounces.net/privacy-policy
[Bug lto/66029] Build error compiling gcc5.1 using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029 --- Comment #14 from postmas...@trippelsdorf-de.bounceio.net --- Created attachment 47151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47151&action=edit attachment-104715-1.eml
[Bug bootstrap/92301] bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301
--- Comment #7 from Martin Liška ---
Even easier, use the following self-contained test-case:
$ cat /tmp/vect.c
unsigned int m;
struct df_reg_info
{
unsigned int n_regs;
};
#define N 128
struct df_reg_info a[N];
unsigned int
__attribute__((noipa))
df_count_refs (bool include_defs)
{
unsigned int regno;
int size = 0;
for (regno = 0; regno < m; regno++)
{
if (include_defs)
size += a[regno].n_regs;
}
return size;
}
int main(int argc, char **argv)
{
for (unsigned i = 0; i < N; i++)
{
a[i].n_regs = i;
}
if (argc == 1)
m = 17;
unsigned int r = df_count_refs(true);
__builtin_printf ("r: %d\n", r);
if (r != 136)
__builtin_abort ();
return 0;
}
$ marxin@marxinbox:/dev/shm/objdir/gcc> g++ /tmp/vect.c -march=haswell -O0 &&
./a.out
r: 136
marxin@marxinbox:/dev/shm/objdir/gcc> g++ /tmp/vect.c -march=haswell -O3 &&
./a.out
r: 17
Aborted (core dumped)
[Bug middle-end/92307] missing -Wstringop-overflow on a memcpy into an array with out-of-bounds variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92307 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-31 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89427 Blocks||88443 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I'm testing a patch that diagnoses this. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug bootstrap/92301] bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301
--- Comment #8 from Martin Liška ---
Simplified a bit more:
$ cat /tmp/vect.c
unsigned int m;
#define N 128
unsigned int a[N];
unsigned int
__attribute__((noipa))
df_count_refs (bool include_defs)
{
int size = 0;
for (unsigned int regno = 0; regno < m; regno++)
if (include_defs)
size += a[regno];
return size;
}
int main(int argc, char **argv)
{
for (unsigned i = 0; i < N; i++)
a[i] = i;
if (argc == 1)
m = 17;
unsigned int r = df_count_refs(true);
__builtin_printf ("r: %d\n", r);
if (r != 136)
__builtin_abort ();
return 0;
}
$ g++ /tmp/vect.c -march=haswell -O3 && ./a.out
r: 17
Aborted (core dumped)
[Bug middle-end/92308] New: Gimple passes could do a better job of forming address CSEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92308
Bug ID: 92308
Summary: Gimple passes could do a better job of forming address
CSEs
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Consider this testcase which was mentioned in
https://gcc.gnu.org/ml/gcc-help/2019-10/msg00122.html.
#define BB_ADDRESS 0x43fe1800
void test1(void) {
volatile uint32_t * const p = (uint32_t *) BB_ADDRESS;
p[3] = 1;
p[4] = 2;
p[1] = 3;
p[7] = 4;
p[0] = 6;
}
The gimple generated for this is
test1 ()
{
;; basic block 2, loop depth 0
;;pred: ENTRY
MEM[(volatile uint32_t *)1140725772B] ={v} 1;
MEM[(volatile uint32_t *)1140725776B] ={v} 2;
MEM[(volatile uint32_t *)1140725764B] ={v} 3;
MEM[(volatile uint32_t *)1140725788B] ={v} 4;
MEM[(volatile uint32_t *)1140725760B] ={v} 6;
return;
;;succ: EXIT
}
However, it's very unlikely on any RISC type architecture that addresses of
this form will be valid. The TARGET_LEGITIMIZE_ADDRESS hook can help here, but
that has to guess how to split the address and it has no idea what, for each
call, the best base that should be chosen. In this case the best base is
likely to be the lowest addressed object in the sequence, so that all other
objects can use a small positive offset from that.
The GIMPLE passes have a much broader view on the code being optimized, so
forming a common base for all these addresses should be straight forward and
much more likely to lead to better code than having to use a heuristic in the
back-end.
[Bug rtl-optimization/92294] alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 --- Comment #1 from Richard Earnshaw --- Things go wrong in the forward-prop 1 pass.
[Bug preprocessor/92296] [10 Regression] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Thu Oct 31 17:38:44 2019 New Revision: 277685 URL: https://gcc.gnu.org/viewcvs?rev=277685&root=gcc&view=rev Log: PR preprocessor/92296 * internal.h (struct def_pragma_macro): Add is_builtin bitfield. (_cpp_restore_special_builtin): Declare. * init.c (_cpp_restore_special_builtin): New function. * directives.c (do_pragma_push_macro): For NT_BUILTIN_MACRO set is_builtin and don't try to grab definition. (cpp_pop_definition): Use _cpp_restore_special_builtin to restore builtin macros. * c-c++-common/cpp/pr92296-1.c: New test. * c-c++-common/cpp/pr92296-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/cpp/pr92296-1.c trunk/gcc/testsuite/c-c++-common/cpp/pr92296-2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/init.c trunk/libcpp/internal.h
[Bug preprocessor/92296] [7/8/9 Regression] internal compiler error: Segmentation fault #pragma push_macro("__LINE__")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|10.0|7.5
Summary|[10 Regression] GCC build |[7/8/9 Regression] internal
|ICE on MinGW-w64. internal |compiler error:
|compiler error: |Segmentation fault #pragma
|Segmentation fault #pragma |push_macro("__LINE__")
|push_macro("__has_builtin") |
--- Comment #12 from Jakub Jelinek ---
Fixed on the trunk, keeping open for backports to release branches (where we'll
need to leave out the __has_builtin part of the testcase obviously).
[Bug rtl-optimization/92294] alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 Wilco changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-31 Ever confirmed|0 |1 --- Comment #2 from Wilco --- Confirmed then
[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92305 --- Comment #3 from seurer at gcc dot gnu.org --- There are 222 stops in there. Is there an easy way I can catch any of them that fire? Just running in gdb shows this spawns a bunch of threads and it looks like one of them is what is stopping.
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 --- Comment #8 from Segher Boessenkool --- (In reply to gnzlbg from comment #7) > > Note that the situation for zero-sized structs isn't very clear in > > most ABIs, these included. > > This is incorrect: zero-sized types are well-defined and efficient on most > ABIs (most ABIs have a rule for small sizes, and these rules cover > zero-sized types). I don't agree that is true. Besides, that is not what I said: a lot of documentation is less than clear on behaviour here (certainly not for older systems, where you *cannot* have zero-sized arguments in any case!) So your de-facto ABI becomes what some popular implementation does. And if you are unlucky you end up with two or more conflicting implementations. > AFAICT, these two (MSP430 and PPC32) are some of the very > few ABIs in which zero-sized types waste one register and one instruction > for no reason. sparc is another, for example. And or1k, too.
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 --- Comment #9 from gnzlbg --- > sparc is another, for example. And or1k, too. Yeah, I was wrong. x86/x64, arm32/64, aarch64, riscv, ppc64, mips64, ... are some of the ABIs that do not have any of these issues because they special case "all aggregates smaller than X", and that covers zero-sized types. Some ABIs (e.g. ppc32, MSP430) just say that all aggregates are passed by reference, period. And some ABIs (s390x, sparc as well I think), special case some sizes (e.g. 1, 2, 4, and 8 bytes wide aggregates), which means that 0 byte wide aggregates end up being passed by reference instead. --- @josef > The MSP430 ABI is here: http://www.ti.com/lit/an/slaa534/slaa534.pdf Although confusingly that document is wrong regarding passing structures and unions by reference. As I mentioned before, structures and unions are always passed by reference, regardless of size. Can you expand on this? That document says that aggregates smaller than 32-bit are passed in registers. We were trying to update our code documentation to cite the ABI specs and realized this. Do you have a link to where the current behavior is specified?
[Bug d/92309] New: Assignment to anonymous union member corrupts sibling members in struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92309
Bug ID: 92309
Summary: Assignment to anonymous union member corrupts sibling
members in struct
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: sahmi.soulaimane at gmail dot com
Target Milestone: ---
Test case
```
union U
{
struct
{
size_t a;
size_t b;
union
{
size_t c;
size_t d;
}
}
}
void main()
{
U u;
assert(u.a == 0); // ok
u.d = 1;
assert(u.a == 0); // error
}
```
[Bug testsuite/92310] New: New test case gcc.dg/vect/vect-epilogues.c introduced in r277659 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92310 Bug ID: 92310 Summary: New test case gcc.dg/vect/vect-epilogues.c introduced in r277659 fails Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect-epilogues.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -maltivec -mpower8-vector -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o vect-epilogues.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect-epilogues.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -maltivec -mpower8-vector -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o vect-epilogues.s PASS: gcc.dg/vect/vect-epilogues.c (test for excess errors) FAIL: gcc.dg/vect/vect-epilogues.c scan-tree-dump vect "LOOP EPILOGUE VECTORIZED" Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect-epilogues.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -flto -ffat-lto-objects -maltivec -mpower8-vector -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o vect-epilogues.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect-epilogues.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -flto -ffat-lto-objects -maltivec -mpower8-vector -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o vect-epilogues.s PASS: gcc.dg/vect/vect-epilogues.c -flto -ffat-lto-objects (test for excess errors) FAIL: gcc.dg/vect/vect-epilogues.c -flto -ffat-lto-objects scan-tree-dump vect "LOOP EPILOGUE VECTORIZED" testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect.exp completed in 1 seconds === gcc Summary === # of expected passes2 # of unexpected failures2
[Bug fortran/92311] New: Fortran and OpenMP use_device_ptr and OpenACC attach_ptr/dettach_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92311 Bug ID: 92311 Summary: Fortran and OpenMP use_device_ptr and OpenACC attach_ptr/dettach_ptr Product: gcc Version: 9.2.0 Status: UNCONFIRMED Keywords: openacc, openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: naromero at anl dot gov CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86-64 westmere Target: NVidia GPU Build: x86_64-pc-linux-gnu Created attachment 47152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47152&action=edit Test OpenMP use_device_ptr and OpenACC dettach/attach I attach a simple isolated reproducer that reproduces the issue from a more complicated scientific code. The attached file contains both an OpenACC and OpenMP version of the same program. The OpenACC program build and runs correctly with the latest PGI Fortran compiler. The OpenMP program also builds and runs with the latest IBM XL Fortran compiler. The bug is against the frontend of the Fortran compiler that handles directives in both OpenACC and OpenMP for NVidia GPUs. Here is the compile-time error with -fopenmp: The error for the OpenMP is shown below: 29 |!$omp target data use_device_ptr(this_bin) | 1 Error: TARGET DATA must contain at least one MAP clause at (1) AFAIK, this is not a correct interpretation of the standard. You don't need a map clause here, use_device_ptr clause is enough. https://www.openmp.org/spec-html/5.0/openmpsu57.html#x83-2580002.12.2 For the OpenACC program, it may be that this is part of the OpenACC spec that has not been implemented yet. Here is the error with -fopenacc: test_openacc_attach.F90:27:9: 27 |!$acc enter data attach(this_bin) | 1 Error: Unclassifiable OpenACC directive at (1) test_openacc_attach.F90:46:9: 46 |!$acc exit data detach(this_bin) | 1 Error: Unclassifiable OpenACC directive at (1)
[Bug rtl-optimization/92281] Inconsistent canonicalization of (minus (minus A B) C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281 --- Comment #4 from Segher Boessenkool --- (In reply to Richard Earnshaw from comment #2) > Yes, but since > (A - B) - C = A - B - C = A - C - B = (A - C) - B > we can clearly swap the order of the two RHS operands here. My intent was to show the two rtx shapes, and that neither is a defined canonical form. > This would be > a special rule similar to the rules that we have that rewrite > A - (B + C) > as > (A - B) - C. That isn't a canonical form, either! Not according to the documentation, anyway. > My suggestion would be that we should have a rule here that re-orders things > so > that B is the most 'complex' operation and C the simplest, using the normal > precedence ordering (complex > REG > CONST). But minus isn't commutative, and reordering with minus introduces negs which is wrong (it is canonical to *remove* such negs). > > What targets would it break, and how? > > Hard to tell, until we try it. Mostly the 'breakage' would be some combine > patterns might no-longer match if the target only had one and the ordering > were not canonical (leading to some missed optimizations). On targets that > have both orderings, some patterns might become redundant and never match > unless directly generated by the back-end. The breakage will be that many targets optimise worse than they did before. And this is non-obvious to detect, usually. > > What makes combine come up with something else for these two cases? > > Sorry, I don't understand what you're asking here? Why does it produce > these two separate canoncializations in one compilation? I've no idea, > hence the bug report. A lot of what combine does is *not* canonicalisation. But combine comes up with only one result for every attempted combination, making that a kind-of de-facto canonicalisation. And yes, that is what I asked: in both cases it combined the same insn with a simple pseudo move, in both cases on the RHS in that insn. And it came up with different results. This may be unavoidable, or combine does something weird, or the RTL that combine started with was non-canonical or unexpected in some other way, etc. So I'd like to know where the difference was introduced. Was it in combine at all, to start with? It can be in simplify-rtx as well for example.
[Bug middle-end/92312] bogus -Wstringop-overflow storing into a trailing array backed by larger buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92312 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to work||7.3.0, 8.3.0, 9.1.0 Keywords||diagnostic Last reconfirmed||2019-10-31 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |10.0 Known to fail||10.0
[Bug middle-end/92312] New: bogus -Wstringop-overflow storing into a trailing array backed by larger buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92312
Bug ID: 92312
Summary: bogus -Wstringop-overflow storing into a trailing
array backed by larger buffer
Product: gcc
Version: 10.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: ---
GCC 10.0 issues a -Wstringop-overflow warning for stores into trailing arrays
that are backed by a large enough buffer to act as larger "flexible array
members." This is a safe idiom that should probably be allowed without a
warning. It's used for example in the Linux kernel where it triggers the
following warning (and a few others):
drivers/input/mouse/cyapa_gen5.c:1559:34: warning: writing 1 byte into a region
of size 0 [-Wstringop-overflow=]
1559 | app_cmd_head->parameter_data[0] = GEN5_PARAMETER_DISABLE_PIP_REPORT;
| ^
drivers/input/mouse/cyapa_gen5.c: In function ‘cyapa_gen5_set_power_mode’:
drivers/input/mouse/cyapa_gen5.c:317:5: note: at offset 0 to object
‘parameter_data’ with size 0 declared here
317 | u8 parameter_data[0]; /* Parameter data variable based on cmd_code */
| ^~
A small test case is below.
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout z.c
struct S0 { char a, b[0]; };
void f0 (void*);
void f1 (void)
{
char a[3];
struct S0 *p = (struct S0*)a;
p->a = 0;
__builtin_memset (p->b, 0, 2); // ok
f0 (p);
}
void f2 (void)
{
char a[3];
struct S0 *p = (struct S0*)a;
p->a = 0;
p->b[0] = 0;
p->b[1] = 1; // warning
f0 (p);
}
struct Sx { char a, b[]; };
void f3 (void)
{
char a[3];
struct Sx *p = (struct Sx*)a;
p->a = 0;
p->b[0] = 0;
p->b[1] = 1; // warning
f0 (p);
}
;; Function f1 (f1, funcdef_no=0, decl_uid=1935, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
f1 ()
{
char a[3];
[local count: 1073741824]:
MEM[(struct S0 *)&a].a = 0;
__builtin_memset (&MEM [(void *)&a + 1B], 0, 2);
f0 (&a);
a ={v} {CLOBBER};
return;
}
;; Function f2 (f2, funcdef_no=1, decl_uid=1940, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
z.c: In function ‘f2’:
z.c:19:11: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
19 | p->b[0] = 0;
| ^~~
z.c:1:21: note: destination object declared here
1 | struct S0 { char a, b[0]; };
| ^
z.c:20:11: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
20 | p->b[1] = 1; // warning
| ^~~
z.c:1:21: note: destination object declared here
1 | struct S0 { char a, b[0]; };
| ^
f2 ()
{
char a[3];
[local count: 1073741824]:
MEM[(struct S0 *)&a].a = 0;
MEM[(struct S0 *)&a].b[0] = 0;
MEM[(struct S0 *)&a].b[1] = 1;
f0 (&a);
a ={v} {CLOBBER};
return;
}
;; Function f3 (f3, funcdef_no=2, decl_uid=1948, cgraph_uid=3, symbol_order=2)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
z.c: In function ‘f3’:
z.c:31:11: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
31 | p->b[0] = 0;
| ^~~
z.c:24:21: note: destination object declared here
24 | struct Sx { char a, b[]; };
| ^
z.c:32:11: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
32 | p->b[1] = 1; // warning
| ^~~
z.c:24:21: note: destination object declared here
24 | struct Sx { char a, b[]; };
| ^
f3 ()
{
char a[3];
[local count: 1073741824]:
MEM[(struct Sx *)&a].a = 0;
MEM[(struct Sx *)&a].b[0] = 0;
MEM[(struct Sx *)&a].b[1] = 1;
f0 (&a);
a ={v} {CLOBBER};
return;
}
[Bug fortran/92311] Fortran and OpenMP use_device_ptr and OpenACC attach_ptr/dettach_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92311 Jakub Jelinek changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- (In reply to Nichols A. Romero from comment #0) > The bug is against the frontend of the Fortran compiler that handles > directives in both OpenACC and OpenMP for NVidia GPUs. Here is the > compile-time error with -fopenmp: > > The error for the OpenMP is shown below: >29 |!$omp target data use_device_ptr(this_bin) > | 1 > Error: TARGET DATA must contain at least one MAP clause at (1) > > AFAIK, this is not a correct interpretation of the standard. You don't need > a map clause here, use_device_ptr clause is enough. > https://www.openmp.org/spec-html/5.0/openmpsu57.html#x83-2580002.12.2 That is what OpenMP 5.0 says, but not what 4.5 said, 4.5 required at least one map clause, and GCC 9 implements in Fortran only OpenMP 4.0 and some parts of OpenMP 4.5, not OpenMP 5.0. CCing Tobias Burnus who has made progress on use_device_ptr/use_device_addr for GCC 10 in Fortran.
[Bug preprocessor/69665] Internal error on #pragma push_macro("__FILE__")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69665 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 92296 ***
[Bug preprocessor/92296] [7/8/9 Regression] internal compiler error: Segmentation fault #pragma push_macro("__LINE__")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 Jakub Jelinek changed: What|Removed |Added CC||daniel at hebirobotics dot com --- Comment #14 from Jakub Jelinek --- *** Bug 87181 has been marked as a duplicate of this bug. ***
[Bug c++/87181] ICE with _Pragma push_macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87181 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 92296 ***
[Bug preprocessor/92296] [7/8/9 Regression] internal compiler error: Segmentation fault #pragma push_macro("__LINE__")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 Jakub Jelinek changed: What|Removed |Added CC||Keith.S.Thompson at gmail dot com --- Comment #13 from Jakub Jelinek --- *** Bug 69665 has been marked as a duplicate of this bug. ***
[Bug fortran/92311] Fortran and OpenMP use_device_ptr and OpenACC attach_ptr/dettach_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92311 --- Comment #2 from Jakub Jelinek --- Also, looking at that testcase, that doesn't look valid even in OpenMP 5.0. It is using use_device_ptr on an non-associated pointer, from that one gets a device pointer, but then it associates it with host variables and maps normally. I fail to see the point why it is trying to use use_device_ptr in this case at all, with use_device_ptr one gets something that can be passed through is_device_ptr or passed to specialized routines that can handle say CUDA device pointers.
