[Bug c/114971] New: gcc-14.1.0, ICE in get_alias_set, at alias.cc:954

2024-05-07 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971

Bug ID: 114971
   Summary: gcc-14.1.0, ICE in get_alias_set, at alias.cc:954
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sezeroz at gmail dot com
  Target Milestone: ---

Created attachment 58115
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58115&action=edit
-freport-bug output

Output from -freport-bug attached.

[Bug c/114971] gcc-14.1.0, ICE in get_alias_set, at alias.cc:954

2024-05-07 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971

--- Comment #1 from Ozkan Sezer  ---
Created attachment 58116
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58116&action=edit
-freport-bug output from another ICE

Attached a -freport-bug output from another source ICE'ing at the same place

[Bug c/114971] gcc-14.1.0, ICE in get_alias_set, at alias.cc:954

2024-05-07 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971

--- Comment #3 from Ozkan Sezer  ---
Created attachment 58117
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58117&action=edit
output from a third ICE at the same place

[Bug c/114971] gcc-14.1.0, ICE in get_alias_set, at alias.cc:954

2024-05-07 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971

--- Comment #4 from Ozkan Sezer  ---
Created attachment 58118
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58118&action=edit
output from a fourth ICE at the same place

[Bug c/114971] gcc-14.1.0, ICE in get_alias_set, at alias.cc:954

2024-05-07 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971

--- Comment #5 from Ozkan Sezer  ---
(In reply to Richard Biener from comment #2)
> likely a duplicate of PR114931

I guess -std=gnu23 is the key, then yes, likely a dup.

Waiting for a resolution.

[Bug c/114973] New: 14.1.0 - internal compiler error: 'verify_type' failed

2024-05-07 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114973

Bug ID: 114973
   Summary: 14.1.0 - internal compiler error: 'verify_type' failed
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sezeroz at gmail dot com
  Target Milestone: ---

Created attachment 58119
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58119&action=edit
preprocessed source

Happens while compiling mikmod player source with -std=gnu23:


gcc -DHAVE_CONFIG_H -I. -I.. -I/home/ozzie/x1/include -pthread -D_REENTRANT -g
-O2 -freport-bug -Wall -D_REENTRANT -std=gnu23 -MT display.o -MD -MP -MF
.deps/display.Tpo -c -o display.o display.c

In file included from display.c:49:
mwindow.h:70:1: error: 'TYPE_CANONICAL' has different 'TYPE_CANONICAL'
   70 | typedef void (*WinResizeFunc) (MWINDOW *win, int dx, int dy);
  | ^~~
 >
asm_written QI
size  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:1980680544 alias-set -1
structural-equality
arg-types 
asm_written unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:1980679904 alias-set -1
canonical-type 0x7f15760ea738>
chain 
chain 
chain 
pointer_to_this >
 >
QI
size  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f15760eaa80
arg-types 
asm_written unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:1980681664 alias-set -1
canonical-type 0x7f15760ea738>
chain 
chain 
chain 
pointer_to_this >
mwindow.h:70:1: internal compiler error: 'verify_type' failed
0x13774de verify_type(tree_node const*)
../../gcc-14.1.0/gcc/tree.cc:14395
0xbaf894 gen_type_die_with_usage
../../gcc-14.1.0/gcc/dwarf2out.cc:26287
0xbb1d77 gen_type_die
../../gcc-14.1.0/gcc/dwarf2out.cc:26518
0xbb1d77 modified_type_die
../../gcc-14.1.0/gcc/dwarf2out.cc:14000
0xbb1a85 modified_type_die
../../gcc-14.1.0/gcc/dwarf2out.cc:14077
0xbb3406 add_type_attribute
../../gcc-14.1.0/gcc/dwarf2out.cc:22397
0xbad08e gen_typedef_die
../../gcc-14.1.0/gcc/dwarf2out.cc:26193
0xbad08e gen_typedef_die
../../gcc-14.1.0/gcc/dwarf2out.cc:26127
0xbad08e gen_decl_die
../../gcc-14.1.0/gcc/dwarf2out.cc:27161
0xbad8db dwarf2out_decl
../../gcc-14.1.0/gcc/dwarf2out.cc:27716
0xbadb38 dwarf2out_type_decl
../../gcc-14.1.0/gcc/dwarf2out.cc:27434
0xbadb38 dwarf2out_type_decl
../../gcc-14.1.0/gcc/dwarf2out.cc:27429
0xf0e03b rest_of_decl_compilation(tree_node*, int, int)
../../gcc-14.1.0/gcc/passes.cc:251
0x975976 finish_decl(tree_node*, unsigned int, tree_node*, tree_node*,
tree_node*)
../../gcc-14.1.0/gcc/c/c-decl.cc:6056
0x9e3242 c_parser_declaration_or_fndef
../../gcc-14.1.0/gcc/c/c-parser.cc:2841
0x9eeb5b c_parser_external_declaration
../../gcc-14.1.0/gcc/c/c-parser.cc:2046
0x9ef545 c_parser_translation_unit
../../gcc-14.1.0/gcc/c/c-parser.cc:1900
0x9ef545 c_parse_file()
../../gcc-14.1.0/gcc/c/c-parser.cc:26889
0xa66aa1 c_common_parse_file()
../../gcc-14.1.0/gcc/c-family/c-opts.cc:1311
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.

Attaching preprocessed source (along with the stderr
output, because the above is likely mangled.)

[Bug c/114973] 14.1.0 - internal compiler error: 'verify_type' failed

2024-05-07 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114973

--- Comment #1 from Ozkan Sezer  ---
Created attachment 58120
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58120&action=edit
stderr output

[Bug c/114973] 14.1.0 - internal compiler error: 'verify_type' failed

2024-05-07 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114973

--- Comment #3 from Ozkan Sezer  ---
(In reply to Richard Biener from comment #2)
> This a different incarnation of PR114931, fixed on trunk as well already (I
> just checked).
> 
> *** This bug has been marked as a duplicate of bug 114931 ***

Is there a backport of the patch to gcc14 so that I can try?

[Bug c/114971] gcc-14.1.0, ICE in get_alias_set, at alias.cc:954

2024-05-07 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971

--- Comment #7 from Ozkan Sezer  ---
(In reply to Sam James from comment #6)
> Please check if trunk works, as a fix for that PR was committed not long ago.

Confirmed that trunk has it fixed.

Fix hopefully gets backported soon.

[Bug c/114973] 14.1.0 - internal compiler error: 'verify_type' failed

2024-05-07 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114973

--- Comment #4 from Ozkan Sezer  ---
(In reply to Richard Biener from comment #2)
> This a different incarnation of PR114931, fixed on trunk as well already (I
> just checked).
> 
> *** This bug has been marked as a duplicate of bug 114931 ***

Confirmed that trunk has it fixed.

Fix hopefully gets backported soon.

[Bug c/115005] New: [gcc-13] bogus -Warray-bounds warning

2024-05-09 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115005

Bug ID: 115005
   Summary: [gcc-13] bogus -Warray-bounds warning
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sezeroz at gmail dot com
  Target Milestone: ---

Created attachment 58144
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58144&action=edit
reduced C source exhibiting the issue

The attached C source emits bogus -Warray-bounds warnings at -O2 and -O3
(tested on i686 and x86_64):

$ gcc13 -c -O2 -Wall mmcmp-small.c

In function 'block_unpack_8bit',
inlined from 'decrunch_mmcmp' at mmcmp-small.c:231:4:
mmcmp-small.c:155:35: warning: array subscript 4294967295 is above array bounds
of 'const uint32[8]' {aka 'const unsigned int[8]'} [-Warray-bounds=]
  155 | if (d >= cmd_8bits[numbits]) {
  |  ~^
mmcmp-small.c: In function 'decrunch_mmcmp':
mmcmp-small.c:39:21: note: while referencing 'cmd_8bits'
   39 | extern const uint32 cmd_8bits[8];
  | ^
In function 'block_unpack_16bit',
inlined from 'decrunch_mmcmp' at mmcmp-small.c:229:4:
mmcmp-small.c:90:35: warning: array subscript 4294967295 is above array bounds
of 'const uint32[16]' {aka 'const unsigned int[16]'} [-Warray-bounds=]
   90 | if (d >= cmd_16bit[numbits]) {
  |  ~^
mmcmp-small.c: In function 'decrunch_mmcmp':
mmcmp-small.c:41:21: note: while referencing 'cmd_16bit'
   41 | extern const uint32 cmd_16bit[16];
  | ^

The original file in question is at
https://github.com/libxmp/libxmp/blob/master/src/depackers/mmcmp.c
I removed as much clutter as I could, but you guys would most probably reduce
it more.
The issue was originally discussed at libxmp:
https://github.com/libxmp/libxmp/issues/667
Notes particularly at
https://github.com/libxmp/libxmp/issues/667#issuecomment-1712584590

The warnings go away if numbits is changed from uint32 to uint8 or uint16: 
We had changed it to uint8 as a solution.

[Bug c/115005] [gcc-13] bogus -Warray-bounds warning

2024-05-09 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115005

--- Comment #1 from Ozkan Sezer  ---
Created attachment 58145
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58145&action=edit
preprocessed original source

[Bug tree-optimization/115005] [gcc-13] bogus -Warray-bounds warning

2024-05-09 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115005

--- Comment #3 from Ozkan Sezer  ---
> There is a jump threading there handling n==0 (aka numbits==-1u) and that is
> causing the warning.

The thing is, n==0 is not guarding against numbits==-1u: it is guarding
against 0 members of fetch_16bit[] (and fetch_8bit[]) arrays. As far as
I can see, that's where gcc13 is confused, no?

> Now if I understand it numbits can't be more than 128
> (or even 16 in the 16bit case).

Indeed: 15 is the upper limit in 16 bit case, and 7 in 8 bits case.

[Bug tree-optimization/115005] [gcc-13] bogus -Warray-bounds warning

2024-05-09 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115005

--- Comment #4 from Ozkan Sezer  ---
(In reply to Ozkan Sezer from comment #3)
> > There is a jump threading there handling n==0 (aka numbits==-1u) and that is
> > causing the warning.
> 
> The thing is, n==0 is not guarding against numbits==-1u: it is guarding
> against 0 members of fetch_16bit[] (and fetch_8bit[]) arrays. As far as
> I can see, that's where gcc13 is confused, no?

Hm, it seems I had replaced those fetch arrays in mmcmp-small.c
adding them back and re-uploading so the issue is better visible.

[Bug tree-optimization/115005] [gcc-13] bogus -Warray-bounds warning

2024-05-09 Thread sezeroz at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115005

Ozkan Sezer  changed:

   What|Removed |Added

  Attachment #58144|0   |1
is obsolete||

--- Comment #5 from Ozkan Sezer  ---
Created attachment 58156
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58156&action=edit
reduced C source exhibiting the issue