[Bug target/112532] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn: vec_duplicate:V4HI) with -O -msse4 since r14-5388-g2794d510b979be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112532 Sam James changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-11-15 Assignee|unassigned at gcc dot gnu.org |liuhongt at gcc dot gnu.org --- Comment #4 from Sam James --- btw: if you change your email on bugzilla to liuho...@gcc.gnu.org, you'll get more permissions to edit bugs.
[Bug target/112532] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn: vec_duplicate:V4HI) with -O -msse4 since r14-5388-g2794d510b979be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112532 --- Comment #3 from Hongtao.liu --- mine.
[Bug c/107557] [12/13/14 Regression] ICE -fsanitize=undefined and VLA as argument type to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comment #13 from uecker at gcc dot gnu.org --- I think we should backport these changes to 12 and 13. But there is a case which now breaks with these in GCC 14 (PR112488). So I would like to look at this and fix it first.
[Bug target/112535] [14 regression] RISC-V ICE: error: unable to find a register to spill during RTL pass: reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112535 --- Comment #1 from CVS Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:d85161a73b9bdd382e62ca1ba3f9f962971a9695 commit r14-5479-gd85161a73b9bdd382e62ca1ba3f9f962971a9695 Author: Juzhe-Zhong Date: Wed Nov 15 15:15:08 2023 +0800 RISC-V: Disallow RVV mode address for any load/store[PR112535] This patch is quite obvious patch which disallow for load/store address register with RVV mode. PR target/112535 gcc/ChangeLog: * config/riscv/riscv.cc (riscv_legitimate_address_p): Disallow RVV modes base address. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr112535.c: New test.
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 --- Comment #11 from Kito Cheng --- It's not scope of auto vectorization, so I would suggest add something like `-mstringop-strategy=*` or `-mmemcpy-strategy=*` (from x86) or `-param=riscv-mops-memcpy-size-threshold=` (from aarch64). Personally I prefer x86 approach.
[Bug target/112532] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn: vec_duplicate:V4HI) with -O -msse4 since r14-5388-g2794d510b979be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112532 Sam James changed: What|Removed |Added CC||crazylht at gmail dot com Summary|[14 Regression] ICE: in |[14 Regression] ICE: in |extract_insn, at|extract_insn, at |recog.cc:2804 |recog.cc:2804 |(unrecognizable insn: |(unrecognizable insn: |vec_duplicate:V4HI) with -O |vec_duplicate:V4HI) with -O |-msse4 |-msse4 since ||r14-5388-g2794d510b979be --- Comment #2 from Sam James --- 2794d510b979be76b0fee4521d1a454332176007 is the first bad commit commit 2794d510b979be76b0fee4521d1a454332176007 Author: liuhongt Date: Wed Nov 8 14:52:01 2023 +0800 Support vec_set/vec_extract/vec_init for V4HF/V2HF. i.e. r14-5388-g2794d510b979be
[Bug c/107557] [12/13/14 Regression] ICE -fsanitize=undefined and VLA as argument type to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #12 from Sam James --- 12 still ICEs for me, 13 doesn't but I couldn't spot the cherry-pick at a glance. 14 is fine. Dunno if it just needs backports or if something made it latent for 13. martin?
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 --- Comment #10 from JuzheZhong --- This following patch: diff --git a/gcc/config/riscv/riscv-string.cc b/gcc/config/riscv/riscv-string.cc index 57e8ad698d7..c135d4efdb2 100644 --- a/gcc/config/riscv/riscv-string.cc +++ b/gcc/config/riscv/riscv-string.cc @@ -773,7 +773,7 @@ expand_block_move (rtx dst_in, rtx src_in, rtx length_in) bnez a2, loop # Any more? ret # Return */ - if (!TARGET_VECTOR) + if (!TARGET_VECTOR || riscv_autovec_preference == NO_AUTOVEC || !flag_tree_vectorize) return false; HOST_WIDE_INT potential_ew = (MIN (MIN (MEM_ALIGN (src_in), MEM_ALIGN (dst_in)), BITS_PER_WORD) Can fix this issue. Is it OK ?
[Bug c/112539] a struct with an array of unknown size at the end allows writing past end of the struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112539 --- Comment #2 from Sam James --- https://people.kernel.org/kees/bounded-flexible-arrays-in-c and https://developers.redhat.com/articles/2022/09/29/benefits-limitations-flexible-array-members are good reads too
[Bug c/112539] a struct with an array of unknown size at the end allows writing past end of the struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112539 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- C99 (and above) have this kind of array called flexible array member. Which have exactly the semantics you are describing are happening even. See https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Zero-Length.html were GCC documents a different extension but references this. You can also read up about them here: https://en.cppreference.com/w/c/language/struct
[Bug c/112539] New: a struct with an array of unknown size at the end allows writing past end of the struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112539
Bug ID: 112539
Summary: a struct with an array of unknown size at the end
allows writing past end of the struct
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pgmer6809 at yahoo dot com
Target Milestone: ---
Created attachment 56590
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56590=edit
the output of the gcc --save-temps command
See the manpage for sizeof operator at:
https://man7.org/linux/man-pages/man3/offsetof.3.html
it gives an example of code that shows the size of a struct defined as:
struct s {
int i;
char c;
double d;
char a[];
};
struct s S;
in their sample program (attached?) the output shows that
the offset of a[] is given as 16; the size of the struct is also given as 16.
This is clearly incorrect.
Changing a[] to either simply a, or even a[1] makes the size of the struct 24
bytes which is correct.
I modified their program to actually try writing to locations S.a[0] and S.a[1]
successfully. The code compiles and runs, and even reports the correct values
when I try to print them out.
So (a) is this a bug in the sizeof operator?
(b) could one use the fact that we can write beyond the end of the struct as
the basis for some sort of exploit?
attached is the file with the gcc output from the --save-temps that you want me
to include with the bug report.
The actual output from the screen is below.
Hope this helps.
Regards,
Greg Morse; pgmer6...@yahoo.com
here is the printed output of the program
greg21@trojan:/tmp$ ./a.out
offsets: i=0; c=4; d=8 a=16
sizeof(struct s)=16
sizeof Int = 4, char=1, double=8,
The value of S.a is 5A:Z, W
The address of S is 0x7fff9be5d070 ; The address of S.a is 0x7fff9be5d080
The address of S.a[0] is 0x7fff9be5d080, and that of S.a[1] is: 0x7fff9be5d081
[Bug target/111170] [13/14 regression] Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library) since r13-6552-gd11e088210a551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70 --- Comment #3 from LIU Hao --- Costas, would you like to provide a configure option to exclude that manifest?
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 --- Comment #9 from JuzheZhong --- I think we can use -fno-tree-vectorize or --param=riscv-autovec-preference=none to disable it.
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 --- Comment #8 from Kito Cheng --- That remind me we may need one option like something -mgeneral-regs-only in aarch64 and also for target attribute. BTW, clang has an generic option called -mno-implicit-float can did similar thing
[Bug target/112532] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn: vec_duplicate:V4HI) with -O -msse4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112532 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- Reproduced on trunk but r14-5371-g93e92b2e5d6866 is okay, will bisect
[Bug tree-optimization/112496] [13/14 Regression] ICE: in vectorizable_nonlinear_induction, at tree-vect-loop.cc with bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112496 Sam James changed: What|Removed |Added Resolution|--- |FIXED CC||sjames at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #6 from Sam James --- Fixed for 13.3 then.
[Bug c++/106849] internal compiler error: tree check: expected none of template_decl, have template_decl in do_nonmember_using_decl, at cp/name-lookup.cc:4841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106849 Sam James changed: What|Removed |Added Keywords||ice-checking Ever confirmed|0 |1 CC||nathan at gcc dot gnu.org Last reconfirmed||2023-11-15 Status|UNCONFIRMED |NEW --- Comment #5 from Sam James --- Fixed for 14 then?
[Bug rtl-optimization/110390] [13/14 regression] ICE on valid code on x86_64-linux-gnu with sel-scheduling: in av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609 since r13-3596-ge7310e24b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390 Sam James changed: What|Removed |Added Keywords||needs-reduction Summary|ICE on valid code on|[13/14 regression] ICE on |x86_64-linux-gnu with |valid code on |sel-scheduling: in |x86_64-linux-gnu with |av_set_could_be_blocked_by_ |sel-scheduling: in |bookkeeping_p, at |av_set_could_be_blocked_by_ |sel-sched.cc:3609 since |bookkeeping_p, at |r13-3596-ge7310e24b1c0ca|sel-sched.cc:3609 since ||r13-3596-ge7310e24b1c0ca URL|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=110390# | --- Comment #7 from Sam James --- I'll add 'needs-reduction' given pinskia's comment.
[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374 Sam James changed: What|Removed |Added Summary|[14 Regression] |[14 Regression] Failed |`--with-arch=skylake-avx512 |bootstrap with |--with-cpu=skylake-avx512` |`--with-arch=skylake-avx512 |causes a comparison failure |--with-cpu=skylake-avx512`, ||causes a comparison failure Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-11-15 --- Comment #14 from Sam James --- Confirming given pinskia hit it & h.j continues to: https://gcc.gnu.org/pipermail/gcc-regression/2023-November/078409.html.
[Bug target/112538] [RISC-V] Failed to disable V-ext autovectorization using the '--param riscv-autovec-preference=none'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112538 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 112537 ***
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 Andrew Pinski changed: What|Removed |Added CC||mumuxi_ll at outlook dot com --- Comment #7 from Andrew Pinski --- *** Bug 112538 has been marked as a duplicate of this bug. ***
[Bug target/112538] [RISC-V] Failed to disable V-ext autovectorization using the '--param riscv-autovec-preference=none'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112538 JuzheZhong changed: What|Removed |Added CC||juzhe.zhong at rivai dot ai --- Comment #1 from JuzheZhong --- Duplicate bug of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 It generates vector codes since it is lower int __builtin_memcpy https://godbolt.org/z/f36feoW6x Current expanding memcpy into RVV by default as long as TARGET_VECTOR is true. More details see expand_block_move in riscv-string.cc Maybe you need to add if (!flag_tree_vectorize) return false; in expand_block_move .
[Bug bootstrap/54696] Makefile doesn't propagate CPPFLAGS to host libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54696 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #4 from Sam James --- See also r12-4770-g84401ce5fb4eca.
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 --- Comment #6 from JuzheZhong --- We can add if (!flag_tree_vectorize) return false; in riscv_vector::expand_block_move But I am not sure whether other RISC-V folks is happy with that. CCing other folks to see whether they allow it.
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 --- Comment #5 from Huaqi --- (In reply to JuzheZhong from comment #4) > You mean you want to disable it when disabling auto-vectorization ? Yes, I think this could be better, so we can control whether vector instruction should be generated, and if auto generated rvv instruction is not good, we can enable it via gcc pragma control for selected code block. Thanks
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 --- Comment #4 from JuzheZhong --- You mean you want to disable it when disabling auto-vectorization ?
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 --- Comment #3 from Huaqi --- Hi Juzhe, thanks for the help, could it be controlled by --param=riscv-autovec-preference= option, so if I want to enable cpymem optimization, I can enable it by auto vectorzation. Thanks
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537
--- Comment #2 from JuzheZhong ---
Currently, we don't have a compile option to disable cpymem by RVV.
I can tell how to disable it:
in riscv.md:
(define_expand "cpymem"
[(parallel [(set (match_operand:BLK 0 "general_operand")
(match_operand:BLK 1 "general_operand"))
(use (match_operand:P 2 ""))
(use (match_operand:SI 3 "const_int_operand"))])]
""
{
if (riscv_vector::expand_block_move (operands[0], operands[1], operands[2]))
DONE;
else if (riscv_expand_block_move (operands[0], operands[1], operands[2]))
DONE;
else
FAIL;
})
remove
if (riscv_vector::expand_block_move (operands[0], operands[1], operands[2]))
DONE;
Then it will be disabled.
[Bug target/112538] New: [RISC-V] Failed to disable V-ext autovectorization using the '--param riscv-autovec-preference=none'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112538
Bug ID: 112538
Summary: [RISC-V] Failed to disable V-ext autovectorization
using the '--param riscv-autovec-preference=none'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mumuxi_ll at outlook dot com
Target Milestone: ---
Here is my test case:
```
#include
typedef charStr_30 [31];
Str_30 Str_2_Loc;
void foo(void)
{
strcpy(Str_2_Loc, "DHRYSTONE PROGRAM");
}
```
Compiled with riscv64-unknown-elf-gcc -march=rv32imafdc_zve32f -mabi=ilp32d -S
rvv_autovec_bug.c --param riscv-autovec-preference=none
The result is:
.string "DHRYSTONE PROGRAM"
.text
.align 1
.globl foo
.type foo, @function
foo:
addisp,sp,-16
sw ra,12(sp)
sw s0,8(sp)
addis0,sp,16
lui a5,%hi(Str_2_Loc)
addia3,a5,%lo(Str_2_Loc)
lui a5,%hi(.LC0)
addia4,a5,%lo(.LC0)
mv a5,a3
vsetivlizero,9,e16,m8,ta,ma
vle16.v v8,0(a4)
vsetivlizero,9,e16,m8,ta,ma
vse16.v v8,0(a5)
nop
lw ra,12(sp)
lw s0,8(sp)
addisp,sp,16
jr ra
It still generates the v-ext instructions automatically, which seems that the
"--param riscv-autovec-preference=none" did not work.
[Bug tree-optimization/112536] [14 regression] ICE when buliding xorg-server on arm64 (internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.cc:6378)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112536
--- Comment #7 from Sam James ---
Here's the zstd testcase with clz instead too:
```
unsigned a, b, minTableLog_srcSize;
unsigned FSE_minTableLog_srcSize(unsigned maxSymbolValue) {
minTableLog_srcSize = __builtin_clz(a);
b = -minTableLog_srcSize;
int minBitsSrc = b + 1;
minTableLog_srcSize = __builtin_clz(maxSymbolValue);
a = -minTableLog_srcSize;
int minBitsSymbols = a + 2;
int minBits = minBitsSrc < minBitsSymbols ? minBitsSrc : minBitsSymbols;
return minBits;
}
```
[Bug target/112519] [14 Regression] wrong code with __builtin_sub_overflow_p() on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112519 --- Comment #4 from Zdenek Sojka --- I can no longer reproduce the failure on neither the original or reduced testcase, on neither r14-5443 , r14-5456 nor r14-5476
[Bug target/112518] [14 Regression] wrong code with __builtin_mul_overflow_p() and int128_t on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518 --- Comment #4 from Zdenek Sojka --- (In reply to Andrew Pinski from comment #3) > I cannot reproduce it with r14-5450-g4db820928065ec or > r14-5427-gd22b87864e5d47 . Thank you for the investigation! Either the flags have changed, or I did something very wrong; now it needs -mbmi2 to fail: (FAILs for me on r14-5443 , r14-5456 and r14-5476 ) $ md5sum testcase.c 5bc2d32fe8096769aca6bca7fb07470f testcase.c $ x86_64-pc-linux-gnu-gcc -Os -mbmi2 testcase.c $ ./a.out Aborted
[Bug tree-optimization/112536] [14 regression] ICE when buliding xorg-server on arm64 (internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.cc:6378)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112536 Andrew Pinski changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||pinskia at gcc dot gnu.org --- Comment #6 from Andrew Pinski --- manually bisected to r14-5435-g7383cb56e11707 .
[Bug tree-optimization/112536] [14 regression] ICE when buliding xorg-server on arm64 (internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.cc:6378)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112536
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-15
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #5 from Andrew Pinski ---
Confirmed, a little more reduced:
```
typedef struct {
unsigned g, b;
} rgb;
void f(rgb *offset , rgb mask) {
offset->g = __builtin_ffs(mask.g) - 1;
offset->b = __builtin_ffs(mask.b) - 1;
}
```
[Bug tree-optimization/112536] [14 regression] ICE when buliding xorg-server on arm64 (internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.cc:6378)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112536
--- Comment #4 from Sam James ---
Reduced:
```
typedef struct {
int green, blue;
} rgb;
struct {
rgb offset;
} xf86SetWeight_scrp;
rgb xf86SetWeight_mask;
int ffs(int color);
void xf86SetWeight() {
xf86SetWeight_scrp.offset.green = ffs(xf86SetWeight_mask.green) - 1;
xf86SetWeight_scrp.offset.blue = ffs(xf86SetWeight_mask.blue) - 1;
}
```
[Bug target/112537] Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 --- Comment #1 from Andrew Pinski --- >since if vector load and store for smaller structure assign is costable and >harmfull to cpu pipeline. This depends on the Pipeline. Seems like there is a missing cost model for your cpu somewhere.
[Bug c/112537] New: Is there a way to disable cpymem pass for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 Bug ID: 112537 Summary: Is there a way to disable cpymem pass for rvv Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fanghuaqi at vip dot qq.com Target Milestone: --- See https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gcc.target/riscv/rvv/base/cpymem-2.c;h=7b706b6ef52544cabdce2007256c9e67b72ccd79;hb=9464e72bcc9123b619215af8cfef491772a3ebd9 this case, if I pass -march=rv64imafdcv to compile code like this, it will generate vector related code, which I think it should only be enabled when --param=riscv-autovec-preference=scalable is enabled, but actually it is auto enable d even I pass --param=riscv-autovec-preference=none, see https://godbolt.org/z/TazWKEjzM Is there a way to disable it, since if vector load and store for smaller structure assign is costable and harmfull to cpu pipeline. Thanks
[Bug target/112447] risc-v regression: FAIL: gcc.c-torture/execute/memset-3.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #20 from JuzheZhong ---
This is the reason of this patch:
The whole analysis is correct.But we made a mistake on inserting vsetvls.
This is the story.
We have 2 types of global vsetvls insertion.
One is earliest fusion of each end of the block.
The other is LCM suggested edge vsetvls.
So before this patch, insertion as follows:
(insn 2817 2820 2818 361 (set (reg:SI 67 vtype)
(unspec:SI [
(const_int 8 [0x8])
(const_int 7 [0x7])
(const_int 1 [0x1]) repeated x2
] UNSPEC_VSETVL)) 1708 {vsetvl_vtype_change_only}
(nil))
(insn 2818 2817 999 361 (set (reg:SI 67 vtype)
(unspec:SI [
(const_int 32 [0x20])
(const_int 1 [0x1]) repeated x3
] UNSPEC_VSETVL)) 1708 {vsetvl_vtype_change_only}
(nil))
After this patch:
(insn 2817 2820 2819 361 (set (reg:SI 67 vtype)
(unspec:SI [
(const_int 32 [0x20])
(const_int 1 [0x1]) repeated x3
] UNSPEC_VSETVL)) 1708 {vsetvl_vtype_change_only}
(nil))
(insn 2819 2817 999 361 (set (reg:SI 67 vtype)
(unspec:SI [
(const_int 8 [0x8])
(const_int 7 [0x7])
(const_int 1 [0x1]) repeated x2
] UNSPEC_VSETVL)) 1708 {vsetvl_vtype_change_only}
(nil))
The original insertion order is incorrect.
We should first insert earliest fusion since it is the vsetvls information
already there which was seen by later LCM. We just delay the insertion.
So it should be come before the LCM suggested insertion.
Feel free to investigate it with comparing before and after the patch.
Then feel free to send patch with this fix after you understand the reasons.
Thanks.
[Bug tree-optimization/112536] [14 regression] ICE when buliding xorg-server on arm64 (internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.cc:6378)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112536 --- Comment #3 from Andrew Pinski --- Worked at r14-5115-g6e9ee44d96e5bda8808dd9d8ccf58d2525383f6b .
[Bug target/112447] risc-v regression: FAIL: gcc.c-torture/execute/memset-3.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447 --- Comment #19 from JuzheZhong --- Created attachment 56589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56589=edit bug fix patch Hi,Vineet. The attachment is the bug fix patch. I have tested on both RV32 and RV64 C/C++. No regression with reducing memset-3.c FAIL. You can verify and send the patch. Thanks.
[Bug tree-optimization/112536] [14 regression] ICE when buliding xorg-server on arm64 (internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.cc:6378)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112536 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/112447] risc-v regression: FAIL: gcc.c-torture/execute/memset-3.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447 --- Comment #18 from JuzheZhong --- I know how to fix it. Testing a candidate patch.
[Bug tree-optimization/112536] [14 regression] ICE when buliding xorg-server on arm64 (internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.cc:6378)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112536 --- Comment #2 from Sam James --- I'm going to kick off cvise for this. I've also had probably a dupe with zstd but I may reduce that too given both projects are C so it should be quick.
[Bug tree-optimization/112536] [14 regression] ICE when buliding xorg-server on arm64 (internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.cc:6378)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112536 --- Comment #1 from Sam James --- Created attachment 56588 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56588=edit xf86Helper.c.i
[Bug tree-optimization/112536] New: [14 regression] ICE when buliding xorg-server on arm64 (internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.cc:6378)
e complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. ``` ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/14/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./configure --host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu --prefix=/usr --bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/14 --includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/14/include --datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14 --mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14/man --infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14/info --with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/14/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 14.0.0 p, commit 35bb529f420ff5863fdae51049e6935ab927ff3d' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --without-isl --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --with-build-config='bootstrap-O3 bootstrap-lto' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231114 (experimental) b42a09b258c3ed8d1368e0ef0948034dcf0f8ac9 (Gentoo Hardened 14.0.0 p, commit 35bb529f420ff5863fdae51049e6935ab927ff3d) ``` 'gcc -c xf86Helper.c.i -O2' is enough for me to reproduce.
[Bug target/112535] New: [14] RISC-V ICE: error: unable to find a register to spill during RTL pass: reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112535
Bug ID: 112535
Summary: [14] RISC-V ICE: error: unable to find a register to
spill during RTL pass: reload
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Created attachment 56587
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56587=edit
-freport-bug output
> /scratch/tc-testing/tc-bisect-nov-7-2/build-rv64gc/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv -mabi=lp64d -O2 red.c -freport-bug
red.c: In function 'g':
red.c:14:1: error: unable to find a register to spill
14 | }
| ^
red.c:14:1: error: this is the insn:
(insn 22 43 38 4 (set (mem:SI (subreg:DI (reg:V1DI 155 [orig:137 vect_a.17 ]
[137]) 0) [5 *_37+0 S4 A32])
(const_int 0 [0])) "red.c":13:10 207 {*movsi_internal}
(expr_list:REG_DEAD (reg:V1DI 155 [orig:137 vect_a.17 ] [137])
(nil)))
during RTL pass: reload
red.c:14:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.cc:1861
0xa10e93 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:108
0x1073958 lra_split_hard_reg_for()
../../../gcc/gcc/lra-assigns.cc:1861
0x106d339 lra(_IO_FILE*)
../../../gcc/gcc/lra.cc:2495
0x1024119 do_reload
../../../gcc/gcc/ira.cc:5973
0x1024119 execute
../../../gcc/gcc/ira.cc:6161
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/112525] fail to eliminate unused store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112525 --- Comment #6 from Jiu Fu Guo --- (In reply to Jiu Fu Guo from comment #3) > One possible method is fixing DSE to let is able to remove those 'store's. > (but need to take care of the case that is using 'arg_pointer' to pass > parameters.) > Some 'store's to the incoming argument area (arg_pointer_rtx) may not safe to be removed: For example: call memset on X86_64 , the insn(s) maybe: 134: [argp+0x8]=r134:SI 135: [argp+0x4]=0x1 136: [argp]=r132:SI 137: ax:SI=call [`memset'] argc:0xc REG_CALL_DECL `memset' REG_EH_REGION 0 insn(s) 134/135/136 can not be removed.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #38 from LIU Hao --- (In reply to Andrew Pinski from comment #35) > (In reply to peter0x44 from comment #34) > > Unfortunately, this option breaks GCC running under Windows XP. > > XP has not been supported by mingw for a long time so I have no idea how you > have been building there. In the last year, some efforts have been made to ensure that the mingw-w64 CRT no longer references symbols that did not exist on XP (e.g. to provide our alternative when there was no `llabs()`). While I didn't test it (I do not have XP installed on any device) it was said to make GNU toolchains produce executables that run on XP. I'd say XP is still sort of 'supported'. However one still has to take care, for example, not pass `%lld` to `printf()`.
[Bug target/112447] risc-v regression: FAIL: gcc.c-torture/execute/memset-3.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #17 from JuzheZhong ---
The incorrect elimination happens on pre_global_vsetvl_info
You can try simple hack like this:
diff --git a/gcc/config/riscv/riscv-vsetvl.cc
b/gcc/config/riscv/riscv-vsetvl.cc
index 8466b5d019e..65dcf931808 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -3135,6 +3135,8 @@ pre_vsetvl::pre_global_vsetvl_info ()
for (const bb_info *bb : crtl->ssa->bbs ())
{
sbitmap d = m_del[bb->index ()];
+ if (bb->index () == 113 || bb->index () == 54)
+continue;
if (bitmap_count_bits (d) == 0)
continue;
FAIL will be fixed.
So, the idea is that we should investigate why LCM calculation return
m_del to be true on BB 54 and BB 113.
The calculation is done by pre_edge_lcm_avs
[Bug target/112447] risc-v regression: FAIL: gcc.c-torture/execute/memset-3.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447 --- Comment #16 from JuzheZhong --- The victim should be these 2 pieces of codes: .L20: lbu a1,0(a3) li t1,97 bne a1,t1,.L21 lbu t1,1(a3) bne t1,a1,.L21 lbu a1,2(a3) bne a1,t1,.L21 lbu t1,3(a3) bne t1,a1,.L21 lbu a1,4(a3) bne a1,t1,.L21 lbu t1,5(a3) bne t1,a1,.L21 lbu a1,6(a3) bne a1,t1,.L21 lbu a3,7(a3) bne a3,a1,.L21 lui a3,%hi(A) lbu a3,%lo(A)(a3) mv t1,a5 mv a1,a4 bltua4,t3,.L24 mv t1,t4 addia1,a4,-8 vmv.v.x v2,a3 vse8.v v2,0(a2) .L24: .L29: lbu t1,0(a1) li t6,97 bne t1,t6,.L21 lbu t6,1(a1) bne t6,t1,.L21 lbu t1,2(a1) bne t1,t6,.L21 lbu t6,3(a1) bne t6,t1,.L21 lbu t1,4(a1) bne t1,t6,.L21 lbu t6,5(a1) bne t6,t1,.L21 lbu t1,6(a1) bne t1,t6,.L21 lbu a1,7(a1) bne a1,t1,.L21 mv t1,a5 mv a1,a4 bltua4,t3,.L31 li t6,66 mv t1,t4 addia1,a4,-8 vmv.v.x v2,t6 vse8.v v2,0(a2) .L31: They are located on BB 54 and BB 113. Their VSETVLs should not be eliminiated.
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #3 from Bruno Haible --- (In reply to Andrew Pinski from comment #1) > Hmm. similar issue happen with gdb 5 years ago: > https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00151.html Thanks; this is helpful. In this thread we have the explanation https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00158.html, which could maybe be the root cause of the problem here. > Looks like this is huge gnulib mess at that. This comment is not helpful. 1) As shown in the previous comment, max_align_t problems arise from the use of -std=... options that are too old. We are in the year 2023, and it seems right to use ISO C 11 features (from a 12 years old standard), no? 2) Gnulib actually works around two problems related to max_align_t, as documented here: https://www.gnu.org/software/gnulib/manual/html_node/stddef_002eh.html Without Gnulib, you would encounter more problems related to max_align_t, not fewer.
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #2 from Bruno Haible --- > gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) > gcc -std=gnu99 ... > error: unknown type name 'max_align_t' The type 'max_align_t' exists in C11, but not in C99, as can be seen from these uses of gcc 4.8.5: $ cat foo.c #include max_align_t x; $ gcc -std=c11 -c foo.c $ gcc -std=gnu11 -c foo.c $ gcc -std=c99 -c foo.c foo.c:2:1: error: unknown type name ‘max_align_t’ max_align_t x; ^ $ gcc -std=gnu99 -c foo.c foo.c:2:1: error: unknown type name ‘max_align_t’ max_align_t x; ^ But this occurs in the build tree of gettext-runtime, and this package uses AC_PROG_CC, which adds option -std=gnu11 if supported (this is in GNU Autoconf since version 2.70). Maybe some configure file was built with Autoconf 2.69 and older and thus does not add -std=gnu11 ? Or some other configure in the build tree has determined CC="gcc -std=gnu99", and this setting has been propagated into gettext-runtime, overriding the findings from gettext-runtime/configure ?
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #37 from peter0x44 at disroot dot org --- Sorry, comment got sent by accident, before I was done typing. And you replied before I finished, too. Thanks for pointing me in the correct direction. === IRRELEVANT Executables with this embedded UTF-8 manifest don't run on Windows XP. The OS just reports "The system cannot execute the specified program." Patching GCC to remove it does make it work and run fine, simply remove all the contents of winnt-utf8.manifest, and it will work again. Related issue: https://github.com/skeeto/w64devkit/issues/58 I'm not sure if anyone cares, since it is a very old and unsupported OS, but I figured it was worth a little further discussion. Perhaps making disabling it a configure option would be feasible. https://nullprogram.com/blog/2020/05/04/ https://nullprogram.com/blog/2021/12/30/ Here is some useful info that may help in choosing a more optimal solution. ===
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #36 from Andrew Pinski --- (In reply to Andrew Pinski from comment #35) > (In reply to peter0x44 from comment #34) > > Unfortunately, this option breaks GCC running under Windows XP. > > XP has not been supported by mingw for a long time so I have no idea how you > have been building there. Anyways this was reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70 already.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #35 from Andrew Pinski --- (In reply to peter0x44 from comment #34) > Unfortunately, this option breaks GCC running under Windows XP. XP has not been supported by mingw for a long time so I have no idea how you have been building there.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 peter0x44 at disroot dot org changed: What|Removed |Added CC||peter0x44 at disroot dot org --- Comment #34 from peter0x44 at disroot dot org --- Unfortunately, this option breaks GCC running under Windows XP.
[Bug tree-optimization/112104] loop of ^1 should just be reduced to ^(n&1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112104 Andrew Pinski changed: What|Removed |Added Target Milestone|14.0|---
[Bug tree-optimization/112104] loop of ^1 should just be reduced to ^(n&1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112104 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #6 from Andrew Pinski --- (In reply to Hongtao.liu from comment #5) > (In reply to Andrew Pinski from comment #4) > > Fixed via r14-5428-gfd1596f9962569afff6c9298a7c79686c6950bef . > > Note, my patch only handles constant tripcount for XOR, but not do the > transformation when tripcount is variable. Oh.
[Bug tree-optimization/112104] loop of ^1 should just be reduced to ^(n&1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112104 --- Comment #5 from Hongtao.liu --- (In reply to Andrew Pinski from comment #4) > Fixed via r14-5428-gfd1596f9962569afff6c9298a7c79686c6950bef . Note, my patch only handles constant tripcount for XOR, but not do the transformation when tripcount is variable.
[Bug tree-optimization/112496] [13/14 Regression] ICE: in vectorizable_nonlinear_induction, at tree-vect-loop.cc with bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112496 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:ed73ad337739a4244e8040d19b6e567c4101b58a commit r13-8068-ged73ad337739a4244e8040d19b6e567c4101b58a Author: liuhongt Date: Mon Nov 13 17:56:49 2023 +0800 Fix ICE in vectorizable_nonlinear_induction with bitfield. if (TREE_CODE (init_expr) == INTEGER_CST) init_expr = fold_convert (TREE_TYPE (vectype), init_expr); else gcc_assert (tree_nop_conversion_p (TREE_TYPE (vectype), TREE_TYPE (init_expr))); and init_expr is a 24 bit integer type while vectype has 32bit components. The "fix" is to bail out instead of asserting. gcc/ChangeLog: PR tree-optimization/112496 * tree-vect-loop.cc (vectorizable_nonlinear_induction): Return false when !tree_nop_conversion_p (TREE_TYPE (vectype), TREE_TYPE (init_expr)). gcc/testsuite/ChangeLog: * gcc.target/i386/pr112496.c: New test. (cherry picked from commit f28306b4fd309b579c8a4a5bf2f1b24fa40f8f7f)
[Bug tree-optimization/111439] some boolean related transformation to `~(a)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111439 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2023-11-14 --- Comment #1 from Andrew Pinski --- Mine.
[Bug target/112518] [14 Regression] wrong code with __builtin_mul_overflow_p() and int128_t on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518 --- Comment #3 from Andrew Pinski --- I cannot reproduce it with r14-5450-g4db820928065ec or r14-5427-gd22b87864e5d47 .
[Bug target/112447] risc-v regression: FAIL: gcc.c-torture/execute/memset-3.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447 --- Comment #15 from Vineet Gupta --- (In reply to JuzheZhong from comment #14) > Let me give you some guide which helps you to dig into the problem. > > First, reduce the case as follows: Did your msg get truncated or pressed send too soon ? Because the reduced test you pasted is exactly what I uploaded to the bug and I can't reduce it any further.
[Bug target/112447] risc-v regression: FAIL: gcc.c-torture/execute/memset-3.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #14 from JuzheZhong ---
Let me give you some guide which helps you to dig into the problem.
First, reduce the case as follows:
#include
void abort (void);
void exit (int);
#ifndef MAX_OFFSET
#define MAX_OFFSET (sizeof (long long))
#endif
#ifndef MAX_COPY
#define MAX_COPY 15
#endif
#ifndef MAX_EXTRA
#define MAX_EXTRA (sizeof (long long))
#endif
#define MAX_LENGTH (MAX_OFFSET + MAX_COPY + MAX_EXTRA)
static union {
char buf[MAX_LENGTH];
long long align_int;
long double align_fp;
} u;
char A = 'A';
void reset ()
{
int i;
for (i = 0; i < MAX_LENGTH; i++)
u.buf[i] = 'a';
}
void check (int off, int len, int ch)
{
char *q;
int i;
q = u.buf;
for (i = 0; i < off; i++, q++)
if (*q != 'a')
abort ();
for (i = 0; i < len; i++, q++)
if (*q != ch)
abort ();
for (i = 0; i < MAX_EXTRA; i++, q++)
if (*q != 'a')
abort ();
}
int main ()
{
int len;
char *p;
/* off == 0 */
for (len = 0; len < MAX_COPY; len++)
{
reset ();
p = memset (u.buf, '\0', len);
if (p != u.buf) abort ();
check (0, len, '\0');
p = memset (u.buf, A, len);
if (p != u.buf) abort ();
check (0, len, 'A');
p = memset (u.buf, 'B', len);
if (p != u.buf) abort ();
check (0, len, 'B');
}
/* off == 1 */
for (len = 0; len < MAX_COPY; len++)
{
reset ();
p = memset (u.buf+1, '\0', len);
if (p != u.buf+1) abort ();
check (1, len, '\0');
p = memset (u.buf+1, A, len);
if (p != u.buf+1) abort ();
check (1, len, 'A');
p = memset (u.buf+1, 'B', len);
if (p != u.buf+1) abort ();
check (1, len, 'B');
}
exit (0);
}
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #1 from Andrew Pinski --- Hmm. similar issue happen with gdb 5 years ago: https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00151.html Looks like this is huge gnulib mess at that.
[Bug target/112447] risc-v regression: FAIL: gcc.c-torture/execute/memset-3.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447 --- Comment #13 from Vineet Gupta --- Then I don't know where the problem actually is ?
[Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
Bug ID: 112534
Summary: [14 regression] build failure after
r14-5424-gdb50aea6259545 using gcc 4.8.5
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:db50aea62595452db12565186cb520728540d987, r14-5424-gdb50aea6259545
We have one old system where gcc fails to build starting with this revision.
Note even a non-bootstrap build fails.
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
make[6]: Entering directory
`/home/seurer/gcc/git/build/gcc-test/gettext/gnulib-lib'
gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -I.
-I/home/seurer/gcc/git/gcc-test/gettext/gettext-runtime/gnulib-lib -I..
-I../intl -I/home/seurer/gcc/git/gcc-test/gettext/gettext-runtime/intl
-DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -Wno-cast-qual -Wno-conversion
-Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function
-Wno-unused-parameter -Wno-pedantic -Wno-sign-conversion -Wno-type-limits
-Wno-unsuffixed-float-constants -g -O2 -c -o
malloc/libgrt_a-scratch_buffer_grow.o `test -f 'malloc/scratch_buffer_grow.c'
|| echo
'/home/seurer/gcc/git/gcc-test/gettext/gettext-runtime/gnulib-lib/'`malloc/scratch_buffer_grow.c
In file included from
/home/seurer/gcc/git/gcc-test/gettext/gettext-runtime/gnulib-lib/scratch_buffer.h:115:0,
from
/home/seurer/gcc/git/gcc-test/gettext/gettext-runtime/gnulib-lib/malloc/scratch_buffer_grow.c:23:
./malloc/scratch_buffer.gl.h:70:9: error: unknown type name 'max_align_t'
union { max_align_t __align; char __c[1024]; } __space;
^
make[6]: *** [malloc/libgrt_a-scratch_buffer_grow.o] Error 1
make[6]: Leaving directory
`/home/seurer/gcc/git/build/gcc-test/gettext/gnulib-lib'
commit db50aea62595452db12565186cb520728540d987 (HEAD)
Author: Arsen <87>
Date: Fri May 19 21:12:57 2023 +0200
*: add modern gettext
[Bug libstdc++/112491] std::deque::size xmethod output is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112491 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- Fixed for 11.5, 12.4, 13.3 and 14.1. Thanks for the report.
[Bug libstdc++/112491] std::deque::size xmethod output is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112491 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:57727d36e0a3d69dbd6b2221cde0624dbb9dfc95 commit r11-11098-g57727d36e0a3d69dbd6b2221cde0624dbb9dfc95 Author: Jonathan Wakely Date: Tue Nov 14 15:08:13 2023 + libstdc++: Fix std::deque::size() Xmethod [PR112491] The Xmethod for std::deque::size() assumed that the first element would be at the start of the first node. That's only true if elements are only added at the back. If an element is inserted at the front, or removed from the front (or anywhere before the middle) then the first node will not be completely populated, and the Xmethod will give the wrong result. libstdc++-v3/ChangeLog: PR libstdc++/112491 * python/libstdcxx/v6/xmethods.py (DequeWorkerBase.size): Fix calculation to use _M_start._M_cur. * testsuite/libstdc++-xmethods/deque.cc: Check failing cases. (cherry picked from commit 4db820928065eccbeb725406450d826186582b9f)
[Bug pch/47857] Pragma once warning when compiling PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Lewis Hyatt --- Fixed for GCC 14.
[Bug pch/9471] #pragma system_header vs. precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9471 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Lewis Hyatt --- Fixed for GCC 14.
[Bug pch/9471] #pragma system_header vs. precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9471 --- Comment #5 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:9938645fcf914ec2a3fa8137cf1456ad4af5f77c commit r14-5471-g9938645fcf914ec2a3fa8137cf1456ad4af5f77c Author: Lewis Hyatt Date: Fri Nov 10 11:10:18 2023 -0500 c-family: Let libcpp know when the compilation is for a PCH [PR9471] libcpp will generate diagnostics when it encounters things in the main file that only belong in a header file, such as `#pragma once' or `#pragma GCC system_header'. But sometimes the main file is a header file that is just being compiled separately, e.g. to produce a C++ module or a PCH, in which case such diagnostics should be suppressed. libcpp already has an interface to request that, so make use of it in the C frontends to prevent libcpp from issuing unwanted diagnostics when compiling a PCH. gcc/c-family/ChangeLog: PR pch/9471 PR pch/47857 * c-opts.cc (c_common_post_options): Set cpp_opts->main_search so libcpp knows it is compiling a header file separately. gcc/testsuite/ChangeLog: PR pch/9471 PR pch/47857 * g++.dg/pch/main-file-warnings.C: New test. * g++.dg/pch/main-file-warnings.Hs: New test. * gcc.dg/pch/main-file-warnings.c: New test. * gcc.dg/pch/main-file-warnings.hs: New test.
[Bug pch/47857] Pragma once warning when compiling PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857 --- Comment #10 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:9938645fcf914ec2a3fa8137cf1456ad4af5f77c commit r14-5471-g9938645fcf914ec2a3fa8137cf1456ad4af5f77c Author: Lewis Hyatt Date: Fri Nov 10 11:10:18 2023 -0500 c-family: Let libcpp know when the compilation is for a PCH [PR9471] libcpp will generate diagnostics when it encounters things in the main file that only belong in a header file, such as `#pragma once' or `#pragma GCC system_header'. But sometimes the main file is a header file that is just being compiled separately, e.g. to produce a C++ module or a PCH, in which case such diagnostics should be suppressed. libcpp already has an interface to request that, so make use of it in the C frontends to prevent libcpp from issuing unwanted diagnostics when compiling a PCH. gcc/c-family/ChangeLog: PR pch/9471 PR pch/47857 * c-opts.cc (c_common_post_options): Set cpp_opts->main_search so libcpp knows it is compiling a header file separately. gcc/testsuite/ChangeLog: PR pch/9471 PR pch/47857 * g++.dg/pch/main-file-warnings.C: New test. * g++.dg/pch/main-file-warnings.Hs: New test. * gcc.dg/pch/main-file-warnings.c: New test. * gcc.dg/pch/main-file-warnings.hs: New test.
[Bug libstdc++/112348] [C++23] defect in struct hash>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112348 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed for all branches, thanks for the report.
[Bug libstdc++/112348] [C++23] defect in struct hash>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112348 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a97c08ea530dadf366022b5c3e5aab21d34a61bd commit r12-9978-ga97c08ea530dadf366022b5c3e5aab21d34a61bd Author: Jonathan Wakely Date: Tue Nov 14 22:36:31 2023 + libstdc++: Fix std::hash [PR112348] libstdc++-v3/ChangeLog: PR libstdc++/112348 * include/std/stacktrace (hash>): Fix type of hash function for entries. * testsuite/19_diagnostics/stacktrace/hash.cc: New test. (cherry picked from commit 6f2fc42d9e52e8322e718e0154cd235d00906f99)
[Bug libstdc++/112491] std::deque::size xmethod output is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112491 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:99f992a275c30bc8db2e6352e98ab81c89b5b7ed commit r12-9977-g99f992a275c30bc8db2e6352e98ab81c89b5b7ed Author: Jonathan Wakely Date: Tue Nov 14 15:08:13 2023 + libstdc++: Fix std::deque::size() Xmethod [PR112491] The Xmethod for std::deque::size() assumed that the first element would be at the start of the first node. That's only true if elements are only added at the back. If an element is inserted at the front, or removed from the front (or anywhere before the middle) then the first node will not be completely populated, and the Xmethod will give the wrong result. libstdc++-v3/ChangeLog: PR libstdc++/112491 * python/libstdcxx/v6/xmethods.py (DequeWorkerBase.size): Fix calculation to use _M_start._M_cur. * testsuite/libstdc++-xmethods/deque.cc: Check failing cases. (cherry picked from commit 4db820928065eccbeb725406450d826186582b9f)
[Bug libstdc++/112348] [C++23] defect in struct hash>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112348 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:16635b89f36c07b9e06c48a93d1bfafa93178328 commit r13-8067-g16635b89f36c07b9e06c48a93d1bfafa93178328 Author: Jonathan Wakely Date: Tue Nov 14 22:36:31 2023 + libstdc++: Fix std::hash [PR112348] libstdc++-v3/ChangeLog: PR libstdc++/112348 * include/std/stacktrace (hash>): Fix type of hash function for entries. * testsuite/19_diagnostics/stacktrace/hash.cc: New test. (cherry picked from commit 6f2fc42d9e52e8322e718e0154cd235d00906f99)
[Bug libstdc++/112491] std::deque::size xmethod output is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112491 --- Comment #3 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5cb055e99d2026c734602ffdc28cb8b357a7b28e commit r13-8066-g5cb055e99d2026c734602ffdc28cb8b357a7b28e Author: Jonathan Wakely Date: Tue Nov 14 15:08:13 2023 + libstdc++: Fix std::deque::size() Xmethod [PR112491] The Xmethod for std::deque::size() assumed that the first element would be at the start of the first node. That's only true if elements are only added at the back. If an element is inserted at the front, or removed from the front (or anywhere before the middle) then the first node will not be completely populated, and the Xmethod will give the wrong result. libstdc++-v3/ChangeLog: PR libstdc++/112491 * python/libstdcxx/v6/xmethods.py (DequeWorkerBase.size): Fix calculation to use _M_start._M_cur. * testsuite/libstdc++-xmethods/deque.cc: Check failing cases. (cherry picked from commit 4db820928065eccbeb725406450d826186582b9f)
[Bug libstdc++/112348] [C++23] defect in struct hash>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112348 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6f2fc42d9e52e8322e718e0154cd235d00906f99 commit r14-5465-g6f2fc42d9e52e8322e718e0154cd235d00906f99 Author: Jonathan Wakely Date: Tue Nov 14 22:02:55 2023 + libstdc++: Fix std::hash [PR112348] libstdc++-v3/ChangeLog: PR libstdc++/112348 * include/std/stacktrace (hash>): Fix type of hash functio nfor entries. * testsuite/19_diagnostics/stacktrace/hash.cc: New test.
[Bug target/112447] risc-v regression: FAIL: gcc.c-torture/execute/memset-3.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447 --- Comment #12 from JuzheZhong --- The merge is correct here. vmv.x.s demand SEW = 32 wheras vle/vse demand RATIO = 16 (e8mf2) So, to make vsetvl valid for both of them, the vtype should be sew = 32 and lmul = M2 (32 / 16 = 2).
[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112531
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment #1 from JuzheZhong ---
This FAIL is reasonable. So we can ignore it.
The vectorized code will fail at this dump check like ARM SVE:
https://godbolt.org/z/dbsKb7bxY
Or you can fix testcase like AMDGCN:
disable vectorization:
/* { dg-additional-options "-fno-tree-vectorize" { target amdgcn-*-* } } */
[Bug libstdc++/112348] [C++23] defect in struct hash>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112348 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.4 Status|NEW |ASSIGNED --- Comment #2 from Jonathan Wakely --- (In reply to vincenzo Innocente from comment #0) > Surprised it passed tests. Tests can't fail if you don't write them guy-tapping-head.gif
[Bug modula2/111871] invoking gm2 with -pipe and -v does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111871 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-11-14 Ever confirmed|0 |1 --- Comment #1 from Gaius Mulley --- Conformed will fix!
[Bug modula2/111627] modula2: Excess test fails with a case-preserving-case-insensitive source tree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111627 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed|2023-09-28 00:00:00 |2023-11-14 --- Comment #1 from Gaius Mulley --- Thanks for the bug report - will fix!
[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #5) > We need to detect and diagnose violations of the above. Example: program main implicit none type t integer :: i end type t type(t), allocatable, target :: xa type(t), pointer :: xp class(t), allocatable, target :: ya class(t), pointer :: yp call foo_p (xp) ! Invalid call foo_p (xa) ! Invalid in F2008, valid in F2018 call foo_p (yp) ! Valid, OK call foo_p (ya) ! Valid, OK contains subroutine foo_p (x) class(t), pointer, intent(in) :: x end subroutine end The lines marked invalid are detected for -std=f2003, but not for >= f2008.
[Bug analyzer/103533] Enable "taint" state machine with -fanalyzer without requiring -fanalyzer-checker=taint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from David Malcolm --- I've enabled the taint state machine by default (with -fanalyzer) with the above patch, for GCC 14 onwards. PR analyzer/112528 tracks the only known state explosion; integration testing shows no significicant changes in results from -fanalyzer before/after the patch. Closing this bug out.
[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311 Edwin Lu changed: What|Removed |Added CC||ewlu at rivosinc dot com --- Comment #17 from Edwin Lu --- (In reply to Patrick O'Neill from comment #8) > === gcc: Unexpected fails for rv64gcv lp64d medlow === > FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, > doesn't roll" > FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6" > FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1" tracked in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112531
[Bug analyzer/103533] Enable "taint" state machine with -fanalyzer without requiring -fanalyzer-checker=taint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533 --- Comment #8 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:cfaaa8b11b8429eed5ec44426fc6a20ad5d53d30 commit r14-5464-gcfaaa8b11b8429eed5ec44426fc6a20ad5d53d30 Author: David Malcolm Date: Tue Nov 14 15:51:52 2023 -0500 analyzer: enable taint state machine by default [PR103533] gcc/analyzer/ChangeLog: PR analyzer/103533 * sm-taint.cc: Remove "experimental" from comment. * sm.cc (make_checkers): Always add taint state machine. gcc/ChangeLog: PR analyzer/103533 * doc/invoke.texi (Static Analyzer Options): Add the six -Wanalyzer-tainted-* warnings. Update documentation of each warning to reflect removed requirement to use -fanalyzer-checker=taint. Remove discussion of -fanalyzer-checker=taint. gcc/testsuite/ChangeLog: PR analyzer/103533 * c-c++-common/analyzer/attr-tainted_args-1.c: Remove use of -fanalyzer-checker=taint. * c-c++-common/analyzer/fread-1.c: Likewise. * c-c++-common/analyzer/pr104029.c: Likewise. * gcc.dg/analyzer/pr93032-mztools-signed-char.c: Add params to work around state explosion. * gcc.dg/analyzer/pr93032-mztools-unsigned-char.c: Likewise. * gcc.dg/analyzer/pr93382.c: Remove use of -fanalyzer-checker=taint. * gcc.dg/analyzer/switch-enum-taint-1.c: Likewise. * gcc.dg/analyzer/taint-CVE-2011-2210-1.c: Likewise. * gcc.dg/analyzer/taint-CVE-2020-13143-1.c: Likewise. * gcc.dg/analyzer/taint-CVE-2020-13143-2.c: Likewise. * gcc.dg/analyzer/taint-CVE-2020-13143.h: Likewise. * gcc.dg/analyzer/taint-alloc-1.c: Likewise. * gcc.dg/analyzer/taint-alloc-2.c: Likewise. * gcc.dg/analyzer/taint-alloc-3.c: Likewise. * gcc.dg/analyzer/taint-alloc-4.c: Likewise. * gcc.dg/analyzer/taint-alloc-5.c: Likewise. * gcc.dg/analyzer/taint-assert-BUG_ON.c: Likewise. * gcc.dg/analyzer/taint-assert-macro-expansion.c: Likewise. * gcc.dg/analyzer/taint-assert-system-header.c: Likewise. * gcc.dg/analyzer/taint-assert.c: Likewise. * gcc.dg/analyzer/taint-divisor-1.c: Likewise. * gcc.dg/analyzer/taint-divisor-2.c: Likewise. * gcc.dg/analyzer/taint-merger.c: Likewise. * gcc.dg/analyzer/taint-ops.c: Delete this test: it was a duplicate of material in operations.c and data-model-1.c, with -fanalyzer-checker=taint added. * gcc.dg/analyzer/taint-read-index-1.c: Remove use of -fanalyzer-checker=taint. * gcc.dg/analyzer/taint-read-offset-1.c: Likewise. * gcc.dg/analyzer/taint-realloc.c: Likewise. Add missing dg-warning for leak now that the malloc state machine is also active. * gcc.dg/analyzer/taint-size-1.c: Remove use of -fanalyzer-checker=taint. * gcc.dg/analyzer/taint-size-access-attr-1.c: Likewise. * gcc.dg/analyzer/taint-write-index-1.c: Likewise. * gcc.dg/analyzer/taint-write-offset-1.c: Likewise. * gcc.dg/analyzer/torture/taint-read-index-2.c: Likewise. * gcc.dg/analyzer/torture/taint-read-index-3.c: Likewise. * gcc.dg/plugin/taint-CVE-2011-0521-1-fixed.c: Likewise. Add -Wno-pedantic. * gcc.dg/plugin/taint-CVE-2011-0521-1.c: Likewise. * gcc.dg/plugin/taint-CVE-2011-0521-2-fixed.c: Likewise. * gcc.dg/plugin/taint-CVE-2011-0521-2.c: Likewise. * gcc.dg/plugin/taint-CVE-2011-0521-3-fixed.c: Likewise. * gcc.dg/plugin/taint-CVE-2011-0521-3.c: Likewise. Fix C++-style comment. * gcc.dg/plugin/taint-CVE-2011-0521-4.c: Remove use of -fanalyzer-checker=taint and add -Wno-pedantic. Remove xfail and add missing dg-warning. * gcc.dg/plugin/taint-CVE-2011-0521-5-fixed.c: Remove use of -fanalyzer-checker=taint and add -Wno-pedantic. * gcc.dg/plugin/taint-CVE-2011-0521-5.c: Likewise. * gcc.dg/plugin/taint-CVE-2011-0521-6.c: Likewise. * gcc.dg/plugin/taint-antipatterns-1.c: : Remove use of -fanalyzer-checker=taint. Signed-off-by: David Malcolm
[Bug tree-optimization/112533] missed optimization (~A & C) == (~B & C) => (A & C) == (B & C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112533 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-11-14 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- I think there is a dup.
[Bug tree-optimization/112533] New: missed optimization (~A & C) == (~B & C) => (A & C) == (B & C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112533
Bug ID: 112533
Summary: missed optimization (~A & C) == (~B & C) => (A & C) ==
(B & C)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
On this code
static bool is_even(unsigned a)
{
return a % 2 == 0;
}
bool same_evenness(unsigned a, unsigned b)
{
return is_even(a) == is_even(b);
}
GCC -02 currently produces
same_evenness:
notl%esi // (1)
notl%edi // (2)
andl$1, %esi
andl$1, %edi
cmpb%dil, %sil
sete%al
ret
The NOTs (1) and (2) are redundant. It would be great if GCC could optimize
them out.
[Bug target/112532] New: [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn: vec_duplicate:V4HI) with -O -msse4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112532 Bug ID: 112532 Summary: [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn: vec_duplicate:V4HI) with -O -msse4 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56586 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56586=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -msse4 testcase.c testcase.c: In function 'foo0': testcase.c:26:1: error: unrecognizable insn: 26 | } | ^ (insn 58 56 59 2 (set (reg:V4HI 20 xmm0 [129]) (vec_duplicate:V4HI (reg:HI 22 xmm2 [123]))) "testcase.c":16:21 -1 (nil)) during RTL pass: split2 testcase.c:26:1: internal compiler error: in extract_insn, at recog.cc:2804 0x7f5c79 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.cc:108 0x7f5cf6 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.cc:116 0x7e4b65 extract_insn(rtx_insn*) /repo/gcc-trunk/gcc/recog.cc:2804 0x14168c4 extract_insn_cached(rtx_insn*) /repo/gcc-trunk/gcc/recog.cc:2693 0x10af2a4 cleanup_subreg_operands(rtx_insn*) /repo/gcc-trunk/gcc/final.cc:3054 0x1414088 split_insn /repo/gcc-trunk/gcc/recog.cc:3419 0x141ad65 split_all_insns() /repo/gcc-trunk/gcc/recog.cc:3487 0x141ae88 execute /repo/gcc-trunk/gcc/recog.cc:4411 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5443-20231114122339-gb9fd8399ec0-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-5443-20231114122339-gb9fd8399ec0-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231114 (experimental) (GCC)
[Bug target/112447] risc-v regression: FAIL: gcc.c-torture/execute/memset-3.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #11 from Vineet Gupta ---
As a hack I commented out set_delete() to see what the extraneous vsetvli
would have been.
```
.L36:
# bb 3: start of outer loop: off 0
vsetvli zero,zero,e8,mf2,ta,ma # insn 2915
vse8.v v1,0(t3) # insn 2874, bb 3
vse8.v v1,0(t6)
vse8.v v1,0(s0)
...
# bb 181
addia4,a4,1
li a7,15
bne a4,a7,.L36 # insn 1082
# bb 182: start of outer loop: off 1
vsetvli zero,zero,e32,mf2,ta,ma# insn 2919
vmv.x.s a3,v1 # insn 1858
vsetvli zero,zero,e16,mf2,ta,ma
sw a3,8(sp)
vmv.x.s a3,v1
```
Essentially phase 2 is fusing vsetvl info for insn 2874 and insn 1858
But the fused info doesn't seem right.
vsetvli zero,zero,e32,m2,ta,ma
j .L36
Manually modifying it to orig value fixes the test.
vsetvli zero,zero,e8,mf2,ta,ma
j .L36
Phase 2 logs
```
Try lift up 1.
earliest:
Edge(bb 0 -> bb 2): n_bits = 13, set = {0 }
Edge(bb 62 -> bb 63): n_bits = 13, set = {4 }
Edge(bb 180 -> bb 181): n_bits = 13, set = {8 }
Edge(bb 181 -> bb 3): n_bits = 13, set = {2 }
Fuse curr info since prev info compatible with it:
prev_info: VALID (insn 1858, bb 181) <-- due to Edge(bb 181 -> bb
3)
Demand fields: demand_sew_only
SEW=32, VLMUL=mf2, RATIO=64, MAX_SEW=64
TAIL_POLICY=agnostic, MASK_POLICY=agnostic
AVL=(nil)
VL=(nil)
curr_info: VALID (insn 2874, bb 3)
Demand fields: demand_ratio_only demand_avl
SEW=8, VLMUL=mf2, RATIO=16, MAX_SEW=64
TAIL_POLICY=agnostic, MASK_POLICY=agnostic
AVL=(const_int 8 [0x8])
VL=(nil)
prev_info after fused: VALID (insn 1858, bb 181)
Demand fields: demand_sew_lmul demand_avl
SEW=32, VLMUL=m2, RATIO=16, MAX_SEW=64
TAIL_POLICY=agnostic, MASK_POLICY=agnostic
AVL=(const_int 8 [0x8])
VL=(nil)
```
This fuse in turn is happening from
DEF_SEW_LMUL_RULE (sew_only, ratio_only, sew_lmul,
next_ratio_valid_for_prev_sew_p, always_false,
modify_lmul_with_next_ratio)
I'm not really sure if the merge callback here is correct.
[Bug c++/103499] C++20 modules error: invalid use of non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103499 --- Comment #7 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:14979dd31c887ba5ba573f2cdb0647b37e09641a commit r14-5461-g14979dd31c887ba5ba573f2cdb0647b37e09641a Author: Nathaniel Shead Date: Tue Nov 14 11:26:03 2023 -0500 c++: Stream virtual dtor vtable indices Virtual cloned functions have distinct vtable indices, stream them explicitly. As such, this patch ensures that DECL_VINDEX is properly passed on for cloned functions as well to prevent this from causing issues. PR c++/103499 gcc/cp/ChangeLog: * module.cc (trees_out::decl_node): Write DECL_VINDEX for virtual clones. (trees_in::tree_node): Read DECL_VINDEX for virtual clones. gcc/testsuite/ChangeLog: * g++.dg/modules/pr103499_a.C: New test. * g++.dg/modules/pr103499_b.C: New test. Signed-off-by: Nathaniel Shead Signed-off-by: Nathan Sidwell
[Bug c++/106849] internal compiler error: tree check: expected none of template_decl, have template_decl in do_nonmember_using_decl, at cp/name-lookup.cc:4841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106849 --- Comment #4 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:5b9ecce87e8f315e2681743d75401991cdfefa71 commit r14-5460-g5b9ecce87e8f315e2681743d75401991cdfefa71 Author: Nathaniel Shead Date: Thu Nov 9 19:05:09 2023 -0500 c++: Fix exported using decls of templates We need to look at DECL_TEMPLATE_RESULT to get the module attachment. PR c++/106849 gcc/cp/ChangeLog: * name-lookup.cc (do_nonmember_using_decl): Handle TEMPLATE_DECLs when checking module attachment. gcc/testsuite/ChangeLog: * g++.dg/modules/using-9.C: New test. Signed-off-by: Nathaniel Shead Signed-off-by: Nathan Sidwell
[Bug target/112531] New: [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112531
Bug ID: 112531
Summary: [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors
with --param=riscv-autovec-preference=scalable
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ewlu at rivosinc dot com
Target Milestone: ---
As reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311#c8
The following errors are found on trunk
=== gcc: Unexpected fails for rv64gcv lp64d medlow ===
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't
roll"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"
I have bisected it down to this commit r14-701-gb75c9e10379 introducing the
errors.
I have isolated the cause to specifically the change in the expand pass by
running the testsuite with just the refactor (reverting the change to
autovec.md) and saw no change in testsuite results.
Compilation command:
./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/gcc.dg/unroll-8.c
-march=rv64gcv -mabi=lp64d -mcmodel=medlow -fdiagnostics-plain-output -O2
-fdump-rtl-loop2_unroll-details-blocks -funroll-loops -ffat-lto-objects -S -o
unroll-8.s --param=riscv-autovec-preference=scalable --fdump-rtl-all
--fdump-tree-all
Observations:
Adding the new define expand pattern changes unroll-8.s to output vector
instructions. Previously only scalar output was generated (previous commit:
r14-700-gaf595613acb.)
The first difference in dump file outputs occurs with the tree dump 172t.vect
where vector variables are added. This is confusing to me since I expected the
first change to be with the rtl expand pass. I believe this may be the cause of
the problem since the optimized tree dump has
# loop_len_16 = PHI <_31(4), _27(3)>
which affects the analysis of the operands in the loop2_unroll pass.
Analyzing operand (reg:DI 137 [ loop_len_16 ]) of insn (jump_insn 56 54 81 10
(set (pc)
(if_then_else (ne (reg:DI 137 [ loop_len_16 ])
(const_int 0 [0]))
(label_ref:DI 81)
(pc))) 242 {*branchdi}
(int_list:REG_BR_PROB 894784862 (nil))
-> 81)
Checking get reaching def
has more than one reaching def
not simple.
loop number: 1 Failed to analyze op0: (reg:DI 137 [ loop_len_16 ])
Loop 1 is not simple.
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/gcc.dg/unroll-8.c:8:9: note:
considering unrolling loop 1 at BB 6
;; Not unrolling loop, user didn't want it unrolled
starting the processing of deferred insns
loop_len_16 now has multiple reaching definitions since it is the output of a
phi function.
[Bug tree-optimization/112530] [14 Regression] New ICE in gimple->rtl expansion after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112530 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jeffrey A. Law --- Confirmed the patch for 112481 fixes this problem. *** This bug has been marked as a duplicate of bug 112481 ***
[Bug target/112481] [14 Regression] RISCV: ICE: Segmentation fault when compiling pr110817-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112481 --- Comment #14 from Jeffrey A. Law --- *** Bug 112530 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/112530] [14 Regression] New ICE in gimple->rtl expansion after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112530 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Does r14-5453-g948b8b6e0e50958ecf56d4d9fb7ac16f245d9cc3 fix this too? The RISCV backtrace and the alpha backtrace is the same for the same testcase too which is why I suspect the alpha issue is the same as the riscv one.
[Bug tree-optimization/112530] [14 Regression] New ICE in gimple->rtl expansion after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112530 --- Comment #1 from Andrew Pinski --- Does r14-5453-g948b8b6e0e50958ecf56d4d9fb7ac16f245d9cc3 fix this too?
[Bug tree-optimization/112530] New: [14 Regression] New ICE in gimple->rtl expansion after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112530 Bug ID: 112530 Summary: [14 Regression] New ICE in gimple->rtl expansion after recent change Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- This change: commit a5922427c29fad177251d89cc946d1c5bfc135eb Author: Andrew Stubbs Date: Fri Oct 20 16:26:51 2023 +0100 vect: Don't set excess bits in unform masks AVX ignores any excess bits in the mask (at least for vector sizes >=8), but AMD GCN magically uses a larger vector than was intended (the smaller sizes are "fake"), leading to wrong-code. This patch fixes amdgcn execution failures in gcc.dg/vect/pr81740-1.c, gfortran.dg/c-interop/contiguous-1.f90, gfortran.dg/c-interop/ff-descriptor-7.f90, and others. gcc/ChangeLog: * expr.cc (store_constructor): Add "and" operation to uniform mask generation. Causes regressions on the alpha port (these can be seen with a simple cross compiler, a full toolchain is not necessary): gcc.c-torture/execute/pr110817-3.c -O1 (test for excess errors) gcc.c-torture/execute/pr110817-3.c -O2 (test for excess errors) gcc.c-torture/execute/pr110817-3.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) gcc.c-torture/execute/pr110817-3.c -O3 -g (test for excess errors) gcc.c-torture/execute/pr110817-3.c -Os (test for excess errors) dump file: j.c.262r.expand j.c: In function ‘main’: j.c:10:28: internal compiler error: Segmentation fault 10 | volatile signed int t = x[0]; | ~^~~ 0x1510fc4 crash_signal /home/jlaw/test/gcc/gcc/toplev.cc:316 0x7fcfa388efcf ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0xf81369 emit_move_insn(rtx_def*, rtx_def*) /home/jlaw/test/gcc/gcc/expr.cc:4249 0xf8d86c store_constructor(tree_node*, rtx_def*, int, poly_int<1u, long>, bool) /home/jlaw/test/gcc/gcc/expr.cc:7494 0xf93de0 expand_constructor /home/jlaw/test/gcc/gcc/expr.cc:8970 0xf9de14 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /home/jlaw/test/gcc/gcc/expr.cc:11245 0xf93e9f expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /home/jlaw/test/gcc/gcc/expr.cc:9049 0xf9bd72 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /home/jlaw/test/gcc/gcc/expr.cc:10860 0xf93e9f expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /home/jlaw/test/gcc/gcc/expr.cc:9049 0xdc48ba expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier) /home/jlaw/test/gcc/gcc/expr.h:310 [ ... ]
