[Bug libstdc++/105722] [10 regression] std/ranges/adaptors/elements.cc fails after r10-10724-g93ec7bf2253061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105722 Richard Biener changed: What|Removed |Added Known to work||10.3.0 Target Milestone|--- |10.4 Priority|P3 |P1 Known to fail||10.3.1 --- Comment #1 from Richard Biener --- Makes it P1 since 10.3.0 worked(?)
[Bug libstdc++/105723] Optimization false positive warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105723 Richard Biener changed: What|Removed |Added Keywords||diagnostic Component|c++ |libstdc++ --- Comment #1 from Richard Biener --- In file included from /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/algorithm:61, from :1: In function '_OIter std::transform(_IIter, _IIter, _OIter, _UnaryOperation) [with _IIter = reverse_iterator<__gnu_cxx::__normal_iterator > >; _OIter = reverse_iterator<__gnu_cxx::__normal_iterator > >; _UnaryOperation = some_func(const uint8_t* const&)::]', inlined from 'void some_func(const uint8_t* const&)' at :15:23: /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:4263:19: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 4263 | *__result = __unary_op(*__first); | ~~^~ compilation terminated due to -Wfatal-errors. cc1plus: some warnings being treated as errors Compiler returned: 1
[Bug c++/105726] spurious warning with -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105726 Richard Biener changed: What|Removed |Added Keywords||diagnostic Blocks||56456 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-05-25 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. At -O1 emitted by the warn_restrict pass on [local count: 1073741824]: _3 = &MEM[(const struct array *)aMessage_1(D) + 4B]._M_elems; strncpy (aBuffer_4(D), _3, 1); return; type_6 QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x75d86d20 domain pointer_to_this > unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x75d86f18> readonly arg:0 readonly type_6 QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x75d862a0 domain > readonly arg:0 arg:0 visited var def_stmt GIMPLE_NOP version:1 ptr-info 0x75d7b8e8> arg:1 > arg:1 I think the pass mis-analyzes the reference. Let me have a look. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug rtl-optimization/105459] [12/13 Regression] ICE: Segmentation fault (in record_operand_costs) since r12-3721-g63c6446f77b9001d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459 --- Comment #10 from Kewen Lin --- (In reply to Kewen Lin from comment #8) > (In reply to Kewen Lin from comment #7) > > I wonder if it's fine to move init_function_start downward after > > execute_all_ipa_transforms call? the testing is ongoing. > > This proposed patch was bootstrapped and regress-tested. I think it's > reasonable as it can avoid uninitialized target global issue (on secondary > members) exposed by this bug. > Just noticed that in execute_pass_list (cfun, g->get_passes ()->all_passes), it's still possible in theory to change the cfun and cause the possible target global creation (call save_target_globals_default_opts for a totally new target option node, I think it wants copying actually) in target hook. Although the proposed fix can make the ICE gone, this issue gets exposed is due to the special handlings introduced by r11-5855 which creates target globals again. Technically speaking we can create one new target option node and with a new target globals in set_current_function hook without any restricted conditions, then this issue can be exposed easily. Not sure this kind of need would become popular or not, if yes, we probably need to add one deep copy interface for target globals when its previous target global having this_target_rtl->target_specific_initialized true.
[Bug target/104689] aarch64: libgcc: DW_CFA_val_expression is not supported for RA_SIGN_SATE register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104689 --- Comment #1 from CVS Commits --- The master branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:0d344b557604e966dc7f91739881f03e1f221efd commit r13-753-g0d344b557604e966dc7f91739881f03e1f221efd Author: Szabolcs Nagy Date: Thu Feb 10 17:42:56 2022 + aarch64: Fix pac-ret with unusual dwarf in libgcc unwinder [PR104689] The RA_SIGN_STATE dwarf pseudo-register is normally only set using the DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which toggles the return address signedness state (the default state is 0). (It may be set by remember/restore_state CFI too, those save/restore the state of all registers.) However RA_SIGN_STATE can be set directly via DW_CFA_val_expression too. GCC does not generate such CFI but some other compilers reportedly do. Note: the toggle operation must not be mixed with other dwarf register rule CFI within the same CIE and FDE. In libgcc we assume REG_UNSAVED means the RA_STATE is set using toggle operations, otherwise we assume its value is set by other CFI. libgcc/ChangeLog: PR target/104689 * config/aarch64/aarch64-unwind.h (aarch64_frob_update_context): Handle the !REG_UNSAVED case. * unwind-dw2.c (execute_cfa_program): Fail toggle if !REG_UNSAVED. gcc/testsuite/ChangeLog: PR target/104689 * gcc.target/aarch64/pr104689.c: New test.
[Bug target/104689] aarch64: libgcc: DW_CFA_val_expression is not supported for RA_SIGN_SATE register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104689 nsz at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from nsz at gcc dot gnu.org --- fixed for gcc-13
[Bug c++/105725] [ICE] segfault with `-Wmismatched-tags`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105725 --- Comment #1 from tim blechmann --- it also ICEs on valid code: ``` template struct enable_if; template using enable_if_t = typename enable_if<_Cond>::type; template bool is_class_v; template bool IsPrivateSignalArg; template bool IsPrivateSignalArg>>; ```
[Bug c++/105726] spurious warning with -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105726
Richard Biener changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
Oh, my - this is mightly complicated code. We get to
void
builtin_memref::set_base_and_offset (tree expr)
{
...
if (TREE_CODE (base) == MEM_REF)
{
tree memrefoff = fold_convert (ptrdiff_type_node, TREE_OPERAND (base,
1));
extend_offset_range (memrefoff);
base = TREE_OPERAND (base, 0);
if (refoff != HOST_WIDE_INT_MIN
&& TREE_CODE (expr) == COMPONENT_REF)
{
/* Bump up the offset of the referenced subobject to reflect
the offset to the enclosing object. For example, so that
in
struct S { char a, b[3]; } s[2];
strcpy (s[1].b, "1234");
REFOFF is set to s[1].b - (char*)s. */
offset_int off = tree_to_shwi (memrefoff);
refoff += off;
}
which looks somewhat suspicious and then
tree
builtin_memref::offset_out_of_bounds (int strict, offset_int ooboff[3]) const
{
...
/* When the referenced subobject is known, the end offset must be
within its bounds. Otherwise there is nothing to do. */
if (strict
&& !decl_p
&& ref
&& refsize >= 0
&& TREE_CODE (ref) == COMPONENT_REF)
{
/* If REFOFF is negative, SIZE will become negative here. */
size = refoff + refsize;
obj = ref;
triggers with ref being a COMPONENT_REF to the array, refoff being 4 (from the
MEM_REF) and refsize == 0.
The idea is probably that the '4' is for the pointer adjustment (base
is &aMessage here), but then the object shouldn't be 'ref'?
But I'm confused by all the complexity and the abstraction and I'm sure
starting to deleting code that confuses me will cause all sorts of
regressions in the diagnostic parts of the testsuite.
Martin - can you have a look here and maybe give directions?
In particular how 'refoff' and 'offrange' depend (or if they stand on its
own). I think that &ref - &base == refoff?
So for &MEM[(const struct array *)aMessage_1(D) + 4B]._M_elems
having ref = MEM[(const struct array *)aMessage_1(D) + 4B]._M_elems,
base = aMessage_1(D), refoff = 4 and offrange[] = {4, 4} looks OK.
But then I'm confused as to why the diagnostic triggers. Maybe that's
because refsize == 0 which is a special case for "unknown"? That's
because ref analysis does
if (!integer_zerop (memrefoff))
/* A non-zero offset into an array of struct with flexible array
members implies that the array is empty because there is no
way to initialize such a member when it belongs to an array.
This must be some sort of a bug. */
refsize = 0;
on the MEM_REF path. But I don't understand how the comment applies
here - there is no flexibel array member involved, in particular
the MEM_REF doesn't offset an array it offsets struct X. So I'm
inclined to simply kill the above ...?
[Bug c++/105726] spurious warning with -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105726 --- Comment #3 from Richard Biener --- The following fixes the bogus diagnostic: diff --git a/gcc/gimple-ssa-warn-restrict.cc b/gcc/gimple-ssa-warn-restrict.cc index b678e806da3..25c63f99c61 100644 --- a/gcc/gimple-ssa-warn-restrict.cc +++ b/gcc/gimple-ssa-warn-restrict.cc @@ -539,13 +559,6 @@ builtin_memref::set_base_and_offset (tree expr) offset_int off = tree_to_shwi (memrefoff); refoff += off; } - - if (!integer_zerop (memrefoff)) - /* A non-zero offset into an array of struct with flexible array - members implies that the array is empty because there is no - way to initialize such a member when it belongs to an array. - This must be some sort of a bug. */ - refsize = 0; } if (TREE_CODE (ref) == COMPONENT_REF)
[Bug c++/104493] OpenMP offload map cannot handle const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104493
--- Comment #2 from Tobias Burnus ---
(In reply to Ye Luo from comment #1)
> gcc 12 rejects the code but devel/omp/gcc-11 was happy.
Note: the devel/omp/gcc-* branch contains both patches backported ("git
cherry-picked") from the mainline (curent development) branch but also some
patches which are not yet on mainline for various reasons. – In particular,
this happens for features which are only ready shortly before the next release
("release freeze"). The closer to the release and the more invasive the
patches, the less likely to be included. — See https://gcc.gnu.org/develop.html
for "Schedule" with Stage 1/3/4 for an overview and towards the end of the
page, the timeline (i.e. when did Stage 1/(2/)/3/4 start and when were the GCC
releases).
If a patch is in OG11 then it is almost sure that OG12 will also contain it.
Additionally, there is a high probability that this patch will also be included
in mainline.
For GCC's git, its branches branches in general and the active branches,
including devel/omp/gcc-*, see also https://gcc.gnu.org/git.html (OG12, based
on the GCC 12 branch, will soon be available; at the same time, OG11 will then
be retired).
* * *
Regarding the issue at hand, I think the issue is fixed by patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591449.html
is was reviewed at
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594082.html
with some minor comments. Thus, I assume that this patch will soon be committed
to
GCC 13 (current mainline).
* * *
I concur that it is a bit unfortunate that it missed the GCC 12 deadline, but
that's the general problem with deadlines and bug fixes and new features:
There will always be features/bug fixes, which are very important for some,
that missed the deadline by a very short time.
[Bug lto/105727] New: __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727
Bug ID: 105727
Summary: __builtin_constant_p expansion in LTO
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
It's basically follow-up of PR101941 which I noticed during the building of
Linux with LTO w/ KASAN enabled:
$ cat a.c
void memory_is_poisoned(int size) {
if (__builtin_constant_p(size)) __builtin_abort();
}
$ cat b.c
void memory_is_poisoned(int size);
int main(int argc, char **argv) {
memory_is_poisoned(128);
return 0;
}
$ gcc [ab].c -O2 && ./a.out
$ clang [ab].c -flto -O2 && ./a.out
$ gcc [ab].c -flto -O2 && ./a.out
Aborted (core dumped)
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101941 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-25 --- Comment #1 from Martin Liška --- So the question is if the LTO time expansion is correct or not?
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2 from Florian Weimer --- (In reply to Martin Liška from comment #1) > So the question is if the LTO time expansion is correct or not? What's the argument in favor of it being incorrect? Sorry, I just don't see it.
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 Andrew Pinski changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Andrew Pinski --- This has to have been reduced too much. Gcc is doing exactly what it was asked to do. __builtin_constant_p works across inlining and lto.
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 --- Comment #4 from Jakub Jelinek --- I don't see anything wrong on it. If memory_is_poisoned is inlined into main, size is constant, if memory_is_poisoned is cloned and ipa-cp or ipa-vrp optimized, likewise.
[Bug c++/105726] spurious warning with -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105726
--- Comment #4 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> The following fixes the bogus diagnostic:
>
> diff --git a/gcc/gimple-ssa-warn-restrict.cc
> b/gcc/gimple-ssa-warn-restrict.cc
> index b678e806da3..25c63f99c61 100644
> --- a/gcc/gimple-ssa-warn-restrict.cc
> +++ b/gcc/gimple-ssa-warn-restrict.cc
> @@ -539,13 +559,6 @@ builtin_memref::set_base_and_offset (tree expr)
> offset_int off = tree_to_shwi (memrefoff);
> refoff += off;
> }
> -
> - if (!integer_zerop (memrefoff))
> - /* A non-zero offset into an array of struct with flexible array
> - members implies that the array is empty because there is no
> - way to initialize such a member when it belongs to an array.
> - This must be some sort of a bug. */
> - refsize = 0;
> }
>
>if (TREE_CODE (ref) == COMPONENT_REF)
It for example regresses gcc.dg/Warray-bounds-46.c which essentially does
struct X { char pad[4]; char ax[]; };
void foo (struct X *p, char *a)
{
__builtin_strcpy (p[1].ax, a);
}
and the intent was to detect that p[1] implies a zero-size 'ax'. That's
going to be interesting to distinguish from our case here with just
the MEM_REF - possibly the easiest heuristic is to trigger this only
for incomplete TREE_TYPE of the MEM_REF at least. That will still
trigger in too many cases, requiring the MEM_REF offset to be a multiple
of the size of the struct will trigger in not enough cases (if there's
also an embedded offset into the array). But maybe it's a good compromise:
diff --git a/gcc/gimple-ssa-warn-restrict.cc b/gcc/gimple-ssa-warn-restrict.cc
index b678e806da3..734cdd7f5b4 100644
--- a/gcc/gimple-ssa-warn-restrict.cc
+++ b/gcc/gimple-ssa-warn-restrict.cc
@@ -525,7 +525,6 @@ builtin_memref::set_base_and_offset (tree expr)
{
tree memrefoff = fold_convert (ptrdiff_type_node, TREE_OPERAND (base,
1));
extend_offset_range (memrefoff);
- base = TREE_OPERAND (base, 0);
if (refoff != HOST_WIDE_INT_MIN
&& TREE_CODE (expr) == COMPONENT_REF)
@@ -538,14 +537,19 @@ builtin_memref::set_base_and_offset (tree expr)
REFOFF is set to s[1].b - (char*)s. */
offset_int off = tree_to_shwi (memrefoff);
refoff += off;
- }
-
- if (!integer_zerop (memrefoff))
- /* A non-zero offset into an array of struct with flexible array
- members implies that the array is empty because there is no
- way to initialize such a member when it belongs to an array.
- This must be some sort of a bug. */
- refsize = 0;
+
+ if (!integer_zerop (memrefoff)
+ && !COMPLETE_TYPE_P (TREE_TYPE (expr))
+ && multiple_of_p (sizetype, memrefoff,
+ TYPE_SIZE_UNIT (TREE_TYPE (base)), true))
+ /* A non-zero offset into an array of struct with flexible array
+ members implies that the array is empty because there is no
+ way to initialize such a member when it belongs to an array.
+ This must be some sort of a bug. */
+ refsize = 0;
+ }
+
+ base = TREE_OPERAND (base, 0);
}
if (TREE_CODE (ref) == COMPONENT_REF)
[Bug tree-optimization/105726] [10/11/12/13 Regression] spurious warning with -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105726 Richard Biener changed: What|Removed |Added Summary|spurious warning with |[10/11/12/13 Regression] |-Warray-bounds |spurious warning with ||-Warray-bounds Known to fail||10.3.1, 11.3.0, 12.1.0 Target Milestone|--- |10.4 Priority|P3 |P2 Component|c++ |tree-optimization Known to work||9.4.1
[Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:af02daff557a0abbf5521c143f1cdda406848a9b commit r13-756-gaf02daff557a0abbf5521c143f1cdda406848a9b Author: Jakub Jelinek Date: Wed May 25 12:05:08 2022 +0200 asan: Fix up instrumentation of assignments which are both loads and stores [PR105714] On the following testcase with -Os asan pass sees: [local count: 354334800]: # h_21 = PHI *c.3_5 = *d.2_4; h_15 = h_21 + 1; if (h_15 != 3) goto ; [75.00%] else goto ; [25.00%] [local count: 118111600]: *c.3_5 = MEM[(struct a *)&b + 12B]; _13 = c.3_5->x; return _13; It instruments the *c.3_5 = *d.2_4; assignment by adding .ASAN_CHECK (7, c.3_5, 4, 4); .ASAN_CHECK (6, d.2_4, 4, 4); before it (which later lowers to checking the corresponding shadow memory). But when considering instrumentation of *c.3_5 = MEM[(struct a *)&b + 12B]; it doesn't instrument anything, because it sees that *c.3_5 store is already instrumented in a dominating block and so there is no need to instrument *c.3_5 store again (i.e. add another .ASAN_CHECK (7, c.3_5, 4, 4); ). That is true, but misses the fact that we still want to instrument the MEM[(struct a *)&b + 12B] load. The following patch fixes that by changing has_stmt_been_instrumented_p to consider both store and load in the assignment if it does both (returning true iff both have been instrumented). That matches how we handle e.g. builtin calls, where we also perform AND of all the memory locs involved in the call. I've verified that we still don't add the redundant .ASAN_CHECK (7, c.3_5, 4, 4); call but just add _18 = &MEM[(struct a *)&b + 12B]; .ASAN_CHECK (6, _18, 4, 4); to instrument the load. 2022-05-25 Jakub Jelinek PR sanitizer/105714 * asan.cc (has_stmt_been_instrumented_p): For assignments which are both stores and loads, return true only if both destination and source have been instrumented. * gcc.dg/asan/pr105714.c: New test.
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #5 from Martin Liška --- All right, then closing as invalid.
[Bug c++/105725] [ICE] segfault with `-Wmismatched-tags`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105725 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-05-25 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #2 from Marek Polacek --- Confirmed. Started with r10-7424-g04dd734b52de1218 when the warning was added.
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 --- Comment #6 from Jan Hubicka --- I don't know what clang does, but GCC keeps builtin_constant_p till late optimization and resolves it then. So here we cross module inline (or constant propagate) and then it becomes constant. Outcome of __builtin_constant_p should depend on optimization settings and LTO is one of them. So I would say that both clang and gcc are correct, just gcc has better QOI. Why this breaks kernel?
[Bug c/91134] Confusing error message: error: ‘*server’ is a pointer; did you mean to use ‘->’? when -> is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91134 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7a3ee77a2e33b8b8ad31aea27996ebe92a5c8d83 commit r13-759-g7a3ee77a2e33b8b8ad31aea27996ebe92a5c8d83 Author: Jakub Jelinek Date: Wed May 25 14:21:54 2022 +0200 c: Improve build_component_ref diagnostics [PR91134] On the following testcase (the first dg-error line) we emit a weird diagnostics and even fixit on pointerpointer->member where pointerpointer is pointer to pointer to struct and we say 'pointerpointer' is a pointer; did you mean to use '->'? The first part is indeed true, but suggesting -> when the code already does use -> is confusing. The following patch adjusts callers so that they tell it if it is from . parsing or from -> parsing and in the latter case suggests to dereference the left operand instead by adding (* before it and ) after it (before ->). Or would a suggestion to add [0] before -> be better? 2022-05-25 Jakub Jelinek PR c/91134 gcc/c/ * c-tree.h (build_component_ref): Add ARROW_LOC location_t argument. * c-typeck.cc (build_component_ref): Likewise. If DATUM is INDIRECT_REF and ARROW_LOC isn't UNKNOWN_LOCATION, print a different diagnostic and fixit hint if DATUM has pointer type. * c-parser.cc (c_parser_postfix_expression, c_parser_omp_variable_list): Adjust build_component_ref callers. * gimple-parser.cc (c_parser_gimple_postfix_expression_after_primary): Likewise. gcc/objc/ * objc-act.cc (objc_build_component_ref): Adjust build_component_ref caller. gcc/testsuite/ * gcc.dg/pr91134.c: New test.
[Bug c/91134] Confusing error message: error: ‘*server’ is a pointer; did you mean to use ‘->’? when -> is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91134 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed for GCC 13.
[Bug tree-optimization/101668] BB vectorizer doesn't handle lowpart of existing vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101668 --- Comment #6 from Richard Biener --- Created attachment 53031 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53031&action=edit patch This works now - the support for enhanced vec_perm_const is still not complete on trunk (it claims all is OK ...) so it will ICE for testcases that would require this. But lowpart extracts and concats (untested) should work. I'll extend coverage once the dependences are on trunk. For the testcase at hand we now generate bar_s32_s64: .LFB0: .cfi_startproc vpmovsxdq %ymm0, %zmm0 vmovdqa64 %zmm0, (%rdi) ret with AVX512.
[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897 Tomáš Trnka changed: What|Removed |Added CC||trnka at scm dot com --- Comment #15 from Tomáš Trnka --- (In reply to Dominik Gronkiewicz from comment #14) > Still affected by this bug in 10.2.1. ifort, in contrast, calls the defined > assignment, which is consistent with the cited paragraph of the standard > (point 13 in 10.2.1.3 of F2018 standard draft): > > I wanted to file a new bug but found this one so just bumping. :) > Dominik Can you share a testcase that is failing for you? This issue seems to be fixed for me on GCC 10, so you have probably hit a corner case of some sort. Is there perhaps an "allocatable" component involved? If so, that's PR57696 which is still unfixed (so defined assignments don't work inside any allocatable components with GCC but they do with recent enough IFort).
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727
--- Comment #7 from Martin Liška ---
(In reply to Jan Hubicka from comment #6)
> I don't know what clang does, but GCC keeps builtin_constant_p till late
> optimization and resolves it then. So here we cross module inline (or
> constant propagate) and then it becomes constant.
>
> Outcome of __builtin_constant_p should depend on optimization settings and
> LTO is one of them. So I would say that both clang and gcc are correct, just
> gcc has better QOI. Why this breaks kernel?
Using KASAN, we end up with:
In function ‘memory_is_poisoned’,
inlined from ‘check_region_inline’ at mm/kasan/generic.c:180:6,
inlined from ‘kasan_check_range’ at mm/kasan/generic.c:189:9,
inlined from ‘memset’ at mm/kasan/shadow.c:44:7,
inlined from ‘do_sysinfo.isra’ at kernel/sys.c:2656:2:
mm/kasan/generic.c:155:25: error: call to ‘__compiletime_assert_243’ declared
with attribute error: BUILD_BUG failed
155 | BUILD_BUG();
static __always_inline bool memory_is_poisoned(unsigned long addr, size_t size)
{
if (__builtin_constant_p(size)) {
switch (size) {
case 1:
return memory_is_poisoned_1(addr);
case 2:
case 4:
case 8:
return memory_is_poisoned_2_4_8(addr, size);
case 16:
return memory_is_poisoned_16(addr);
default:
BUILD_BUG();
}
}
return memory_is_poisoned_n(addr, size);
}
where we propagate large some value during LTRANS and that's why we end up with
BUILD_BUG().
[Bug tree-optimization/94793] Failure to optimize clz idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94793 Tamar Christina changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |andrew.carlotti at arm dot com --- Comment #4 from Tamar Christina --- Assigning it to Andrew who'll take a crack at it in GCC 13
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #49 from Lewis Hyatt --- I rebased the patches so they apply to the current master branch and pinged them on gcc-patches here: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html -Lewis
[Bug c++/104493] OpenMP offload map cannot handle const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104493 --- Comment #3 from Ye Luo --- Thank you for the answer with well explained development procedure of gcc. I was intended to keep this bug report active. I just adopted OpenMP offload options adjusted in gcc 12 but OG11 doesn't have them due to using 11 as its base. So looking forward to updates on gcc 12 mainline or og12 branch.
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- I must be missing something, but it looks to me like a kasan kernel bug memset(info, 0, sizeof(struct sysinfo)); most likely doesn't have size 1, 2, 4, 8 or 16 but it is still a constant size memset calls if (!kasan_check_range((unsigned long)addr, len, true, _RET_IP_)) that calls return check_region_inline(addr, size, write, ret_ip); in check_region_inline I don't see any effort to take a different path for sizes other than 1/2/4/8/16, then it calls if (likely(!memory_is_poisoned(addr, size))) and that function emits BUILD_BUG if size is constant and not 1/2/4/8/16 What just surprises me is that it doesn't hit much more often, there will be many memset calls with constant size that is not 1/2/4/8/16. Sure, we might not inline or ipa cp/vrp all of them...
[Bug libstdc++/105722] [10 regression] std/ranges/adaptors/elements.cc fails after r10-10724-g93ec7bf2253061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105722 --- Comment #2 from seurer at gcc dot gnu.org --- Yes, it used to work.
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727
--- Comment #9 from Martin Liška ---
> Sure, we might not inline or ipa cp/vrp all of them...
That's the explanation as
bool kasan_check_range(unsigned long addr, size_t size, bool write,
unsigned long ret_ip)
{
return check_region_inline(addr, size, write, ret_ip);
}
lives in mm/kasan/generic.c and so one needs LTO in other to propagate to this
call.
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 --- Comment #10 from Jakub Jelinek --- My guess is that the BUILD_BUG(); line is the sole thing that is wrong, it should be just break; as the memory_is_poisoned_n(addr, size); will handle all the sizes, regardless if they are constants or not.
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 --- Comment #11 from Martin Liška --- (In reply to Jakub Jelinek from comment #10) > My guess is that the > BUILD_BUG(); > line is the sole thing that is wrong, it should be just break; > as the memory_is_poisoned_n(addr, size); will handle all the sizes, > regardless if they are constants or not. Sure, I'm going to suggest such a change.
[Bug sanitizer/105714] [12 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714 Jakub Jelinek changed: What|Removed |Added Summary|[12/13 Regression] ASan in |[12 Regression] ASan in gcc |gcc trunk missed a |trunk missed a |buffer-overflow at -Os |buffer-overflow at -Os |since |since |r12-5138-ge82c382971664d6f |r12-5138-ge82c382971664d6f --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far. The bug really exists in older releases too, just this testcase doesn't trigger it in gcc 11 or older.
[Bug c/105728] New: dead store to static var not optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105728
Bug ID: 105728
Summary: dead store to static var not optimized out
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
Consider this piece of test code:
int dummy1()
{
static int removeme = 0;
if (removeme)
{
return 0;
}
removeme = 1;
return 0;
}
int dummy2()
{
static int removeme = 0;
if (!removeme)
removeme = 1;
return 0;
}
int dummy3()
{
static int removeme = 0;
removeme = 1;
return 0;
}
To me, all of these do the same thing and should generate the same code.
As nobody else can see removeme, and we aren't leaking its address, shouldn't
the compiler be able to deduce that all accesses to removeme are
inconsequential and can be removed?
My gcc 11.3 generates a condidion and a store and a return 0 for dummy1, the
same thing for dummy2, but for dummy3 it understands that it only needs to emit
a return 0.
[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266 seurer at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from seurer at gcc dot gnu.org --- This is now happening with gcc 11 as of g:0be87cc23d0b0e07656e94137978971555bebbb3, r11-10013-g0be87cc23d0b0e make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr105250.c" FAIL: gcc.dg/pr105250.c (test for excess errors) # of unexpected failures1 Excess errors: /home/seurer/gcc/git/gcc-11-test/gcc/testsuite/gcc.dg/pr105250.c:28:8: error: AltiVec argument passed to unprototyped function commit 0be87cc23d0b0e07656e94137978971555bebbb3 (HEAD, refs/bisect/bad) Author: Richard Biener Date: Wed Apr 13 08:52:57 2022 +0200 tree-optimization/105250 - adjust fold_convertible_p PR105140 fix
[Bug libcc1/104799] Header issue with x86_64-linux-musl based cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104799 Lance Fredrickson changed: What|Removed |Added CC||lancethepants at gmail dot com --- Comment #3 from Lance Fredrickson --- Similar? to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105632
[Bug libgcc/105708] libgcc: aarch64: init_lse_atomics can race with user-defined constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708 --- Comment #13 from CVS Commits --- The master branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:75c4e4909ae2667f56487434f99c2915b4570794 commit r13-764-g75c4e4909ae2667f56487434f99c2915b4570794 Author: Wilco Dijkstra Date: Wed May 25 14:29:03 2022 +0100 AArch64: Prioritise init_have_lse_atomics constructor [PR 105708] Increase the priority of the init_have_lse_atomics constructor so it runs before other constructors. This improves chances that rr works when LSE atomics are supported. libgcc/ PR libgcc/105708 * config/aarch64/lse-init.c: Increase constructor priority.
[Bug c++/100252] [9/10/11/12/13 Regression] Internal compiler error during template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100252
--- Comment #11 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:1b661f3f5e712c951e774b3b91fffe4dac734cc7
commit r13-765-g1b661f3f5e712c951e774b3b91fffe4dac734cc7
Author: Marek Polacek
Date: Tue Apr 26 15:52:00 2022 -0400
c++: ICE with temporary of class type in DMI [PR100252]
Consider
struct A {
int x;
int y = x;
};
struct B {
int x = 0;
int y = A{x}.y; // #1
};
where for #1 we end up with
{.x=(&)->x, .y=(&)->x}
that is, two PLACEHOLDER_EXPRs for different types on the same level in
a {}. This crashes because our CONSTRUCTOR_PLACEHOLDER_BOUNDARY mechanism
to
avoid replacing unrelated PLACEHOLDER_EXPRs cannot deal with it.
Here's why we wound up with those PLACEHOLDER_EXPRs: When we're performing
cp_parser_late_parsing_nsdmi for "int y = A{x}.y;" we use
finish_compound_literal
on type=A, compound_literal={((struct B *) this)->x}. When digesting this
initializer, we call get_nsdmi which creates a PLACEHOLDER_EXPR for A -- we
don't
have any object to refer to yet. After digesting, we have
{.x=((struct B *) this)->x, .y=(&)->x}
and since we've created a PLACEHOLDER_EXPR inside it, we marked the whole
ctor
CONSTRUCTOR_PLACEHOLDER_BOUNDARY. f_c_l creates a TARGET_EXPR and returns
TARGET_EXPR x, .y=(&)->x}>
Then we get to
B b = {};
and call store_init_value, which digests the {}, which produces
{.x=NON_LVALUE_EXPR <0>, .y=(TARGET_EXPR )->x, .y=(&)->x}>).y}
lookup_placeholder in constexpr won't find an object to replace the
PLACEHOLDER_EXPR for B, because ctx->object will be D.2395 of type A, and
we
cannot search outward from D.2395 to find 'b'.
The call to replace_placeholders in store_init_value will not do anything:
we've marked the inner { } CONSTRUCTOR_PLACEHOLDER_BOUNDARY, and it's only
a sub-expression, so replace_placeholders does nothing, so the
stays even though now is the perfect time to replace it because we have an
object for it: 'b'.
Later, in cp_gimplify_init_expr the *expr_p is
D.2395 = {.x=(&)->x, .y=(&)->x}
where D.2395 is of type A, but we crash because we hit ,
which
has a different type.
My idea was to replace with D.2384 after creating the
TARGET_EXPR because that means we have an object we can refer to.
Then clear CONSTRUCTOR_PLACEHOLDER_BOUNDARY because we no longer have
a PLACEHOLDER_EXPR in the {}. Then store_init_value will be able to
replace with 'b', and we should be good to go. We must
be careful not to break guaranteed copy elision, so this replacement
happens in digest_nsdmi_init where we can see the whole initializer,
and avoid replacing any placeholders in TARGET_EXPRs used in the context
of initialization/copy elision. This is achieved via the new function
called potential_prvalue_result_of.
While fixing this problem, I found PR105550, thus the FIXMEs in the
tests.
PR c++/100252
gcc/cp/ChangeLog:
* typeck2.cc (potential_prvalue_result_of): New.
(replace_placeholders_for_class_temp_r): New.
(digest_nsdmi_init): Call it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/nsdmi-aggr14.C: New test.
* g++.dg/cpp1y/nsdmi-aggr15.C: New test.
* g++.dg/cpp1y/nsdmi-aggr16.C: New test.
* g++.dg/cpp1y/nsdmi-aggr17.C: New test.
* g++.dg/cpp1y/nsdmi-aggr18.C: New test.
* g++.dg/cpp1y/nsdmi-aggr19.C: New test.
[Bug c++/100252] [9/10/11/12 Regression] Internal compiler error during template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100252 Marek Polacek changed: What|Removed |Added Summary|[9/10/11/12/13 Regression] |[9/10/11/12 Regression] |Internal compiler error |Internal compiler error |during template |during template |instantiation |instantiation --- Comment #12 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/36685] clarify/diagnose use of weak constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36685 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #4 from James Y Knight --- The interaction of __attribute__((weak)) and const int was recently explored in Clang in this thread: https://discourse.llvm.org/t/weak-attribute-semantics-on-const-variables/62311 Strangely, it appears that Clang and GCC have opposite odd behavior currently: GCC appears to evaluate weak constants _only_ in constant evaluation (so long as
[Bug c++/105623] [12/13 regression][rejects valid] invalid use of auto when deducing return type of base class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105623 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:850a9ce8bcca59c7efabcdeeca14c5bd905e8363 commit r13-768-g850a9ce8bcca59c7efabcdeeca14c5bd905e8363 Author: Jason Merrill Date: Tue May 24 17:37:58 2022 -0400 c++: deduction from auto fn [PR105623] Since my patch for PR90451, we defer mark_used of single functions as late as possible. And since my r12-1273, we keep BASELINK from lookup around rather than reconstruct it later. These both made us try to instantiate g with a function type that still had 'auto' as its return type. PR c++/105623 gcc/cp/ChangeLog: * decl2.cc (mark_used): Copy type from fn to BASELINK. * pt.cc (unify_one_argument): Call mark_single_function. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn62.C: New test.
[Bug c++/36685] clarify/diagnose use of weak constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36685 --- Comment #5 from James Y Knight --- (oops submitted commit by mistake, continuing...) Strangely, it appears that Clang and GCC both have odd behaviors currently, but somewhat opposites: - GCC appears to evaluate weak constants _only_ in frontend constant evaluation. It does not treat them as known during backend optimizations. (However, GCC does not allow you to use such a variable in a context that is required to be constant by language rules). - Clang evaluates weak constants _only_ in backend optimizations, and never in frontend constant evaluation. Clang will be changing to stop optimizing based on weak constant value, so that they are consistently treated as unknown values. I'd suggest that GCC probably ought to do the same (by no longer constant evaluating such variables).
[Bug c++/105655] [12/13 Regression] ICE on invalid deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105655 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/96363] bogus error with multiple constrained partial specialization forward declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96363 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
Re: [Bug c/105728] New: dead store to static var not optimized out
> To me, all of these do the same thing and should generate the same code. > As nobody else can see removeme, and we aren't leaking its address, shouldn't > the compiler be able to deduce that all accesses to removeme are > inconsequential and can be removed? > > My gcc 11.3 generates a condidion and a store and a return 0 for dummy1, the > same thing for dummy2, but for dummy3 it understands that it only needs to > emit > a return 0. GCC detects "write olny" variables and that is what matches for dummy3. I am not 100% sure it is valid to do the optimization in other two cases since when multiple threads are considered. In any case we lack tracking of constants stored to global variables which is something ipa-cp can be extended to. Honza
[Bug c/105728] dead store to static var not optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105728 --- Comment #1 from hubicka at kam dot mff.cuni.cz --- > To me, all of these do the same thing and should generate the same code. > As nobody else can see removeme, and we aren't leaking its address, shouldn't > the compiler be able to deduce that all accesses to removeme are > inconsequential and can be removed? > > My gcc 11.3 generates a condidion and a store and a return 0 for dummy1, the > same thing for dummy2, but for dummy3 it understands that it only needs to > emit > a return 0. GCC detects "write olny" variables and that is what matches for dummy3. I am not 100% sure it is valid to do the optimization in other two cases since when multiple threads are considered. In any case we lack tracking of constants stored to global variables which is something ipa-cp can be extended to. Honza
Re: [Bug lto/105727] __builtin_constant_p expansion in LTO
> > My guess is that the > > BUILD_BUG(); > > line is the sole thing that is wrong, it should be just break; > > as the memory_is_poisoned_n(addr, size); will handle all the sizes, > > regardless if they are constants or not. > > Sure, I'm going to suggest such a change. To me it looked like a protection that size is not going to be large (or perhaps author wants to add extra special cases as they are needed) Honza
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 --- Comment #12 from hubicka at kam dot mff.cuni.cz --- > > My guess is that the > > BUILD_BUG(); > > line is the sole thing that is wrong, it should be just break; > > as the memory_is_poisoned_n(addr, size); will handle all the sizes, > > regardless if they are constants or not. > > Sure, I'm going to suggest such a change. To me it looked like a protection that size is not going to be large (or perhaps author wants to add extra special cases as they are needed) Honza
[Bug other/105729] New: False positive UBsan "reference binding to null pointer of type" when evaluating array indexing which throws exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105729
Bug ID: 105729
Summary: False positive UBsan "reference binding to null
pointer of type" when evaluating array indexing which
throws exception
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: egor_suvorov at mail dot ru
Target Milestone: ---
Consider the following code:
int range_check(int x) {
throw 0;
}
struct Bar {};
struct Foo {
Bar *data = nullptr;
const Bar &get(int x) const {
return data[range_check(x)];
}
};
int main() {
Foo b;
try {
b.get(-1);
} catch (...) {
}
}
In my understanding, it contains no UB: although binding a reference to
`data[range_check(x)]` would result in UB due to a null pointer reference (or
an invalid pointer altogether), it is never evaluated as `range_check` just
throws an exception. Hence, this program should not trigger any UBsan
(undefined sanitizer) warnings.
I was able to reproduce it on Ubuntu 20.04 with both "g++ (Ubuntu
9.4.0-1ubuntu1~20.04.1) 9.4.0" and "gcc version 10.3.0 (Ubuntu
10.3.0-1ubuntu1~20.04)":
1. Compile the code from above with `g++ -fsanitize=undefined a.cpp`
2. Run `./a.out`
3. Expected output: empty. Real output:
a.cpp:8:23: runtime error: reference binding to null pointer of type 'const
struct Bar'
This also reproduces on the trunk version of GCC at the Compiler Explorer
(https://godbolt.org/z/q5edxMbaE), but I was unable to find Clang version with
such behavior.
Additional information:
* If you set a `catch throw` in GDB in the program above, you get stopped
inside `__cxa_throw` after the `reference binding to null pointer` message is
emitted by the sanitizer. So it looks like the check is performed before
actually running the `range_check` function, which is a good idea unless
exceptions are involved.
* Moving the field to a local/global variable hides the issue
* Removing const-qualification from the method hides the issue
[Bug middle-end/93517] bogus -Wrestrict on sprintf with unknown strings bounded by array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93517 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Martin Sebor --- I'm not able to reproduce the warning with any released version, or on trunk.
[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774 Bug 84774 depends on bug 93517, which changed state. Bug 93517 Summary: bogus -Wrestrict on sprintf with unknown strings bounded by array size https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93517 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug target/105090] BFI instructions are not generated on arm-none-eabi-g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090 --- Comment #4 from Andrew Jeddeloh --- Hi, I wanted to follow up now that GCC 13 development has opened up. Any news on including it?
[Bug target/105704] jump tables are not marked with @STT_OBJECT, disassembly wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105704 --- Comment #3 from Jürgen Urban --- >From security point of view the compiler should not put jump tables into the code, because this creates new attack vectors. The code might be used by different types of security attacks, as it can contain instructions which are special (cache or FPU operations for example). A better location would be a different section which can be configured to be not executable. For me it looks like it could be easy to add the @STT_OBJECT feature while it would help to correctly disassemble the code. When you have to analyse the code for security or safety reasons, this helps with automated analysis. For example you might have to prove full code coverage when testing and the compiler should not create code which is never executed/tested. The fmsub instruction can never be executed. For such an analysis you get into problems, as you have to explain why the code is never executed. Actually the problem was detected as the code should not contain any floating point instructions (because FPU is disabled), but the disassembly has shown that this was not the case.
[Bug c++/105722] [10 regression] std/ranges/adaptors/elements.cc fails after r10-10724-g93ec7bf2253061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105722 Jason Merrill changed: What|Removed |Added Ever confirmed|0 |1 Component|libstdc++ |c++ Depends on||102629 Last reconfirmed||2022-05-25 Status|UNCONFIRMED |NEW Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629 [Bug 102629] [10 Regression] ICE: tree check in lookup_base, at cp/search.c:233 since r10-2194-g10acaf4db9f8b54b
[Bug c++/105722] [10 regression] std/ranges/adaptors/elements.cc fails after r10-10724-g93ec7bf2253061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105722 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:bea4429004b02b834c6a15dcc3bfbd953b230585 commit r10-10759-gbea4429004b02b834c6a15dcc3bfbd953b230585 Author: Jason Merrill Date: Wed May 25 12:55:26 2022 -0400 Revert "c++: pack init-capture of unresolved overload [PR102629]" PR c++/105722 This reverts commit 93ec7bf22530610ef697fd3a64a28bebd589c790.
[Bug c++/102307] [10/11/12 Regression] internal compiler error: in reshape_init_r since r10-6388-ge98ebda074bf8fc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102307 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5022f4af0d1e2f3fdf2bb159d4372ee3cf34b052 commit r10-10760-g5022f4af0d1e2f3fdf2bb159d4372ee3cf34b052 Author: Jason Merrill Date: Tue Apr 26 11:15:04 2022 -0400 c++: constexpr ref to array of array [PR102307] The problem here is that first check_initializer calls build_aggr_init_full_exprs, which does overload resolution, but then in the case of failed constexpr throws away the result and does it again in build_functional_cast. But in the first overload resolution, reshape_init_array_1 decided to reuse the inner CONSTRUCTORs because tf_error is set, so we know we're committed. But the second pass gets confused by the CONSTRUCTORs with non-init-list types. Fixed by avoiding a second pass: instead, pass the call from build_aggr_init to build_cplus_new, which will turn it into a TARGET_EXPR. I don't bother to change the object argument because it will be replaced later in simplify_aggr_init_expr. PR c++/102307 gcc/cp/ChangeLog: * decl.c (check_initializer): Use build_cplus_new in case of constexpr failure. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-array2.C: New test.
[Bug c++/102629] [10 Regression] ICE: tree check in lookup_base, at cp/search.c:233 since r10-2194-g10acaf4db9f8b54b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629 Jason Merrill changed: What|Removed |Added Target Milestone|10.4|11.3 --- Comment #7 from Jason Merrill --- The fix caused a regression on the 10 branch, so I backed it out.
[Bug c++/105722] [10 regression] std/ranges/adaptors/elements.cc fails after r10-10724-g93ec7bf2253061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105722 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Jason Merrill --- Fixed by reverting that change. I take it the 11 branch doesn't have the same problem?
[Bug c++/105716] [12/13 Regression] CTAD failure with member function returning auto as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105716 Jason Merrill changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Jason Merrill --- Same issue. *** This bug has been marked as a duplicate of bug 105623 ***
[Bug c++/105623] [12/13 regression][rejects valid] invalid use of auto when deducing return type of base class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105623 Jason Merrill changed: What|Removed |Added CC||j-l.wynen at hotmail dot de --- Comment #5 from Jason Merrill --- *** Bug 105716 has been marked as a duplicate of this bug. ***
[Bug ipa/105690] -Warray-bounds sensitive false positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105690 --- Comment #2 from Martin Jambor --- (In reply to Richard Biener from comment #1) > somehow function splitting exposes this, With options: -O2 -Warray-bounds -S -fno-inline-functions-called-once --param inline-unit-growth=0 --param max-inline-insns-auto=0 the warning also goes away, so it might be re-inlining the split functions together that exposes it. > but since all calls to > .part.0 are properly guarded this is senseless doing (maybe IPA with VRP > info does something odd here with the signed/unsigned promotion) IPA-VRP (or IPA-CP in general) does not seem to play a role, or at least disabling them does not seem to have any effect.
[Bug libstdc++/105730] New: Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 Bug ID: 105730 Summary: Issue with commit - Allow std::condition_variable waits to be cancelled Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lancethepants at gmail dot com Target Milestone: --- I noticed that the lld-14 linker (and also lldb) built with gcc-12 was segfaulting and pointing to libstdc++ in the backtrace. I've narrowed it down to commit 9e18a25331fa25c3907249fede65a02c6817b06e. When I reverse this commit then lld built by gcc functions again normally. gcc-12.1 release uclibc-ng c-standard library armv7 cpu I'm not sure if the issue is unique to uclibc-ng, arm, or if it's a general issue to all platforms. Here is the gdb log. Starting program: /mmc/bin/ld.lld -plugin /mmc/libexec/gcc/arm-tomatoware-linux-uclibcgnueabi/12.1.0/liblto_plugin.so -plugin-opt=/mmc/libexec/gcc/arm-tomatoware-linux-uclibcgnueabi/12.1.0/lto-wrapper -plugin-opt=-fresolution=/mmc/tmp/cc1ZwXDr.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/mmc --eh-frame-hdr -dynamic-linker /mmc/lib/ld-uClibc.so.1 -X -m armelf_linux_eabi -o hello /mmc/usr/lib/crt1.o /mmc/usr/lib/crti.o /mmc/lib/gcc/arm-tomatoware-linux-uclibcgnueabi/12.1.0/crtbegin.o -L/mmc/lib/gcc/arm-tomatoware-linux-uclibcgnueabi/12.1.0 -L/mmc/lib/gcc/arm-tomatoware-linux-uclibcgnueabi/12.1.0/../../../../arm-tomatoware-linux-uclibcgnueabi/lib -L/mmc/lib/gcc/arm-tomatoware-linux-uclibcgnueabi/12.1.0/../../.. -L/mmc/lib -L/mmc/usr/lib hello.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /mmc/lib/gcc/arm-tomatoware-linux-uclibcgnueabi/12.1.0/crtend.o /mmc/usr/lib/crtn.o Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /mmc/lib/ld-uClibc.so.1] Can't read data for section '.debug_info' in file '/mmc/lib/libLLVM-14.so' Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /mmc/usr/lib/libstdc++.so.6] Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /mmc/lib/libgcc_s.so.1] Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /mmc/lib/libc.so.0] Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /mmc/lib/libffi.so.8] Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /mmc/lib/libedit.so.0] Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /mmc/lib/libxml2.so.2] Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /mmc/lib/liblzma.so.5] [New LWP 27688] [New LWP 27689] Thread 2 "ld.lld" received signal SIGSEGV, Segmentation fault. [Switching to LWP 27688] 0x42deada0 in std::condition_variable::wait(std::unique_lock&)@GLIBCXX_3.4.11 () from /mmc/usr/lib/libstdc++.so.6
[Bug fortran/104330] ICE in gfc_simplify_image_index, at fortran/simplify.cc:8294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104330 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||kargl at gcc dot gnu.org Last reconfirmed||2022-05-25 --- Comment #2 from kargl at gcc dot gnu.org --- NULL pointer dereference. This fixes the ICE. Don't know if the compiled code is correct. I don't have CLASS in my codes. diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc index 233cc42137f..542c8cb5537 100644 --- a/gcc/fortran/simplify.cc +++ b/gcc/fortran/simplify.cc @@ -8295,7 +8295,7 @@ gfc_simplify_image_index (gfc_expr *coarray, gfc_expr *sub) if (ref->type == REF_COMPONENT) as = ref->u.ar.as; - if (as->type == AS_DEFERRED) + if (!as || as->type == AS_DEFERRED) return NULL; /* "valid sequence of cosubscripts" are required; thus, return 0 unless
[Bug c++/105655] [12/13 Regression] ICE on invalid deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105655 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:34970d08c6297e12f3f9117b6ac19fb2de522e24 commit r13-769-g34970d08c6297e12f3f9117b6ac19fb2de522e24 Author: Jason Merrill Date: Wed May 25 12:38:58 2022 -0400 c++: CTAD with alias and nested template [PR105655] Here, alias_ctad_tweaks expect tsubst_decl of a FUNCTION_DECL to return a FUNCTION_DECL. A reasonable expectation, but in this case we were replacing the template args of the class-scope deduction guide with equivalent args, so looking in the hash table we found the partial instantiation stored when instantiating A, which is a TEMPLATE_DECL. It's fine for that to be what is stored, but tsubst_function_decl should never return it. PR c++/105655 gcc/cp/ChangeLog: * pt.cc (build_template_decl): Add assert. (tsubst_function_decl): Don't return a template. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/class-deduction-alias13.C: New test.
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 Martin Jansa changed: What|Removed |Added CC||Martin.Jansa at gmail dot com --- Comment #8 from Martin Jansa --- Can this be please backported to 11 release as well?
[Bug c++/96637] [9/10/11/12/13 Regression] ICE in tree check: expected tree_list, have error_mark in cp_check_const_attributes, at cp/decl2.c:1423
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96637 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:da2c56ee601ac696a76e469e33c88313428c5c5a commit r13-770-gda2c56ee601ac696a76e469e33c88313428c5c5a Author: Marek Polacek Date: Thu Apr 28 13:21:41 2022 -0400 c++: fix ICE on invalid attributes [PR96637] When chaining attributes, attr_chainon should be used rather than plain chainon, so that we don't end up with a TREE_LIST where one of the elements is error_mark_node, which causes problems. parser.cc has already been fixed to use attr_chainon, but decl.cc has not. Until now. PR c++/96637 gcc/cp/ChangeLog: * cp-tree.h (attr_chainon): Declare. * decl.cc (start_decl): Use attr_chainon. (grokdeclarator): Likewise. * parser.cc (cp_parser_statement): No longer static. gcc/testsuite/ChangeLog: * g++.dg/parse/error64.C: New test.
[Bug c++/105731] New: superfluous second operation before conditional branch -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105731 Bug ID: 105731 Summary: superfluous second operation before conditional branch -O2 -mcpu=cortex-m0plus Product: gcc Version: og10 (devel/omp/gcc-10) Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@little-bat.de Target Milestone: --- gcc 10.3.1 misses an easy oportunity for optimization: Instruction: if ((bits<<=1)>=0) goto p3; generated code: strhr7, [r0, #4] lslsr3, r2, #1 lslsr2, r2, #1 bpl .L8 i believe the 2nd "lsls" is superfluous. It would save me 3MHz if it wasn't there. :-) full example: https://godbolt.org/z/xocbvjn5x
[Bug c++/96637] [9/10/11/12/13 Regression] ICE in tree check: expected tree_list, have error_mark in cp_check_const_attributes, at cp/decl2.c:1423
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96637 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed for GCC 13.
[Bug target/105731] superfluous second operation before conditional branch -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105731 Marek Polacek changed: What|Removed |Added Version|og10 (devel/omp/gcc-10) |unknown Component|c++ |target CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Not a C++ FE problem.
[Bug target/105731] superfluous second operation before conditional branch -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105731 --- Comment #2 from Andrew Pinski --- Created attachment 53032 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53032&action=edit testcase
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 --- Comment #33 from Iain Sandoe --- (In reply to Eric Gallager from comment #32) > (In reply to r...@cebitec.uni-bielefeld.de from comment #26) > > That's one option, certainly easier for the users. At the least, the > > issue should be documented in install.texi so they can add > > --with-sysroot manually if need be. I just noticed that the install > > docs only have a small section on PowerPC Darwin, nothing else... > > > So wait, is the idea to add separate sections for each other architecture of > Darwin supported? Or should we just have one architecture-independent Darwin > section? When musing over this, I was thinking perhaps to have a relatively small entry [on the install webpage] for Darwin (replacing the powerpc-specific one) and just put the headlines there with a link to a new page in the wiki where we could expand upon things. I think that we would, at least, need subsections for darwin <= 10 darwin 11..14 darwin 15..19 darwin 20+ since there are some differences (e.g earlier systems _must_ have the installation into / to work properly, the middle set can have either the / install or the --sysroot= case, and the set from darwin15+ must use the --sysroot= ) there could be cause to want to describe stuff for powerpc, i686, x86_64 and arm64 separately .. .. that was why a pointer to a new wiki page seemed possibly a better solution than much churn on the webpage.
[Bug target/105731] superfluous second operation before conditional branch -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105731
--- Comment #3 from Andrew Pinski ---
Combine:
Trying 41 -> 44:
41: r120:SI=r119:SI<<0x1a
REG_DEAD r119:SI
44: pc={(r120:SI<0)?L114:pc}
REG_BR_PROB 283038348
Failed to match this instruction:
(parallel [
(set (pc)
(if_then_else (ne (zero_extract:SI (reg:SI 119 [ _7 ])
(const_int 1 [0x1])
(const_int 5 [0x5]))
(const_int 0 [0]))
(label_ref 114)
(pc)))
(set (reg/v:SI 120 [ bits ])
(ashift:SI (reg:SI 119 [ _7 ])
(const_int 26 [0x1a])))
])
Failed to match this instruction:
(parallel [
(set (pc)
(if_then_else (ne (zero_extract:SI (reg:SI 119 [ _7 ])
(const_int 1 [0x1])
(const_int 5 [0x5]))
(const_int 0 [0]))
(label_ref 114)
(pc)))
(set (reg/v:SI 120 [ bits ])
(ashift:SI (reg:SI 119 [ _7 ])
(const_int 26 [0x1a])))
])
Failed to match this instruction:
(parallel [
(set (pc)
(if_then_else (ne (and:SI (lshiftrt:SI (reg:SI 119 [ _7 ])
(const_int 5 [0x5]))
(const_int 1 [0x1]))
(const_int 0 [0]))
(label_ref 114)
(pc)))
(set (reg/v:SI 120 [ bits ])
(ashift:SI (reg:SI 119 [ _7 ])
(const_int 26 [0x1a])))
])
Failed to match this instruction:
(parallel [
(set (pc)
(if_then_else (ne (and:SI (lshiftrt:SI (reg:SI 119 [ _7 ])
(const_int 5 [0x5]))
(const_int 1 [0x1]))
(const_int 0 [0]))
(label_ref 114)
(pc)))
(set (reg/v:SI 120 [ bits ])
(ashift:SI (reg:SI 119 [ _7 ])
(const_int 26 [0x1a])))
])
Successfully matched this instruction:
(set (reg/v:SI 120 [ bits ])
(ashift:SI (reg:SI 119 [ _7 ])
(const_int 26 [0x1a])))
Successfully matched this instruction:
(set (pc)
(if_then_else (ne (zero_extract:SI (reg:SI 119 [ _7 ])
(const_int 1 [0x1])
(const_int 5 [0x5]))
(const_int 0 [0]))
(label_ref 114)
(pc)))
allowing combination of insns 41 and 44
original costs 4 + 14 = 18
replacement costs 4 + 14 = 18
modifying insn i241: r120:SI=r119:SI<<0x1a
deferring rescan insn with uid = 41.
modifying insn i344:
{pc={(zero_extract(r119:SI,0x1,0x5)!=0)?L114:pc};clobber scratch;}
REG_DEAD r119:SI
REG_BR_PROB 283038348
deferring rescan insn with uid = 44.
The cost for the following instruction is wrong:
(jump_insn 113 110 114 13 (parallel [
(set (pc)
(if_then_else (eq (zero_extract:SI (reg:SI 119 [ _7 ])
(const_int 1 [0x1])
(const_int 5 [0x5]))
(const_int 0 [0]))
(label_ref 59)
(pc)))
(clobber (scratch:SI))
]) "/app/example.cpp":33:26 961 {*tbit_cbranch}
(expr_list:REG_DEAD (reg:SI 119 [ _7 ])
(int_list:REG_BR_PROB 457091900 (nil)))
-> 59)
It should be 18 since it gets splitted into two one which has a cost of 4 and
another which is a cost of 14.
[Bug target/105731] superfluous second operation before conditional branch -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105731 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-25 --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug fortran/104352] ICE in gfc_conv_intrinsic_anyall, at fortran/trans-intrinsic.cc:4481 (etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104352
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-05-25
Priority|P3 |P4
Ever confirmed|0 |1
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from kargl at gcc dot gnu.org ---
It make absolutely no sense to emit a warning when gfortran
detects an out-of-bounds array index. This patch fixes the
ICE and fixes the second error message to report that it is
the upper bound not the lower bound that errors out.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ebf076f730..52a394db26a 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -4754,19 +4754,19 @@ check_dimension (int i, gfc_array_ref *ar,
gfc_array_spec *as)
{
if (compare_bound (AR_START, as->lower[i]) == CMP_LT)
{
- gfc_warning (0, "Lower array reference at %L is out of bounds "
+ gfc_error ("Lower array reference at %L is out of bounds "
"(%ld < %ld) in dimension %d", &ar->c_where[i],
mpz_get_si (AR_START->value.integer),
mpz_get_si (as->lower[i]->value.integer), i+1);
- return true;
+ return false;
}
if (compare_bound (AR_START, as->upper[i]) == CMP_GT)
{
- gfc_warning (0, "Lower array reference at %L is out of bounds "
+ gfc_error ("Upper array reference at %L is out of bounds "
"(%ld > %ld) in dimension %d", &ar->c_where[i],
mpz_get_si (AR_START->value.integer),
mpz_get_si (as->upper[i]->value.integer), i+1);
- return true;
+ return false;
}
}
[Bug c++/105732] New: [REGRESSION] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 Bug ID: 105732 Summary: [REGRESSION] internal compiler error: unspellable token PADDING Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: linux_dr at yahoo dot com Target Milestone: --- Created attachment 53033 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53033&action=edit Source file, with no includes, exhibiting the issue. Regression appeared between 11.2.0 and 11.3.0. viewable online with "Compiler Explorer”: https://godbolt.org/z/bsenoqdjv g++ (Compiler-Explorer-Build-gcc--binutils-2.36.1) 11.3.0 Copyright (C) 2021 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. ===What we need=== Please include all of the following items, the first three of which can be obtained from the output of gcc -v: * the exact version of GCC: + g++ 11.3.0 * the system type: + x86_64-linux-gnu * the options given when GCC was configured/built: + From debug output: COLLECT_GCC=/opt/compiler-explorer/gcc-11.3.0/bin/g++ Target: x86_64-linux-gnu Configured with: ../gcc-11.3.0/configure --prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.36.1 Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.3.0 (Compiler-Explorer-Build-gcc--binutils-2.36.1) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-masm=intel' '-S' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/' * the complete command line that triggers the bug: + From debug output: /opt/compiler-explorer/gcc-11.3.0/bin/../libexec/gcc/x86_64-linux-gnu/11.3.0/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-11.3.0/bin/../lib/gcc/x86_64-linux-gnu/11.3.0/ -D_GNU_SOURCE -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext .cpp -masm=intel -mtune=generic -march=x86-64 -g -version -fdiagnostics-color=always -o /app/output.s * the compiler output (error messages, warnings, etc.): + (attached) * the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below). + As the bug appears to be in the preprocessor, I think the single source file may be sufficient: (attached) (It should also be included in the link above)
[Bug c++/105732] [REGRESSION] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 --- Comment #1 from Loren Osborn --- Created attachment 53034 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53034&action=edit Complete Compiler output Only allowed to attach one file to initial bug report
[Bug c++/105732] [REGRESSION] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 --- Comment #2 from Loren Osborn --- Just noting that this is my **THIRD** time submitting this bug. @jwakely had to come bail me out twice after spam assassin did it's thing. You may want to: 1) Turn down the sensitivity on spam assassin 2) Review the spam assassin logs to see what other bug reports may have been kicked out without a determined user following up.
[Bug c++/105732] [REGRESSION] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 --- Comment #3 from Andrew Pinski --- Confirmed. Reduced as much as I could: #define _VA_FEATURE_DETECT__3RD_ARG(_placeholder_1, _placeholder_2, value, ...) value # define _VA_FEATURE_OPT_DISAPPEARS 1 # define _VA_FEATURE_OPT_DISAPPEARS__VA_OPT__(_placeholder) 0 # define _VA_FEATURE_OPT_DETECT_UNEXPANDED(...) _VA_FEATURE_OPT_DISAPPEARS##__VA_OPT__(foo) # define _VA_FEATURE_OPT_DETECT_VERIFY_2_ARGS_TEST_ZERO(_placeholder_1, _placeholder_2) \ _VA_FEATURE_OPT_DETECT_UNEXPANDED() # define _VA_FEATURE_OPT_DETECT_1_OR_2_ARGS(_placeholder, ...) \ _VA_FEATURE_DETECT__3RD_ARG(__VA_ARGS__, \ _VA_FEATURE_OPT_DETECT_VERIFY_2_ARGS_TEST_ZERO, \ 0) # define _VA_FEATURE_OPT_DETECT_1_ARG(...) \ _VA_FEATURE_OPT_DETECT_1_OR_2_ARGS(bar, __VA_OPT__(, ))(__VA_OPT__(, )) # define _VA_FEATURE_OPT_DETECT_SUPPORTED _VA_FEATURE_OPT_DETECT_1_ARG(?) # if _VA_FEATURE_OPT_DETECT_SUPPORTED # endif
[Bug preprocessor/105732] [11/12/13 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Last reconfirmed||2022-05-25 Status|UNCONFIRMED |NEW Target Milestone|--- |11.4 Known to fail||11.3.0, 12.1.0, 13.0 Summary|[REGRESSION] internal |[11/12/13 Regression] |compiler error: unspellable |internal compiler error: |token PADDING |unspellable token PADDING Known to work||10.3.0, 11.2.0, 9.4.0 Ever confirmed|0 |1 Component|c++ |preprocessor
[Bug preprocessor/105732] [11/12/13 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 --- Comment #4 from Loren Osborn --- (*Comment lost in submit collision*) Just a couple last notes: 1) Go here first: https://godbolt.org/z/bsenoqdjv. (Easy to reproduce bug in a simple link.) 2) I filed this bug against 11.3.0, as that is when the regression appeared, but Compiler Explorer seems to show that this is still a current bug on trunk Regarding Andrew Pinski's shortening of the code sample, I mostly left the comments there for context. (I actually found this bug by accident: This code was never intended to run against GCC >= 8. Due to a bug in my code, I found this bug.) This is chopped down from a ~460 line header file already. I hope that helps!
[Bug preprocessor/105732] [11/12/13 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 Marek Polacek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- Started with r12-6155-g5545d1edcbdb17
[Bug preprocessor/105732] [11/12/13 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 --- Comment #6 from Loren Osborn --- This is unlikely to be helpful or relevant, but just in case, this is the source of the original code: https://developer.blender.org/D14947
[Bug preprocessor/105732] [11/12/13 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 --- Comment #7 from Andrew Pinski --- (In reply to Loren Osborn from comment #4) > 2) I filed this bug against 11.3.0, as that is when the regression appeared, > but Compiler Explorer seems to show that this is still a current bug on trunk Right, this is why there are "known to work" and "know to fail" fields that I filled out to reflect where the regression showed up and they will be updated when the bug gets fixed. The reported against version is good to have if we could not reproduce it right away.
[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 Andrew Pinski changed: What|Removed |Added Target Milestone|11.4|9.5 Known to fail||10.3.1, 9.4.1 Summary|[11/12/13 Regression] |[9/10/11/12/13 Regression] |internal compiler error:|internal compiler error: |unspellable token PADDING |unspellable token PADDING Severity|normal |blocker
[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 --- Comment #8 from Marek Polacek --- /* PR preprocessor/105732 */ #define m1(p1, p2, p3) p3 #define m2(p1, ...) 1##__VA_OPT__(foo) #define M(...) m1(1, 2, m2) #if M(,)(,) #endif
[Bug target/105733] New: riscv: Poor codegen for large stack frames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733
Bug ID: 105733
Summary: riscv: Poor codegen for large stack frames
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jrtc27 at jrtc27 dot com
Target Milestone: ---
Target: riscv*-*-*
For the following test:
#define BUF_SIZE 2064
void
foo(unsigned long i)
{
volatile char buf[BUF_SIZE];
buf[i] = 0;
}
GCC currently generates:
foo:
li t0,-4096
addit0,t0,2016
li a4,4096
add sp,sp,t0
li a5,-4096
addia4,a4,-2032
add a4,a4,a5
addia5,sp,16
add a5,a4,a5
add a0,a5,a0
li t0,4096
sd a5,8(sp)
sb zero,2032(a0)
addit0,t0,-2016
add sp,sp,t0
jr ra
whereas Clang generates the much shorter:
foo:
lui a1, 1
addiw a1, a1, -2016
sub sp, sp, a1
addia1, sp, 16
add a0, a0, a1
sb zero, 0(a0)
lui a0, 1
addiw a0, a0, -2016
add sp, sp, a0
ret
The:
li a4,4096
...
li a5,-4096
addia4,a4,-2032
add a4,a4,a5
sequence in particular is rather surprising to see rather than just li a4,-2032
and constant-folding that would halve the instruction count difference between
GCC and Clang alone.
See: https://godbolt.org/z/8EGc85dsf
[Bug c++/105722] [10 regression] std/ranges/adaptors/elements.cc fails after r10-10724-g93ec7bf2253061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105722 --- Comment #5 from seurer at gcc dot gnu.org --- I do not see it in my gcc 11 test runs.
[Bug c++/105734] New: Regression: Incorrect "error: invalid use of 'auto'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 Bug ID: 105734 Summary: Regression: Incorrect "error: invalid use of 'auto'" Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: llvm at rifkin dot dev Target Milestone: --- The following code errors erroneously: https://godbolt.org/z/68vYYj8cc A more minimal reproducible example is here: https://godbolt.org/z/f75Yx7K57. Interestingly the error only manifests in conjunction with the explicit destructor call. This came up in conjunction with a library doing a lot of TMP shenanigans, I will try to make a more minimal standalone reproducible example.
[Bug c++/105734] Regression: Incorrect "error: invalid use of 'auto'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 --- Comment #1 from Jeremy R. --- More minimal: https://godbolt.org/z/WcGab4W8T
[Bug c++/105734] Regression: Incorrect "error: invalid use of 'auto'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
namespace hh {
struct nothing {};
template
struct expression_decomposer {
auto h() {
return expression_decomposer();
}
};
}
template
void bar() {
auto m = hh::expression_decomposer( hh::expression_decomposer{}.h());
m.~expression_decomposer();
}
void foo() { bar(); }
[Bug c++/105734] Regression: Incorrect "error: invalid use of 'auto'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Reduced testcase:
> namespace hh {
> struct nothing {};
> template
> struct expression_decomposer {
> auto h() {
> return expression_decomposer();
> }
> };
> }
>
> template
> void bar() {
> auto m = hh::expression_decomposer( hh::expression_decomposer{}.h());
> m.~expression_decomposer();
> }
>
> void foo() { bar(); }
The namespace is really required here. If I remove it, it works ...
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.2 Summary|Regression: Incorrect |[12/13 Regression]: |"error: invalid use of |Incorrect "error: invalid |'auto'" |use of 'auto'" for explicit ||destructor inside a ||template Known to fail||12.1.0 Known to work||11.3.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-26 --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734
--- Comment #5 from Andrew Pinski ---
(In reply to Jeremy R. from comment #1)
> More minimal: https://godbolt.org/z/WcGab4W8T
>// only fails when this stuff is in a namespace, for some reason
You found that at the same time I did :).
Here is the most reduced testcase changing the names some more:
namespace hh {
struct nothing {};
template
struct s {
auto h() {
return s();
}
};
}
template
void bar() {
auto m = hh::s( hh::s{}.h());
m.~s();
}
void foo() { bar(); }
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734
--- Comment #6 from Andrew Pinski ---
A little more reduced:
namespace hh {
struct nothing {};
template
struct s {
s h();
};
}
template
void bar() {
auto m = hh::s(hh::s{}.h());
m.~s();
}
void foo() { bar<1>(); }
The template arguments can be the same even.
[Bug target/105733] riscv: Poor codegen for large stack frames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-26 --- Comment #1 from Kito Cheng --- Confirmed, Thanks for reporting this!
