[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 --- Comment #9 from Richard Biener --- So just to say all versions seem to be affected and the issue is just latent because of the rev we bisected to.
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Jakub Jelinek ---
Seems to be fixed by the PR113921 fix. But more test coverage doesn't hurt, so
2024-02-15 Jakub Jelinek
PR middle-end/107385
* gcc.target/i386/pr107385.c: New test.
--- gcc/testsuite/gcc.target/i386/pr107385.c.jj 2024-01-13 00:05:00.077372302
+0100
+++ gcc/testsuite/gcc.target/i386/pr107385.c2024-02-15 09:18:47.711260427
+0100
@@ -0,0 +1,20 @@
+/* PR middle-end/107385 */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+__attribute__((noipa)) int
+foo (void)
+{
+ int x;
+ asm goto ("": "=r" (x) : "0" (15), "a" (42) :: lab);
+ x = 6;
+lab:
+ return x;
+}
+
+int
+main ()
+{
+ if (foo () != 6)
+__builtin_abort ();
+}
*** This bug has been marked as a duplicate of bug 113921 ***
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 --- Comment #10 from Jakub Jelinek --- *** Bug 107385 has been marked as a duplicate of this bug. ***
[Bug target/113856] `(vect64 float){1.0f, 0}` code generation could just be `fmov sN, 1.0f`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113856
--- Comment #3 from Andrew Pinski ---
I should note that the one place where `{1.0, 0.0}` shows up is the use with
complex :). I found it on accident while understanding why I was getting a
failure with `libgomp.c-c++-common/reduction-*.c` where I would also match on
accident `{1.0, 0.0, 1.0, 0.0}`.
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56 --- Comment #13 from Richard Biener --- I didn't add STMT_VINFO_SLP_VECT_ONLY, I'm quite sure we can now do both SLP of masked loads and stores, so yes, STMT_VINFO_SLP_VECT_ONLY (when we formed a DR group of stmts we cannot combine without SLP as the masks are not equal) should be set for both loads and stores. The can_group_stmts_p checks as present seem correct here (but the dump should not say "Load" but maybe "Access") So it looks like the issue is with "late" deciding we can't actually do the masked SLP store (why?) and the odd "vect_dissolve_slp_only_groups" and then somehow botching strided store code-gen which likely doesn't expect masks or should have disabled fully masking? I'll note that we don't support single element interleaving for stores, so vect_analyze_group_access_1 would have falled back to STMT_VINFO_STRIDED_P. But as said, maybe that somehow misses to disable loop masking then when vect_analyze_loop_operations? So what's the testcase comment#9 talks about?
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 --- Comment #18 from Jonathan Wakely --- See http://cplusplus.github.io/LWG/lwg-active.html#submit_issue
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #14 from Tamar Christina ---
(In reply to Richard Biener from comment #13)
> I didn't add STMT_VINFO_SLP_VECT_ONLY, I'm quite sure we can now do both SLP
> of masked loads and stores, so yes, STMT_VINFO_SLP_VECT_ONLY (when we formed
> a DR group of stmts we cannot combine without SLP as the masks are not equal)
> should be set for both loads and stores.
>
> The can_group_stmts_p checks as present seem correct here (but the dump
> should not say "Load" but maybe "Access")
I guess I'm wondering because of this usage:
/* Check that the data-refs have same first location (except init)
and they are both either store or load (not load and store,
not masked loads or stores). */
if (DR_IS_READ (dra) != DR_IS_READ (drb)
|| data_ref_compare_tree (DR_BASE_ADDRESS (dra),
DR_BASE_ADDRESS (drb)) != 0
|| data_ref_compare_tree (DR_OFFSET (dra), DR_OFFSET (drb)) != 0
|| !can_group_stmts_p (stmtinfo_a, stmtinfo_b, true))
break;
We don't exit there now for non-SLP.
>
> So what's the testcase comment#9 talks about?
You should be able to reproduce it with:
---
typedef __SIZE_TYPE__ size_t;
typedef signed char int8_t;
typedef unsigned short uint16_t ;
void __attribute__((noinline, noclone))
test_i8_i8_i16_2(int8_t *__restrict dest, int8_t *__restrict src,
uint16_t *__restrict cond, size_t n) {
for (size_t i = 0; i < n; ++i) {
if (cond[i] < 8)
dest[i * 2] = src[i];
if (cond[i] > 2)
dest[i * 2 + 1] = src[i];
}
}
void __attribute__((noinline, noclone))
test_i8_i8_i16_2_1(volatile int8_t * dest, volatile int8_t * src,
volatile uint16_t * cond, size_t n) {
#pragma GCC novector
for (size_t i = 0; i < n; ++i) {
if (cond[i] < 8)
dest[i * 2] = src[i];
if (cond[i] > 2)
dest[i * 2 + 1] = src[i];
}
}
#define size 16
int8_t srcarray[size];
uint16_t maskarray[size];
int8_t destarray[size*2];
int8_t destarray1[size*2];
int main()
{
#pragma GCC novector
for(int i = 0; i < size; i++)
{
maskarray[i] = i == 10 ? 0 : (i == 5 ? 9 : (2*i) & 0xff);
srcarray[i] = i;
}
#pragma GCC novector
for(int i = 0; i < size*2; i++)
{
destarray[i] = i;
destarray1[i] = i;
}
test_i8_i8_i16_2(destarray, srcarray, maskarray, size);
test_i8_i8_i16_2_1(destarray1, srcarray, maskarray, size);
#pragma GCC novector
for(int i = 0; i < size*2; i++)
{
if (destarray[i] != destarray1[i])
__builtin_abort();
}
}
---
since really only one of the functions needs to vectorize.
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56 --- Comment #15 from Tamar Christina --- and just -O3 -march=armv8-a+sve
[Bug tree-optimization/113774] wrong code with _BitInt() arithmetics at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113774 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/113783] ICE: in lower_stmt, at gimple-lower-bitint.cc:5455 with -O -mavx512f and _BitInt() in memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113783 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/113567] ICE: SSA corruption: Unable to coalesce ssa_names 1 and 3 which are marked as MUST COALESCE. with _BitInt() and computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113567 --- Comment #5 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:baa40971d1600672f3a1abf688905a70cf655c92 commit r14-8995-gbaa40971d1600672f3a1abf688905a70cf655c92 Author: Jakub Jelinek Date: Thu Feb 15 09:52:47 2024 +0100 lower-bitint: Ensure we don't get coalescing ICEs for (ab) SSA_NAMEs used in mul/div/mod [PR113567] The build_bitint_stmt_ssa_conflicts hook has a special case for multiplication, division and modulo, where to ensure there is no overlap between lhs and rhs1/rhs2 arrays we make the lhs conflict with the operands. On the following testcase, we have # a_1(ab) = PHI lab: a_3(ab) = a_1(ab) % 3; before lowering and this special case causes a_3(ab) and a_1(ab) to conflict, but the PHI requires them not to conflict, so we ICE because we can't find some partitioning that will work. The following patch fixes this by special casing such statements before the partitioning, force the inputs of the multiplication/division which have large/huge _BitInt (ab) lhs into new non-(ab) SSA_NAMEs initialized right before the multiplication/division. This allows the partitioning to work then, as it has the possibility to use a different partition for the */% operands. 2024-02-15 Jakub Jelinek PR tree-optimization/113567 * gimple-lower-bitint.cc (gimple_lower_bitint): For large/huge _BitInt multiplication, division or modulo with SSA_NAME_OCCURS_IN_ABNORMAL_PHI lhs and at least one of rhs1 and rhs2 force the affected inputs into a new SSA_NAME. * gcc.dg/bitint-90.c: New test.
[Bug tree-optimization/113567] ICE: SSA corruption: Unable to coalesce ssa_names 1 and 3 which are marked as MUST COALESCE. with _BitInt() and computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113567 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug target/31679] Incorrect result of multiplication long long by 0xFFFFFFFFLL constant.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31679 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > HWI is always 64bit these days so I doubt this can be reproduced. Plus The tree level uses wide_int so maybe this was fixed
[Bug testsuite/113899] Vect module test failures while running on remote host due to default dg-do set to compile and additional-sources being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899 --- Comment #6 from sadineniharish8446 at gmail dot com --- After adding given patch, vect-simd-clone-10.c & vect-simd-clone-12.c test case were not running the below error observed in gcc.sum, ERROR: tcl error sourcing /poky/build-st/tmp/work-shared/gcc-13.2.0-r0/gcc-13.2.0/gcc/testsuite/gcc.dg/vect/vect.exp. ERROR: tcl error code NONE UNRESOLVED: testcase '/poky/build-st/tmp/work-shared/gcc-13.2.0-r0/gcc-13.2.0/gcc/testsuite/gcc.dg/vect/vect.exp' aborted due to Tcl error Also as you said in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899#c3 (Maybe the run testcases are failing but you might not be noticing that.), I have gone through summary file and i checked a few 'dg-do run' tests and those were marked as unresolved. We have observed some failure from the gcc.log as below, Executing on ssh: mkdir -p /tmp/runtest.3549458 (timeout = 300) spawn [open ...]^M kex_exchange_identification: read: Connection reset by peer^M Connection reset by 192.168.7.2 port 22^M ERROR: Couldn't create remote directory /tmp/runtest.3549458 on ssh Download of ./sse_hw_available3549458.exe to ssh failed. Executing on ssh: mkdir -p /tmp/runtest.1880844 (timeout = 300) spawn [open ...]^M Host key verification failed.^M ERROR: Couldn't create remote directory /tmp/runtest.1880844 on ssh Download of ./sse2_hw_available1880844.exe to ssh failed. what could be the reason for this and how can we fix this? .
[Bug testsuite/113899] Vect module test failures while running on remote host due to default dg-do set to compile and additional-sources being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899 --- Comment #7 from Andrew Pinski --- (In reply to sadineniharish8446 from comment #6) > Also as you said in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899#c3 > (Maybe the run testcases are failing but you might not be noticing that.), > I have gone through summary file and i checked a few 'dg-do run' tests and > those were marked as unresolved. We have observed some failure from the > gcc.log as below, > Executing on ssh: mkdir -p /tmp/runtest.3549458 (timeout = 300) > spawn [open ...]^M > kex_exchange_identification: read: Connection reset by peer^M > Connection reset by 192.168.7.2 port 22^M > ERROR: Couldn't create remote directory /tmp/runtest.3549458 on ssh > Download of ./sse_hw_available3549458.exe to ssh failed. > > Executing on ssh: mkdir -p /tmp/runtest.1880844 (timeout = 300) > spawn [open ...]^M > Host key verification failed.^M > ERROR: Couldn't create remote directory /tmp/runtest.1880844 on ssh > Download of ./sse2_hw_available1880844.exe to ssh failed. > > what could be the reason for this and how can we fix this? . Well it is ssh that is failing so you need to check why ssh to the host is no longer working. Note one trick is to use one ssh connection but multiple sessions which should speed up things. See https://tutonics.com/articles/allow-multiple-ssh-sessions-over-an-existing-connection/ for more info on that.
[Bug target/50440] 128 bit unsigned int subtraction generates too many register moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50440 Andrew Pinski changed: What|Removed |Added CC||sayle at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- The trunk we get: ``` sub: xchgq %rdi, %rsi movq%rdx, %r8 movq%rsi, %rax movq%rdi, %rdx subq%r8, %rax sbbq%rcx, %rdx ret ``` There still seems to be too many movq going on compared to LLVM even.
[Bug middle-end/112639] Incorrect handling of __builtin_c[lt]zg argument side-effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112639 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug other/113927] New: [avr-tiny] Sets up a stack-frame even for trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113927
Bug ID: 113927
Summary: [avr-tiny] Sets up a stack-frame even for trivial code
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Code like
char func (char c)
{
return c;
}
compiles as expected to
func:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
/* epilogue start */
ret
with avr-gcc -S -Os -mmcu=attiny26 -da , but for attiny40 (Reduced Tiny with
16 GPRs only) the result is:
func:
push r28
push r29
push __tmp_reg__
in r28,__SP_L__
in r29,__SP_H__
/* prologue: function */
/* frame size = 1 */
/* stack size = 3 */
.L__stack_usage = 3
/* epilogue start */
pop __tmp_reg__
pop r29
pop r28
ret
In .asmcons, i.e. just prior to register allocation, the code reads:
(insn 13 4 2 2 (set (reg:QI 46)
(reg:QI 24 r24 [ c ])) "main.c":2:1 86 {movqi_insn_split}
(expr_list:REG_DEAD (reg:QI 24 r24 [ c ])
(nil)))
(insn 2 13 3 2 (set (reg/v:QI 44 [ c ])
(reg:QI 46)) "main.c":2:1 86 {movqi_insn_split}
(expr_list:REG_DEAD (reg:QI 46)
(nil)))
(note 3 2 10 2 NOTE_INSN_FUNCTION_BEG)
(insn 10 3 11 2 (set (reg/i:QI 24 r24)
(reg/v:QI 44 [ c ])) "main.c":4:1 86 {movqi_insn_split}
(expr_list:REG_DEAD (reg/v:QI 44 [ c ])
(nil)))
(insn 11 10 0 2 (use (reg/i:QI 24 r24)) "main.c":4:1 -1
(nil))
so everything is fine and this PR is not a dup of PR110093. According to
Vladimir Makarov, PR110093 is because DFA cannot handle subregs, but the RTL
code above does not have subregs. What's the case is that IRA has very high
register costs, for example in .ira:
Pass 0 for finding pseudo/allocno costs
a1 (r46,l0) best NO_REGS, allocno NO_REGS
a0 (r44,l0) best NO_REGS, allocno NO_REGS
a0(r44,l0) costs: POINTER_X_REGS:65535000 POINTER_Y_REGS:65535000
POINTER_Z_REGS:65535000 BASE_POINTER_REGS:65535000 POINTER_REGS:65535000
SIMPLE_LD_REGS:65535000 GENERAL_REGS:65535000 MEM:3000
whereas the .ira for attiny26 (ordinary core with 32 GPRs):
Pass 0 for finding pseudo/allocno costs
a0 (r46,l0) best GENERAL_REGS, allocno GENERAL_REGS
a0(r46,l0) costs: POINTER_X_REGS:4000 POINTER_Y_REGS:4000 POINTER_Z_REGS:4000
BASE_POINTER_REGS:4000 POINTER_REGS:4000 ADDW_REGS:4000 SIMPLE_LD_REGS:4000
LD_REGS:4000 NO_LD_REGS:4000 GENERAL_REGS:4000 MEM:4000
../../source/gcc-master/configure --target=avr --disable-nls --with-dwarf2
--with-gnu-as --with-gnu-ld --disable-shared --enable-languages=c,c++
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-15 Status|UNCONFIRMED |NEW
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #17 from Erhard F. --- Sidenote: Interestingly GCC 14 builds fine with -mcpu=970 -mtune=970 despite the PowerPC G5 (aka. 970, POWER4+) is before ISA 2.06 and not being able to use -mvsx either. I used Gentoo snapshot gcc-14.0.1_pre20240211-r1.
[Bug fortran/113928] New: Aliasing of pointer in expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113928 Bug ID: 113928 Summary: Aliasing of pointer in expression Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: eddyg_61-bugzilla at yahoo dot it Target Milestone: --- I think that this program gives an erroneous result: program wzerror implicit none integer, parameter :: N = 20 complex, target :: wz(N) real, pointer :: wr(:) integer :: i wr => wz%re wz = 0 wr = [(i,i=1,N)] wr = wr + wz(N:1:-1)%re print *, wr end program It doesn't recognize the aliasing in the expression that should be allowed when pointers are involved. I'm expecting a list of '21'. But this is not the case. I couldn't test on a more recent compiler.
[Bug tree-optimization/113910] [12/13 Regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #16 from Richard Biener --- OK, thanks for checking. Btw, -ftime-report for GCC 11 has different bottle-necks meanwhile fixed: tree PTA : 1.66 ( 3%) tree SSA incremental : 31.86 ( 61%) TOTAL : 52.08 but it had a bit less bloated PTA. I now have tree PTA : 12.21 ( 35%) tree SSA incremental : 3.96 ( 11%) TOTAL : 35.24 on trunk. I guess with bitmaps it always also depends on the memory hierarchy of the machine, nevertheless overall it looks fine on SPARC then. Queued for backporting, some RFC for further improvements on bitmap_hash is on the mailing list but I'm not going to backport that.
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #16 from Richard Biener --- OK, so the missed SLP is a known one: t.c:8:26: note: starting SLP discovery for node 0x5d42840 t.c:8:26: note: Build SLP for _27 = _3 <= 7; t.c:8:26: note: precomputed vectype: vector([8,8]) t.c:8:26: note: nunits = [8,8] t.c:8:26: note: Build SLP for _14 = _3 > 2; t.c:8:26: note: precomputed vectype: vector([8,8]) t.c:8:26: note: nunits = [8,8] t.c:8:26: missed: Build SLP failed: different operation in stmt _14 = _3 > 2; t.c:8:26: missed: original stmt _27 = _3 <= 7; I'm not sure we can do this with a single vector stmt but of course using 'two_operator' support might be possible here (do both > and <= and then blend the result). I see we end up using .MASK_STORE_LANES in the end but we're not using load-lanes. t.c:8:26: note: ==> examining pattern statement: .MASK_STORE (_5, 8B, patt_12, pretmp_29); t.c:8:26: note: vect_is_simple_use: operand () _27, type of def: internal t.c:8:26: note: vect_is_simple_use: vectype vector([16,16]) t.c:8:26: note: vect_is_simple_use: operand *_28, type of def: internal t.c:8:26: note: vect_is_simple_use: vectype vector([16,16]) signed char t.c:8:26: missed: cannot use vec_mask_len_store_lanes t.c:8:26: note: can use vec_mask_store_lanes t.c:8:26: note: vect_is_simple_use: operand *_28, type of def: internal t.c:8:26: missed: cannot use vec_mask_len_store_lanes t.c:8:26: note: can use vec_mask_store_lanes ... t.c:8:26: note: ==> examining pattern statement: .MASK_STORE (_9, 8B, patt_4, pretmp_29); t.c:8:26: note: vect_is_simple_use: operand () _14, type of def: internal t.c:8:26: note: vect_is_simple_use: vectype vector([16,16]) t.c:8:26: note: vect_is_simple_use: operand *_28, type of def: internal t.c:8:26: note: vect_is_simple_use: vectype vector([16,16]) signed char t.c:8:26: missed: cannot use vec_mask_len_store_lanes t.c:8:26: note: can use vec_mask_store_lanes t.c:8:26: missed: cannot use vec_mask_len_store_lanes t.c:8:26: note: can use vec_mask_store_lanes and somehow transform decides to put the two stores together again, probably missing to verify the masks are the same. I'll dig a bit more after lunch.
[Bug c++/113802] gcc rejects auto f(this auto self...) { }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org,
||waffl3x at protonmail dot com
--- Comment #1 from Jakub Jelinek ---
The problem is that as the comment says, when next token is ellipsis, it isn't
at that point clear if it will be a parameter pack or the odd varargs case
without , before ellipsis.
I've tried
--- gcc/cp/parser.cc.jj 2024-02-14 14:26:19.0 +0100
+++ gcc/cp/parser.cc2024-02-15 11:07:01.706650134 +0100
@@ -25727,17 +25727,10 @@ cp_parser_parameter_declaration (cp_pars
bool const xobj_param_p
= decl_spec_seq_has_spec_p (&decl_specifiers, ds_this);
- if (xobj_param_p
- && ((declarator && declarator->parameter_pack_p)
- || cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS)))
+ bool diag_xobj_parameter_pack = false;
+ if (xobj_param_p && (declarator && declarator->parameter_pack_p))
{
- location_t xobj_param
- = make_location (decl_specifiers.locations[ds_this],
-decl_spec_token_start->location,
-input_location);
- error_at (xobj_param,
- "an explicit object parameter cannot "
- "be a function parameter pack");
+ diag_xobj_parameter_pack = true;
/* Suppress errors that occur down the line. */
if (declarator)
declarator->parameter_pack_p = false;
@@ -25755,9 +25748,10 @@ cp_parser_parameter_declaration (cp_pars
(INNERMOST_TEMPLATE_PARMS (current_template_parms));
if (latest_template_parm_idx != template_parm_idx)
- decl_specifiers.type = convert_generic_types_to_packs
- (decl_specifiers.type,
- template_parm_idx, latest_template_parm_idx);
+ decl_specifiers.type
+ = convert_generic_types_to_packs (decl_specifiers.type,
+ template_parm_idx,
+ latest_template_parm_idx);
}
if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
@@ -25775,18 +25769,34 @@ cp_parser_parameter_declaration (cp_pars
{
/* Consume the `...'. */
cp_lexer_consume_token (parser->lexer);
- maybe_warn_variadic_templates ();
-
- /* Build a pack expansion type */
- if (template_parm_p)
- template_parameter_pack_p = true;
- else if (declarator)
- declarator->parameter_pack_p = true;
+ if (xobj_param_p)
+ diag_xobj_parameter_pack = true;
else
- decl_specifiers.type = make_pack_expansion (type);
+ {
+ maybe_warn_variadic_templates ();
+
+ /* Build a pack expansion type */
+ if (template_parm_p)
+ template_parameter_pack_p = true;
+ else if (declarator)
+ declarator->parameter_pack_p = true;
+ else
+ decl_specifiers.type = make_pack_expansion (type);
+ }
}
}
+ if (diag_xobj_parameter_pack)
+{
+ location_t xobj_param
+ = make_location (decl_specifiers.locations[ds_this],
+decl_spec_token_start->location,
+input_location);
+ error_at (xobj_param,
+ "an explicit object parameter cannot "
+ "be a function parameter pack");
+}
+
/* The restriction on defining new types applies only to the type
of the parameter, not to the default argument. */
parser->type_definition_forbidden_message = saved_message;
and that causes
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 27)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 36)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 47)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 56)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 67)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 76)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 87)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 96)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 107)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 116)
where presumably those lines are valid, not invalid, but I'm not sure and
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:32:22:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-dia
[Bug c++/113802] gcc rejects auto f(this auto self...) { }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2024-02-15 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 57432 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57432&action=edit gcc14-pr113802.patch Ah, this seems to work.
[Bug ada/113877] gnatchop -c puts gnat.adc in the current working directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877 --- Comment #3 from simon at pushface dot org --- I’ve now found the related documentation[1]. I think the conclusion is that gnatchop is working-as-designed, and that this PR should be marked WONTFIX (or INVALID), as seems best. Sorry for the noise. [1] https://docs.adacore.com/live/wave/gnat_ugn/html/gnat_ugn/gnat_ugn/the_gnat_compilation_model.html#operating-gnatchop-in-compilation-mode
[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744 --- Comment #15 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c9ce332b557bb95987d038d98ea929cdfd1eae1d commit r14-8998-gc9ce332b557bb95987d038d98ea929cdfd1eae1d Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Use 128-bit arithmetic for std::linear_congruential_engine [PR87744] For 32-bit targets without __int128 we need to implement the LCG transition function by hand using 64-bit types. We can also slightly simplify the __mod function by using if-constexpr unconditionally, disabling -Wc++17-extensions warnings with diagnostic pragmas. libstdc++-v3/ChangeLog: PR libstdc++/87744 * include/bits/random.h [!__SIZEOF_INT128__] (_Select_uint_least_t): Define specialization for 64-bit generators with non-power-of-two modulus and large constants. (__mod): Use if constexpr unconditionally. * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line number. * testsuite/26_numerics/random/linear_congruential_engine/87744.cc: New test.
[Bug libstdc++/99117] [11/12/13/14 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117 --- Comment #23 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b58f0e5216a3053486e7f1aa96c3f2443b14d630 commit r14-9000-gb58f0e5216a3053486e7f1aa96c3f2443b14d630 Author: Jonathan Wakely Date: Thu Feb 8 13:59:42 2024 + libstdc++: Avoid aliasing violation in std::valarray [PR99117] The call to __valarray_copy constructs an _Array object to refer to this->_M_data but that means that accesses to this->_M_data are through a restrict-qualified pointer. This leads to undefined behaviour when copying from an _Expr object that actually aliases this->_M_data. Replace the call to __valarray_copy with a plain loop. I think this removes the only use of that overload of __valarray_copy, so it could probably be removed. I haven't done that here. libstdc++-v3/ChangeLog: PR libstdc++/99117 * include/std/valarray (valarray::operator=(const _Expr&)): Use loop to copy instead of __valarray_copy with _Array. * testsuite/26_numerics/valarray/99117.cc: New test.
[Bug libstdc++/113811] std::rotate does 64-bit signed division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113811 --- Comment #4 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4d819db7f229a23cb15ef68f310e0bb51d201c45 commit r14-9001-g4d819db7f229a23cb15ef68f310e0bb51d201c45 Author: Jonathan Wakely Date: Thu Feb 8 15:40:32 2024 + libstdc++: Use unsigned division in std::rotate [PR113811] Signed 64-bit division is much slower than unsigned, so cast the n and k values to unsigned before doing n %= k. We know this is safe because neither value can be negative. libstdc++-v3/ChangeLog: PR libstdc++/113811 * include/bits/stl_algo.h (__rotate): Use unsigned values for division.
[Bug libstdc++/113806] [performance] bitset::operator>>= unnecessarily sanitizes the high-word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113806 --- Comment #1 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bf883e6428a545d091319c8b71fcfb35e7dd7084 commit r14-9003-gbf883e6428a545d091319c8b71fcfb35e7dd7084 Author: Jonathan Wakely Date: Thu Feb 8 15:47:19 2024 + libstdc++: Remove redundant zeroing in std::bitset::operator>>= [PR113806] The unused bits in the high word are already zero before this operation. Shifting the used bits to the right cannot affect the unused bits, so we don't need to sanitize them. libstdc++-v3/ChangeLog: PR libstdc++/113806 * include/std/bitset (bitset::operator>>=): Remove redundant call to _M_do_sanitize.
[Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807 --- Comment #2 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e7ae13a858f36031b8fd3aa07362752ff2b19b2e commit r14-9002-ge7ae13a858f36031b8fd3aa07362752ff2b19b2e Author: Jonathan Wakely Date: Thu Feb 8 15:46:08 2024 + libstdc++: Use memset to optimize std::bitset::set() [PR113807] As pointed out in the PR we already do this for reset(). libstdc++-v3/ChangeLog: PR libstdc++/113807 * include/std/bitset (bitset::set()): Use memset instead of a loop over the individual words.
[Bug ada/113877] gnatchop -c puts gnat.adc in the current working directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877 Eric Botcazou changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Eric Botcazou --- Thanks for investigating this.
[Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807 --- Comment #3 from rhalbersma --- Nice that this is changed now. I noticed a similar optimization could be done for bitset::operator== (more accurately: the helper _M_is_equal) where there is an opportunity to use memcmp, with a similar dance for consteval contexts. MSVC STL also does this.
[Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0 --- Comment #4 from Jonathan Wakely --- I'm surprised the compiler can't optimize _M_do_set() and operator== already, but it looks like it doesn't recognize the trivial loops.
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #17 from Richard Biener ---
I think the following fixes it, can you verify the runtime (IL looks sane, but
it uses masked scatter stores).
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 9e26b09504d..5a5865c42fc 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -2551,7 +2551,8 @@ vect_dissolve_slp_only_groups (loop_vec_info loop_vinfo)
FOR_EACH_VEC_ELT (datarefs, i, dr)
{
gcc_assert (DR_REF (dr));
- stmt_vec_info stmt_info = loop_vinfo->lookup_stmt (DR_STMT (dr));
+ stmt_vec_info stmt_info
+ = vect_stmt_to_vectorize (loop_vinfo->lookup_stmt (DR_STMT (dr)));
/* Check if the load is a part of an interleaving chain. */
if (STMT_VINFO_GROUPED_ACCESS (stmt_info))
[Bug libstdc++/113806] [performance] bitset::operator>>= unnecessarily sanitizes the high-word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113806 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Fixed for 14, thanks for the suggestion.
[Bug libstdc++/113811] std::rotate does 64-bit signed division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113811 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |14.0 --- Comment #5 from Jonathan Wakely --- Fixed for gcc-14, thanks for the suggestion.
[Bug middle-end/113508] widen_ssumm3 documentation needs to mention which mode is m here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113508
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:5329b94188206e9f8c96d9a63931c415fa5d39d7
commit r14-9006-g5329b94188206e9f8c96d9a63931c415fa5d39d7
Author: Andrew Pinski
Date: Wed Feb 14 14:29:22 2024 -0800
doc: Add documentation of which operand matches the mode of the standard
pattern name [PR113508]
In some of the standard pattern names, it is not obvious which mode is
being used in the pattern
name. Is it operand 0, 1, or 2? Is it the wider mode or the narrower mode?
This fixes that so there is no confusion by adding a sentence to some of
them.
Built the documentation to make sure that it builds.
gcc/ChangeLog:
PR middle-end/113508
* doc/md.texi (sdot_prod@var{m}, udot_prod@var{m},
usdot_prod@var{m}, ssad@var{m}, usad@var{m}, widen_usum@var{m}3,
smulhs@var{m}3, umulhs@var{m}3, smulhrs@var{m}3, umulhrs@var{m}3):
Add sentence about what the mode m is.
Signed-off-by: Andrew Pinski
[Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
For
unsigned int a[1024];
void
foo (void)
{
for (int i = 0; i < 1024; ++i)
a[i] = 0;
}
void
bar (void)
{
for (int i = 0; i < 1024; ++i)
a[i] = -1;
}
it certainly can.
[Bug middle-end/113508] widen_ssumm3 documentation needs to mention which mode is m here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113508 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 --- Comment #5 from Andrew Pinski --- Fixed.
[Bug other/113927] [avr-tiny] Sets up a stack-frame even for trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113927 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug debug/113918] Incomplete DWARF5 debug information for anonymous unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113918 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 57433 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57433&action=edit gcc14-pr113918.patch Untested patch to emit DW_AT_export_symbols for those cases. That said, I believe GDB must have some code to handle anonymous structs/unions even without that, because e.g. on this new testcase p s.i just works even without the patch (and after all, should even in DWARF4 and earlier where such attribute wasn't there at all).
[Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807 --- Comment #6 from Richard Biener --- It can also for an effective memset to a non-constant, but it has to be uniform, thus 'char'.
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #18 from Richard Biener ---
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 7cf9504398c..8deeecfd4aa 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -1280,8 +1280,11 @@ vect_build_slp_tree_1 (vec_info *vinfo, unsigned char
*swap,
&& rhs_code.is_tree_code ()
&& (TREE_CODE_CLASS (tree_code (first_stmt_code))
== tcc_comparison)
- && (swap_tree_comparison (tree_code (first_stmt_code))
- == tree_code (rhs_code)))
+ && ((swap_tree_comparison (tree_code (first_stmt_code))
+== tree_code (rhs_code))
+ || ((TREE_CODE_CLASS (tree_code (alt_stmt_code))
+== tcc_comparison)
+ && rhs_code == alt_stmt_code)))
&& !(STMT_VINFO_GROUPED_ACCESS (stmt_info)
&& (first_stmt_code == ARRAY_REF
|| first_stmt_code == BIT_FIELD_REF
should get you SLP but:
t.c:8:26: note: === vect_slp_analyze_operations ===
t.c:8:26: note: ==> examining statement: pretmp_29 = *_28;
t.c:8:26: missed: unsupported load permutation
t.c:10:30: missed: not vectorized: relevant stmt not supported: pretmp_29 =
*_28;
t.c:8:26: note: op template: pretmp_29 = *_28;
t.c:8:26: note: stmt 0 pretmp_29 = *_28;
t.c:8:26: note: stmt 1 pretmp_29 = *_28;
t.c:8:26: note: load permutation { 0 0 }
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 Jakub Jelinek changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #3 from Jakub Jelinek --- Actually, the "a" constraint isn't needed there at all and without it it can be used on other targets. Like it fails on aarch64 without the patch the same.
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385
--- Comment #4 from Jakub Jelinek ---
So
2024-02-15 Jakub Jelinek
PR middle-end/107385
* gcc.dg/pr107385.c: New test.
--- gcc/testsuite/gcc.dg/pr107385.c.jj 2024-01-13 00:05:00.077372302 +0100
+++ gcc/testsuite/gcc.dg/pr107385.c 2024-02-15 09:18:47.711260427 +0100
@@ -0,0 +1,20 @@
+/* PR middle-end/107385 */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+__attribute__((noipa)) int
+foo (void)
+{
+ int x;
+ asm goto ("": "=r" (x) : "0" (15) :: lab);
+ x = 6;
+lab:
+ return x;
+}
+
+int
+main ()
+{
+ if (foo () != 6)
+__builtin_abort ();
+}
[Bug other/113927] [avr-tiny] Sets up a stack-frame even for trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113927 --- Comment #1 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:5cff288c2dae4ea709df067cf398f23e214b2e80 commit r14-9009-g5cff288c2dae4ea709df067cf398f23e214b2e80 Author: Georg-Johann Lay Date: Thu Feb 15 13:53:34 2024 +0100 AVR: target 113927 - Simple code triggers stack frame for Reduced Tiny. The -mmcu=avrtiny cores have no ADIW and SBIW instructions. This was implemented by clearing all regs out of regclass ADDW_REGS so that constraint "w" never matched. This corrupted the subset relations of the register classes as they appear in enum reg_class. This patch keeps ADDW_REGS like for all other cores, i.e. it contains R24...R31. Instead of tests like test_hard_reg_class (ADDW_REGS, *) the code now uses avr_adiw_reg_p (*). And all insns with constraint "w" get "isa" insn attribute value of "adiw". Plus, a new built-in macro __AVR_HAVE_ADIW__ is provided, which is more specific than __AVR_TINY__. gcc/ PR target/113927 * config/avr/avr.h (AVR_HAVE_ADIW): New macro. * config/avr/avr-protos.h (avr_adiw_reg_p): New proto. * config/avr/avr.cc (avr_adiw_reg_p): New function. (avr_conditional_register_usage) [AVR_TINY]: Don't clear ADDW_REGS. Replace test_hard_reg_class (ADDW_REGS, ...) with calls to * config/avr/avr.md: Same. (attr "isa") : Remove. : Add. (define_insn, define_insn_and_split): When an alternative has constraint "w", then set attribute "isa" to "adiw". * config/avr/avr-c.cc (avr_cpu_cpp_builtins) [AVR_HAVE_ADIW]: Built-in define __AVR_HAVE_ADIW__. * doc/invoke.texi (AVR Options): Document it.
[Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807 --- Comment #7 from Jonathan Wakely --- Hmm, yes, the code for bitset::set() is actually similar to what we get for foo() in comment 5. The new version with memset does produce different (vectorized?) code though. For operator== the current code is quite branchy, and looks better with memcmp to me (but I don't really know what I'm talking about).
[Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807 --- Comment #8 from rhalbersma --- For bitset::operator==, I wonder why (at last in C++20 and later mode) it is not defaulted? For bitset::set and bitset::operator==, I also wonder why the manual loop vs memset/memcmp consteval logic is not delegated to a call of std::fill_n or std::equal, respectively? Then std::bitset is better proofed against future changes in the tradeoffs between manual loops, unrolled loops or library calls, no?
[Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807 --- Comment #9 from Jonathan Wakely --- (In reply to rhalbersma from comment #8) > For bitset::operator==, I wonder why (at last in C++20 and later mode) it is > not defaulted? Because nobody bothered to change working code. > For bitset::set and bitset::operator==, I also wonder why the manual loop vs > memset/memcmp consteval logic is not delegated to a call of std::fill_n or > std::equal, respectively? Those aren't constexpr in C++14, but bitset is. If we delegated to those algos we'd still need a constexpr-in-C++14 manual loop.
[Bug other/113927] [avr-tiny] Sets up a stack-frame even for trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113927 --- Comment #2 from GCC Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:0f0ca42fb5556f2c6b76b017fbbd90820a728ce0 commit r13-8327-g0f0ca42fb5556f2c6b76b017fbbd90820a728ce0 Author: Georg-Johann Lay Date: Thu Feb 15 13:53:34 2024 +0100 AVR: target 113927 - Simple code triggers stack frame for Reduced Tiny. The -mmcu=avrtiny cores have no ADIW and SBIW instructions. This was implemented by clearing all regs out of regclass ADDW_REGS so that constraint "w" never matched. This corrupted the subset relations of the register classes as they appear in enum reg_class. This patch keeps ADDW_REGS like for all other cores, i.e. it contains R24...R31. Instead of tests like test_hard_reg_class (ADDW_REGS, *) the code now uses avr_adiw_reg_p (*). And all insns with constraint "w" get "isa" insn attribute value of "adiw". Plus, a new built-in macro __AVR_HAVE_ADIW__ is provided, which is more specific than __AVR_TINY__. gcc/ PR target/113927 * config/avr/avr.h (AVR_HAVE_ADIW): New macro. * config/avr/avr-protos.h (avr_adiw_reg_p): New proto. * config/avr/avr.cc (avr_adiw_reg_p): New function. (avr_conditional_register_usage) [AVR_TINY]: Don't clear ADDW_REGS. Replace test_hard_reg_class (ADDW_REGS, ...) with calls to * config/avr/avr.md: Same. (attr "isa") : Remove. : Add. (define_insn, define_insn_and_split): When an alternative has constraint "w", then set attribute "isa" to "adiw". * config/avr/avr-c.cc (avr_cpu_cpp_builtins) [AVR_HAVE_ADIW]: Built-in define __AVR_HAVE_ADIW__. * doc/invoke.texi (AVR Options): Document it. (cherry picked from commit 5cff288c2dae4ea709df067cf398f23e214b2e80)
[Bug target/113927] [avr-tiny] Sets up a stack-frame even for trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113927 Georg-Johann Lay changed: What|Removed |Added Resolution|--- |FIXED Keywords|missed-optimization | Target Milestone|--- |13.3 Component|other |target Status|UNCONFIRMED |RESOLVED --- Comment #3 from Georg-Johann Lay --- Fixed in v13.3+
[Bug c++/99546] Weird return value of C++20 requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99546
Andrew Giese changed:
What|Removed |Added
CC||gieseanw+gcc at gmail dot com
--- Comment #7 from Andrew Giese ---
This bug in the OP appears to have been fixed as early as gcc 11.1.
For reference, I'm referring to the following code:
int main() {
constexpr auto b = requires { []{}; };
static_assert(b);
static_assert(!b);
}
https://godbolt.org/z/WzzGMxcz6
Note that the code listed in Jonathan's comment above still fails in 14.0.1
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99546#c6)
[Bug c++/99546] Weird return value of C++20 requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99546 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2022-09-20 00:00:00 |2024-2-15 --- Comment #8 from Jonathan Wakely --- The OP's example is supposed to be ill-formed though, it shouldn't compile successfully. So I don't think it's fixed.
[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205 --- Comment #11 from Jakub Jelinek --- Richard S., any comments on this?
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #31 from Jan Hubicka --- Having a testcase is great. I was just playing with crafting one. I am still concerned about value ranges in ipa-prop's jump functions. Let me see if I can modify the testcase to also trigger problem with value ranges in ipa-prop jump functions. Not streaming value ranges is an omission on my side (I mistakely assumed we do stream them). We ought to stream them, since otherwise we will lose propagated return value ranges in partitioned programs, which is pity.
[Bug analyzer/110907] ICE when using -fanalyzer-verbose-state-changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110907 David Malcolm changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- Looks like a duplicate of PR 113509; doesn't reproduce anymore with trunk. *** This bug has been marked as a duplicate of bug 113509 ***
[Bug analyzer/113509] ICE: SIGSEGV in c_tree_printer (c-objc-common.cc:341) with -fanalyzer -fanalyzer-verbose-state-changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113509 David Malcolm changed: What|Removed |Added CC||vultkayn at gcc dot gnu.org --- Comment #5 from David Malcolm --- *** Bug 110907 has been marked as a duplicate of this bug. ***
[Bug analyzer/113606] [14 Regression] -Wanalyzer-infinite-recursion false positive on code involving strstr, memset, strnlen and -D_FORTIFY_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113606 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Summary|-Wanalyzer-infinite-recursi |[14 Regression] |on false positive on code |-Wanalyzer-infinite-recursi |involving strstr, memset, |on false positive on code |strnlen and |involving strstr, memset, |-D_FORTIFY_SOURCE |strnlen and ||-D_FORTIFY_SOURCE Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-15
[Bug analyzer/113619] [14 Regression] -Wanalyzer-tainted-divisor false positive seen in Linux kernel's fs/ceph/ioctl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113619 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-15 Summary|-Wanalyzer-tainted-divisor |[14 Regression] |false positive seen in |-Wanalyzer-tainted-divisor |Linux kernel's |false positive seen in |fs/ceph/ioctl.c |Linux kernel's ||fs/ceph/ioctl.c Status|UNCONFIRMED |NEW
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #32 from Jakub Jelinek --- (In reply to Jan Hubicka from comment #31) > Having a testcase is great. I was just playing with crafting one. > I am still concerned about value ranges in ipa-prop's jump functions. Maybe my imagination is too limited, but if the ipa-prop's jump functions are computed before ICF is performed, then if you call function a which makes some assumptions about its arguments and SSA_NAMEs used within the function and results in some return range and another one which makes different assumptions and results in a different range, then even if the two functions are merged and either the range info is thrown away or unioned, I think if some functions call one or the other functions then still the original range assumptions still apply, depending on which one actually called. > Let me see if I can modify the testcase to also trigger problem with value > ranges in ipa-prop jump functions. > > Not streaming value ranges is an omission on my side (I mistakely assumed we > do stream them). We ought to stream them, since otherwise we will lose > propagated return value ranges in partitioned programs, which is pity. Not sure if it is a good idea to start streaming them now in stage4, but sure, if we stream them (and I think we should mostly have code to be able to stream that because we can stream the ranges in the jump functions, just unsure about points-to stuff), then I still think best approach would be to merge regardless of range info, but in that case preferrably union instead of throw away. The only question is where to do the merging for the LTO case (where to stream the union of the ranges and where to read it in and update for the SSA_NAMEs).
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #33 from Jakub Jelinek --- Anyway, should I work on the union variant or do you want to take this over?
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56 --- Comment #19 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b312cf21afd62b43fbc5034703e2796b0c3c416d commit r14-9011-gb312cf21afd62b43fbc5034703e2796b0c3c416d Author: Richard Biener Date: Thu Feb 15 13:41:25 2024 +0100 tree-optimization/56 - properly dissolve SLP only groups The following fixes the omission of failing to look at pattern stmts when we need to dissolve SLP only groups. PR tree-optimization/56 * tree-vect-loop.cc (vect_dissolve_slp_only_groups): Look at the pattern stmt if any.
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #20 from Richard Biener --- fixed.
[Bug analyzer/111266] [13/14 Regression] Missing -Wanalyzer-out-of-bounds for concrete offset overwrite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111266 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||dmalcolm at gcc dot gnu.org Last reconfirmed||2024-02-15 Summary|Missing |[13/14 Regression] Missing |-Wanalyzer-out-of-bounds|-Wanalyzer-out-of-bounds |for concrete offset |for concrete offset |overwrite. |overwrite. --- Comment #1 from David Malcolm --- Thanks for filing this; confirmed: Trunk: https://godbolt.org/z/jzevK9cTz GCC 13.2: https://godbolt.org/z/6jx87aqn6
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #34 from rguenther at suse dot de --- On Thu, 15 Feb 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 > > --- Comment #32 from Jakub Jelinek --- > (In reply to Jan Hubicka from comment #31) [...] > > Not streaming value ranges is an omission on my side (I mistakely assumed we > > do stream them). We ought to stream them, since otherwise we will lose > > propagated return value ranges in partitioned programs, which is pity. > > Not sure if it is a good idea to start streaming them now in stage4, but sure, Please don't do that now ;) (we've not had ranges early originally, and even nonzero bits were not computed) But yes, IPA CP jump functions with value-ranges might be a problem. I think it does instantiate them as local ranges, does it? We have streaming support for ranges, we just don't stream the auxiliary data for all SSA names (like also not points-to info).
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #35 from rguenther at suse dot de --- On Thu, 15 Feb 2024, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 > > --- Comment #34 from rguenther at suse dot de --- > On Thu, 15 Feb 2024, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 > > > > --- Comment #32 from Jakub Jelinek --- > > (In reply to Jan Hubicka from comment #31) > [...] > > > Not streaming value ranges is an omission on my side (I mistakely assumed > > > we > > > do stream them). We ought to stream them, since otherwise we will lose > > > propagated return value ranges in partitioned programs, which is pity. > > > > Not sure if it is a good idea to start streaming them now in stage4, but > > sure, > > Please don't do that now ;) > > (we've not had ranges early originally, and even nonzero bits were not > computed) > > But yes, IPA CP jump functions with value-ranges might be a problem. > I think it does instantiate them as local ranges, does it? We > have streaming support for ranges, we just don't stream the auxiliary > data for all SSA names (like also not points-to info). Also remember we like to have a fix that's easily backportable, and that's probably going to be resetting the info. We can do something more fancy for GCC 15
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #12 from Jens Gustedt --- (In reply to Joseph S. Myers from comment #11) > As I said in comment#2, I prefer a constant suffix for __int128 to the > wb/uwb hack - I think it's cleaner, as well as allowing int128_t to work > properly on all the targets that support __int128 but have not so far had an > ABI for _BitInt defined, or not had such an ABI implemented in GCC. Maybe. But that does not have much to do with the very specific question asked here.
[Bug c++/99546] Weird return value of C++20 requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99546 --- Comment #9 from Andrew Giese --- (In reply to Jonathan Wakely from comment #8) > The OP's example is supposed to be ill-formed though, it shouldn't compile > successfully. So I don't think it's fixed. That's my mistake, sorry. Yes the second static assertion should definitely fail.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #36 from Jan Hubicka --- > > Having a testcase is great. I was just playing with crafting one. > > I am still concerned about value ranges in ipa-prop's jump functions. > > Maybe my imagination is too limited, but if the ipa-prop's jump functions are > computed before ICF is performed, then if you call function a which makes some > assumptions about its arguments and SSA_NAMEs used within the function and > results in some return range > and another one which makes different assumptions and results in a different > range, > then even if the two functions are merged and either the range info is thrown > away > or unioned, I think if some functions call one or the other functions then > still the original range assumptions still apply, depending on which one > actually called. I think the tescase should have functions A1 and A2 calling function B. We need to arrange A1 to ICF into A2 and make A2 to have narrower value range of parameter of B visible to ipa-prop. Since ICF happens first, ipa-prop will not see A1's value range and specialize B for A2's range. Which sould make it possible to trigger wrong code. > > > Let me see if I can modify the testcase to also trigger problem with value > > ranges in ipa-prop jump functions. > > > > Not streaming value ranges is an omission on my side (I mistakely assumed we > > do stream them). We ought to stream them, since otherwise we will lose > > propagated return value ranges in partitioned programs, which is pity. > > Not sure if it is a good idea to start streaming them now in stage4, but sure, > if we > stream them (and I think we should mostly have code to be able to stream that It probably makes sense to postpone VR stremaing for stage1. (Even thouh it is not hard to do.) I will add that to my TODO. > because we can stream the ranges in the jump functions, just unsure about > points-to stuff), > then I still think best approach would be to merge regardless of range info, > but in that case preferrably union instead of throw away. The only question > is > where to do the merging for the LTO case (where to stream the union of the > ranges and where to read it in and update for the SSA_NAMEs). With LTO ICF streams in all function bodies for comparsion to WPA and keeps the winning one, so it is about extending the comparator to keep track of difference of value ranges for all compared pairs. There is code to merge profiles, so at that place one can also do other kind of metadata merging. ICF needs a lot of love on this - value range merging is just one example. We also want to merge TBAA (so we can merge different template instatiations) and other stuff. At the moment we handle all other metadat conservatively (i.e. do not attempt to merge, just refuse merging if it differs) so value ranges are first that are handled aggressively with your patch. I think it is fine, since most value range will be recomputed in late optimization - the only exceptions are the return value ranges for now. I will try to work on making this more systematic next stage1.
[Bug c++/113929] New: GCC accepts template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929
Bug ID: 113929
Summary: GCC accepts template
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This is the sibling of Bug 113788.
template struct S {} ;
S<0> s{};
https://godbolt.org/z/GbdqW9zee
Thank you.
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 --- Comment #11 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2b4efc5db2aedb59196987300e14951d08cd7106 commit r14-9012-g2b4efc5db2aedb59196987300e14951d08cd7106 Author: Jakub Jelinek Date: Thu Feb 15 15:53:01 2024 +0100 expand: Fix handling of asm goto outputs vs. PHI argument adjustments [PR113921] The Linux kernel and the following testcase distilled from it is miscompiled, because tree-outof-ssa.cc (eliminate_phi) emits some fixups on some of the edges (but doesn't commit edge insertions). Later expand_asm_stmt emits further instructions on the same edge. Now the problem is that expand_asm_stmt uses insert_insn_on_edge to add its own fixups, but that function appends to the existing sequence on the edge if any. And the bug triggers when the fixup sequence emitted by eliminate_phi uses a pseudo which the fixup sequence emitted by expand_asm_stmt later on sets. So, we end up with (set (reg A) (asm_operands ...)) and on one of the edges queued sequence (set (reg C) (reg B)) // added by eliminate_phi (set (reg B) (reg A)) // added by expand_asm_stmt That is wrong, what we emit by expand_asm_stmt needs to be as close to the asm_operands as possible (they aren't known until expand_asm_stmt is called, the PHI fixup code assumes it is reg B which holds the right value) and the PHI adjustments need to be done after it. So, the following patch introduces a prepend_insn_to_edge function and uses it from expand_asm_stmt, so that we queue (set (reg B) (reg A)) // added by expand_asm_stmt (set (reg C) (reg B)) // added by eliminate_phi instead and so the value from the asm_operands output propagates correctly to the PHI result. 2024-02-15 Jakub Jelinek PR middle-end/113921 * cfgrtl.h (prepend_insn_to_edge): New declaration. * cfgrtl.cc (insert_insn_on_edge): Clarify behavior in function comment. (prepend_insn_to_edge): New function. * cfgexpand.cc (expand_asm_stmt): Use prepend_insn_to_edge instead of insert_insn_on_edge. * gcc.target/i386/pr113921.c: New test.
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #5 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5459a9074afabf700f055fc8164f88dadb1c39b0 commit r14-9013-g5459a9074afabf700f055fc8164f88dadb1c39b0 Author: Jakub Jelinek Date: Thu Feb 15 15:55:25 2024 +0100 testsuite: Add testcase for already fixed PR [PR107385] This testcase has been fixed by the PR113921 fix, but unlike testcase in there this one is not target specific. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: New test.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #37 from Jan Hubicka --- > Also remember we like to have a fix that's easily backportable, and > that's probably going to be resetting the info. We can do something > more fancy for GCC 15 Rejecting to merge function with different vlaue ranges is also easy, but so is reseting. I only need to check the ipa-prop. Jakub, also I can take over the patch - and sorry for beging slow. I had visitor doing some research last two weeks and I am trying to catch up now.
[Bug analyzer/111802] New analyser diagram failures since commit b365e9d57ad4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111802 --- Comment #1 from David Malcolm --- Thanks for filing this bug report. The issue seems to be with the top line here: ┌┬┬┬┬┐┌─┬─┬─┐ │[1] │[1] │[1] │[1] │[1] ││ [1] │ [1] │ [1] │ ├┼┼┼┼┤├─┼─┼─┤ │' ' │'w' │'o' │'r' │'l' ││ 'd' │ '!' │ NUL │ ├┴┴┴┴┴┴─┴─┴─┤ │ string literal (type: 'char[8]') │ └───┘ where the repeated "[1]"s are meant to be 0 through 7. Does this still affect you?
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #38 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #36)
> > > Having a testcase is great. I was just playing with crafting one.
> > > I am still concerned about value ranges in ipa-prop's jump functions.
> >
> > Maybe my imagination is too limited, but if the ipa-prop's jump functions
> > are
> > computed before ICF is performed, then if you call function a which makes
> > some
> > assumptions about its arguments and SSA_NAMEs used within the function and
> > results in some return range
> > and another one which makes different assumptions and results in a different
> > range,
> > then even if the two functions are merged and either the range info is
> > thrown
> > away
> > or unioned, I think if some functions call one or the other functions then
> > still the original range assumptions still apply, depending on which one
> > actually called.
>
> I think the tescase should have functions A1 and A2 calling function B.
> We need to arrange A1 to ICF into A2 and make A2 to have narrower value
> range of parameter of B visible to ipa-prop. Since ICF happens first,
> ipa-prop will not see A1's value range and specialize B for A2's range.
> Which sould make it possible to trigger wrong code.
If you manage to get wrong ranges in such case, then reusing part of the above
testcase could help make it exploitable, with -minline-all-stringops (at least
in some tunings?) memcpy emits if (len < 8) rep movsb; else { if (dst & 1)
movsb; if (dst & 2) movsb; etc. } and so if incorrect value range results in
the len < 8 check to be optimized away, the rest misbehaves if destination is
aligned to 8 with misalignment 1 and length is smaller than 8.
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 --- Comment #12 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4040d472825f203660371331c9e86cd75e30f8d2 commit r13-8328-g4040d472825f203660371331c9e86cd75e30f8d2 Author: Jakub Jelinek Date: Thu Feb 15 15:53:01 2024 +0100 expand: Fix handling of asm goto outputs vs. PHI argument adjustments [PR113921] The Linux kernel and the following testcase distilled from it is miscompiled, because tree-outof-ssa.cc (eliminate_phi) emits some fixups on some of the edges (but doesn't commit edge insertions). Later expand_asm_stmt emits further instructions on the same edge. Now the problem is that expand_asm_stmt uses insert_insn_on_edge to add its own fixups, but that function appends to the existing sequence on the edge if any. And the bug triggers when the fixup sequence emitted by eliminate_phi uses a pseudo which the fixup sequence emitted by expand_asm_stmt later on sets. So, we end up with (set (reg A) (asm_operands ...)) and on one of the edges queued sequence (set (reg C) (reg B)) // added by eliminate_phi (set (reg B) (reg A)) // added by expand_asm_stmt That is wrong, what we emit by expand_asm_stmt needs to be as close to the asm_operands as possible (they aren't known until expand_asm_stmt is called, the PHI fixup code assumes it is reg B which holds the right value) and the PHI adjustments need to be done after it. So, the following patch introduces a prepend_insn_to_edge function and uses it from expand_asm_stmt, so that we queue (set (reg B) (reg A)) // added by expand_asm_stmt (set (reg C) (reg B)) // added by eliminate_phi instead and so the value from the asm_operands output propagates correctly to the PHI result. 2024-02-15 Jakub Jelinek PR middle-end/113921 * cfgrtl.h (prepend_insn_to_edge): New declaration. * cfgrtl.cc (insert_insn_on_edge): Clarify behavior in function comment. (prepend_insn_to_edge): New function. * cfgexpand.cc (expand_asm_stmt): Use prepend_insn_to_edge instead of insert_insn_on_edge. * gcc.target/i386/pr113921.c: New test. (cherry picked from commit 2b4efc5db2aedb59196987300e14951d08cd7106)
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:407b04b59f712ba41d1bcfbf86eba68c52e7917f commit r13-8329-g407b04b59f712ba41d1bcfbf86eba68c52e7917f Author: Jakub Jelinek Date: Thu Feb 15 15:55:25 2024 +0100 testsuite: Add testcase for already fixed PR [PR107385] This testcase has been fixed by the PR113921 fix, but unlike testcase in there this one is not target specific. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: New test. (cherry picked from commit 5459a9074afabf700f055fc8164f88dadb1c39b0)
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 --- Comment #13 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ba09da9787e8db8903b2b0f7c647c0d7af68bb74 commit r12-10158-gba09da9787e8db8903b2b0f7c647c0d7af68bb74 Author: Jakub Jelinek Date: Thu Feb 15 15:53:01 2024 +0100 expand: Fix handling of asm goto outputs vs. PHI argument adjustments [PR113921] The Linux kernel and the following testcase distilled from it is miscompiled, because tree-outof-ssa.cc (eliminate_phi) emits some fixups on some of the edges (but doesn't commit edge insertions). Later expand_asm_stmt emits further instructions on the same edge. Now the problem is that expand_asm_stmt uses insert_insn_on_edge to add its own fixups, but that function appends to the existing sequence on the edge if any. And the bug triggers when the fixup sequence emitted by eliminate_phi uses a pseudo which the fixup sequence emitted by expand_asm_stmt later on sets. So, we end up with (set (reg A) (asm_operands ...)) and on one of the edges queued sequence (set (reg C) (reg B)) // added by eliminate_phi (set (reg B) (reg A)) // added by expand_asm_stmt That is wrong, what we emit by expand_asm_stmt needs to be as close to the asm_operands as possible (they aren't known until expand_asm_stmt is called, the PHI fixup code assumes it is reg B which holds the right value) and the PHI adjustments need to be done after it. So, the following patch introduces a prepend_insn_to_edge function and uses it from expand_asm_stmt, so that we queue (set (reg B) (reg A)) // added by expand_asm_stmt (set (reg C) (reg B)) // added by eliminate_phi instead and so the value from the asm_operands output propagates correctly to the PHI result. 2024-02-15 Jakub Jelinek PR middle-end/113921 * cfgrtl.h (prepend_insn_to_edge): New declaration. * cfgrtl.cc (insert_insn_on_edge): Clarify behavior in function comment. (prepend_insn_to_edge): New function. * cfgexpand.cc (expand_asm_stmt): Use prepend_insn_to_edge instead of insert_insn_on_edge. * gcc.target/i386/pr113921.c: New test. (cherry picked from commit 2b4efc5db2aedb59196987300e14951d08cd7106)
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d2ebd5948bd21f54fdbc5ea99e391be59d0af64c commit r12-10159-gd2ebd5948bd21f54fdbc5ea99e391be59d0af64c Author: Jakub Jelinek Date: Thu Feb 15 15:55:25 2024 +0100 testsuite: Add testcase for already fixed PR [PR107385] This testcase has been fixed by the PR113921 fix, but unlike testcase in there this one is not target specific. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: New test. (cherry picked from commit 5459a9074afabf700f055fc8164f88dadb1c39b0)
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 --- Comment #14 from GCC Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7a6e9e70ea88061981c5565c043985d8cde9ecc8 commit r11-11239-g7a6e9e70ea88061981c5565c043985d8cde9ecc8 Author: Jakub Jelinek Date: Thu Feb 15 15:53:01 2024 +0100 expand: Fix handling of asm goto outputs vs. PHI argument adjustments [PR113921] The Linux kernel and the following testcase distilled from it is miscompiled, because tree-outof-ssa.cc (eliminate_phi) emits some fixups on some of the edges (but doesn't commit edge insertions). Later expand_asm_stmt emits further instructions on the same edge. Now the problem is that expand_asm_stmt uses insert_insn_on_edge to add its own fixups, but that function appends to the existing sequence on the edge if any. And the bug triggers when the fixup sequence emitted by eliminate_phi uses a pseudo which the fixup sequence emitted by expand_asm_stmt later on sets. So, we end up with (set (reg A) (asm_operands ...)) and on one of the edges queued sequence (set (reg C) (reg B)) // added by eliminate_phi (set (reg B) (reg A)) // added by expand_asm_stmt That is wrong, what we emit by expand_asm_stmt needs to be as close to the asm_operands as possible (they aren't known until expand_asm_stmt is called, the PHI fixup code assumes it is reg B which holds the right value) and the PHI adjustments need to be done after it. So, the following patch introduces a prepend_insn_to_edge function and uses it from expand_asm_stmt, so that we queue (set (reg B) (reg A)) // added by expand_asm_stmt (set (reg C) (reg B)) // added by eliminate_phi instead and so the value from the asm_operands output propagates correctly to the PHI result. 2024-02-15 Jakub Jelinek PR middle-end/113921 * cfgrtl.h (prepend_insn_to_edge): New declaration. * cfgrtl.c (insert_insn_on_edge): Clarify behavior in function comment. (prepend_insn_to_edge): New function. * cfgexpand.c (expand_asm_stmt): Use prepend_insn_to_edge instead of insert_insn_on_edge. * gcc.target/i386/pr113921.c: New test. (cherry picked from commit 2b4efc5db2aedb59196987300e14951d08cd7106)
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #8 from GCC Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a6005ed4f1200ce59501cfadd2d8f558ad90 commit r11-11240-ga6005ed4f1200ce59501cfadd2d8f558ad90 Author: Jakub Jelinek Date: Thu Feb 15 15:55:25 2024 +0100 testsuite: Add testcase for already fixed PR [PR107385] This testcase has been fixed by the PR113921 fix, but unlike testcase in there this one is not target specific. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: New test. (cherry picked from commit 5459a9074afabf700f055fc8164f88dadb1c39b0)
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Should be fixed now for GCC 14.1+, 13.3+, 12.4+ and 11.5.
[Bug analyzer/113505] [14 Regression] ICE: SIGSEGV in tree_class_check (tree.h:3766) with -O -fdump-analyzer -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113505 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-02-15 Summary|ICE: SIGSEGV in |[14 Regression] ICE: |tree_class_check|SIGSEGV in tree_class_check |(tree.h:3766) with -O |(tree.h:3766) with -O |-fdump-analyzer -fanalyzer |-fdump-analyzer -fanalyzer --- Comment #1 from David Malcolm --- Confirmed: Trunk: https://godbolt.org/z/hMM5GK9s9 Doesn't affect GCC 13.2
[Bug target/112575] Segfault in libgccjit due to not cleaning up some target specific cache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112575 Antoni changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Antoni --- This patch is not necessary anymore, presumable due to this: "However, as of r14-4003-geaa8e8541349df ggc_common_finalize zeroes everything marked with GTY. The array target_attribute_cache does have a GTY marking, so perhaps as of that commit this patch isn't necessary"
[Bug c++/113930] New: [modules] ICE in register_duplicate when using partitioned modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113930
Bug ID: 113930
Summary: [modules] ICE in register_duplicate when using
partitioned modules
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickbegg at gmail dot com
Target Milestone: ---
Created attachment 57434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57434&action=edit
-freport-bug output
/home/nick/gcc-trunk-debug-inst/include/c++/14.0.1/bits/basic_string.h:643:16:
internal compiler error: in register_duplicate, at cp/module.cc:11621
643 | template>
|^~~~
// submod.mpp
module;
#include
export module modA:submod;
// modA.mpp
module;
export module modA;
export import :submod;
// main.cpp
#include
import modA;
std::string test_func() {
return "";
}
Tested with GCC 14 (trunk), git rev bbb30f12a7e5ce008f59ec26c9e4cc65ee79fe56
[Bug c++/113929] GCC accepts template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
This is IMHO different, because the grammar is:
template-parameter:
type-parameter
parameter-declaration
parameter-declaration:
attribute-specifier-seq[opt] this[opt] decl-specifier-seq declarator
attribute-specifier-seq[opt] decl-specifier-seq declarator =
initializer-clause
attribute-specifier-seq[opt] this[opt] decl-specifier-seq
abstract-declarator[opt]
attribute-specifier-seq[opt] decl-specifier-seq abstract-declarator[opt] =
initializer-clause
So, unlike the other cases, the grammar allows this specifier in there, just
https://eel.is/c++draft/dcl.fct#6 says it is invalid, because it is not the
first parameter-declaration of a parameter-declaration-list (because it is a
parameter-declaration of a template-parameter-list instead).
I'd go with (on top of PR113802 fix):
2024-02-15 Jakub Jelinek
PR c++/113929
* parser.cc (cp_parser_parameter_declaration): Diagnose this specifier
on template parameter declaration.
* g++.dg/parse/pr113929.C: New test.
--- gcc/cp/parser.cc.jj 2024-02-15 17:33:11.641453437 +0100
+++ gcc/cp/parser.cc2024-02-15 17:40:29.592447265 +0100
@@ -25724,8 +25724,15 @@ cp_parser_parameter_declaration (cp_pars
for a C-style variadic function. */
token = cp_lexer_peek_token (parser->lexer);
- bool const xobj_param_p
+ bool xobj_param_p
= decl_spec_seq_has_spec_p (&decl_specifiers, ds_this);
+ if (xobj_param_p && template_parm_p)
+{
+ error_at (decl_specifiers.locations[ds_this],
+ "% specifier in template parameter declaration");
+ xobj_param_p = false;
+ decl_specifiers.locations[ds_this] = 0;
+}
bool diag_xobj_parameter_pack = false;
if (xobj_param_p && (declarator && declarator->parameter_pack_p))
--- gcc/testsuite/g++.dg/parse/pr113929.C.jj2024-02-15 17:43:18.500129688
+0100
+++ gcc/testsuite/g++.dg/parse/pr113929.C 2024-02-15 17:42:54.564458109
+0100
@@ -0,0 +1,7 @@
+// PR c++/113929
+// { dg-do compile }
+
+template // { dg-error "'this' specifier in template
parameter declaration" }
+struct S {};
+template// { dg-error "'this' specifier in template
parameter declaration" }
+struct T {};
[Bug testsuite/113278] analyzer tests relying on fileno() fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278 Torbjörn SVENSSON changed: What|Removed |Added CC||torbjorn.svensson at foss dot st.c ||om --- Comment #3 from Torbjörn SVENSSON --- Patch sent: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645731.html
[Bug other/113931] New: [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931 Bug ID: 113931 Summary: [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:c9ce332b557bb95987d038d98ea929cdfd1eae1d, r14-8998-gc9ce332b557bb9 make -k check RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc" FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 271) FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for excess errors) # of expected passes1 # of unexpected failures2 FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for excess errors) Excess errors: /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:270: error: static assertion failed: template argument must be a floating point type commit c9ce332b557bb95987d038d98ea929cdfd1eae1d (HEAD) Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Use 128-bit arithmetic for std::linear_congruential_engine [PR87744]
[Bug testsuite/113278] analyzer tests relying on fileno() fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278 --- Comment #4 from GCC Commits --- The master branch has been updated by Torbjorn Svensson : https://gcc.gnu.org/g:8e8c2d2b34971bb29e74341a3efc625f1db06639 commit r14-9015-g8e8c2d2b34971bb29e74341a3efc625f1db06639 Author: Torbjörn SVENSSON Date: Thu Feb 15 17:46:24 2024 +0100 testsuite: Define _POSIX_SOURCE for tests [PR113278] As the tests assume that fileno() is visible (only part of POSIX), define the guard to ensure that it's visible. Currently, glibc appears to always have this defined in C++, newlib does not. Without this patch, fails like this can be seen: Testing analyzer/fileno-1.c, -std=c++98 .../fileno-1.c: In function 'int test_pass_through(FILE*)': .../fileno-1.c:5:10: error: 'fileno' was not declared in this scope FAIL: c-c++-common/analyzer/fileno-1.c -std=c++98 (test for excess errors) Patch has been verified on Linux. gcc/testsuite/ChangeLog: PR testsuite/113278 * c-c++-common/analyzer/fileno-1.c: Define _POSIX_SOURCE. * c-c++-common/analyzer/flex-with-call-summaries.c: Same. * c-c++-common/analyzer/flex-without-call-summaries.c: Same. Signed-off-by: Torbjörn SVENSSON
[Bug analyzer/113496] [12/13/14 Regression] ICE: in cmp, at analyzer/constraint-manager.cc:782 with -fanalyzer -fdump-analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113496 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-15 Summary|ICE: in cmp, at |[12/13/14 Regression] ICE: |analyzer/constraint-manager |in cmp, at |.cc:782 with -fanalyzer |analyzer/constraint-manager |-fdump-analyzer |.cc:782 with -fanalyzer ||-fdump-analyzer --- Comment #1 from David Malcolm --- Thanks for filing this bug. Confirmed; affects gcc 12 onwards: Trunk: https://godbolt.org/z/h11fhE75b GCC 13.2: https://godbolt.org/z/z9Eosesff GCC 12.3: https://godbolt.org/z/GKqcoaPsz Doesn't seem to affect GCC 11.4: https://godbolt.org/z/1qMbxsPEv
[Bug analyzer/112889] [11/12/13 Regression] ICE with -fanalyzer seen on Linux kernel drivers/infiniband/hw/cxgb4/cm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112889 David Malcolm changed: What|Removed |Added Summary|ICE with -fanalyzer seen on |[11/12/13 Regression] ICE |Linux kernel|with -fanalyzer seen on |drivers/infiniband/hw/cxgb4 |Linux kernel |/cm.c |drivers/infiniband/hw/cxgb4 ||/cm.c --- Comment #4 from David Malcolm --- Bug is at least present but latent on older releases (from gcc 11 onwards)
[Bug other/113931] [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The first line of the static_assert is indeed line 270 rather than 271.
[Bug c++/113791] Incorrect handling of lvalue to rvalue conversion in ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113791 --- Comment #5 from Marek Polacek --- Looking. It's https://cplusplus.github.io/CWG/issues/1895.html which we don't implement yet.
[Bug libstdc++/113931] [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931 Jonathan Wakely changed: What|Removed |Added Component|other |libstdc++ Ever confirmed|0 |1 Keywords||testsuite-fail Target Milestone|--- |14.0 Last reconfirmed||2024-02-15 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jonathan Wakely --- Doh - that's what I get for only rerunning a subset of tests after removing a line.
[Bug libstdc++/113931] [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931 --- Comment #3 from Jonathan Wakely --- Oh but I did rerun that one and still missed the FAIL.
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #11 from Jerry DeLisle --- Having done all this, I found: C8102 (R868) The namelist-group-name shall not be a name accessed by use association. What does this mean in the context of renamed?
[Bug c++/113791] Incorrect handling of lvalue to rvalue conversion in ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113791 --- Comment #6 from Marek Polacek --- Stage 1 work. Putting this aside for GCC 15.
[Bug analyzer/109191] GCC static analyzer does not warning `*b = 1` where `b` is 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109191 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from David Malcolm --- Resolving as "INVALID"; feel free to reopen if there's a response to the above questions.
[Bug analyzer/111802] New analyser diagram failures since commit b365e9d57ad4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111802
--- Comment #2 from Thiago Jung Bauermann
---
Thank you for responding.
Yes, I checked commit 5266f930bed0 ("Daily bump.") from yesterday and it's
still present.
