[Bug c++/91270] New: ice during GIMPLE pass: dce

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91270

Bug ID: 91270
   Summary: ice during GIMPLE pass: dce
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ code:

class a {
public:
  ~a();
};
long b;
void c() {
  a *d = new a[b];
  delete[] d;
}

compiled with flag -O2 on recent gcc trunk, does this:

$ /home/dcb/gcc/results/bin/gcc -c -O2 bug538.cc
during GIMPLE pass: cddce
bug538.cc: In function ‘void c()’:
bug538.cc:9:1: internal compiler error: Segmentation fault
9 | }
  | ^
0xfbaf6f crash_signal
../../trunk/gcc/toplev.c:326
0x11c9455 verify_use
../../trunk/gcc/tree-ssa.c:884
0x11cd940 verify_ssa(bool, bool)
../../trunk/gcc/tree-ssa.c:1161
0xee3b05 execute_function_todo
../../trunk/gcc/passes.c:1970

The problem seems to exist between revisions 273750
and 273800.

[Bug c++/91270] ice during GIMPLE pass: dce

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91270

Marc Glisse  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Marc Glisse  ---
Does this patch fix it for you?
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01644.html

[Bug c++/91271] New: class template specialization on std::array failed

[zhangbonian17 at 163 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91271

Bug ID: 91271
   Summary: class template specialization on std::array failed
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhangbonian17 at 163 dot com
  Target Milestone: ---

This is the offending code. It compiles successfully on clang/msvc recent
versions.

#include 

template
struct debug_t;

template
struct A{
/*use the primary template will cause the error*/
static void _() {debug_t d;}
};

template
struct A>
{
static void _() {}
};

int main()
{
A>::_();
}

[Bug c++/91271] class template specialization on std::array failed

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91271

--- Comment #1 from Marc Glisse  ---
std::array uses size_t, not int, as second parameter. I didn't check what the
standard says about this.

[Bug middle-end/91242] ICE on aarch64 SVE tests - gcc.target/aarch64/sve/clastb_[146].c

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91242

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Mine.  The problem is with using the raw elt value to hash
wide ints.  build_poly_int_cst is hashing a "normal"
sign-extended wide_int, whereas ::hash is operating on the
INTEGER_CST representation, which for unsigned integers is
zero-extended instead.

[Bug target/88837] [SVE] Poor vector construction code in VL-specific mode

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88837

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Fixed in trunk.

[Bug target/88838] [SVE] Use 32-bit WHILELO in LP64 mode

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88838

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug target/88833] [SVE] Redundant moves for WHILELO-based loops

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88833

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug middle-end/91166] [SVE] Unfolded ZIPs of constants

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91166

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug middle-end/91272] New: [SVE] Use fully-masked loops for CLASTB reductions

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91272

Bug ID: 91272
   Summary: [SVE] Use fully-masked loops for CLASTB reductions
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

Tests like clastb_6.c show that we don't yet support CLASTB
reductions in fully-masked/predicated loops.  E.g.: the main
loop is:

.L3:
ld1wz1.s, p0/z, [x0, x2, lsl 2]
addpl   x1, x2, #2
incwx2
fcmlt   p1.s, p0/z, z1.s, z3.s
cmp w2, w3
clastb  s0, p1, s0, z1.s
bls .L3

This loop operates on full vectors only and relies on a scalar
loop to handle the rest.

We should instead support fully-masked loops by ANDing the
comparison result in a CLASTB reduction with the loop mask.
I think this means:

* making vectorizable_condition apply vect_get_loop_mask
  for reductions.  (There might be cases we want to do this
  for normal conditions as well as for reductions, but that's
  separate work).

* relaxing the LOOP_VINFO_CAN_FULLY_MASK_P handling in
  vectorizable_reduction to account for the above.

[Bug lto/91273] New: [7/8/9/10 Regression] ICE in warn_types_mismatch at ipa-devirt.c:995

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91273

Bug ID: 91273
   Summary: [7/8/9/10 Regression] ICE in warn_types_mismatch at
ipa-devirt.c:995
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I see following ICE from r224248:

$ cat 1.ii
cat 1.ii
extern "C" {
struct {
} ltregul_;
}

$ cat 2.F
common /ltregul/ zeroeps
end 

$ g++ 1.ii 2.F -flto -O2 
2.F:1:3: warning: type of ‘ltregul’ does not match original declaration
[-Wlto-type-mismatch]
1 |  common /ltregul/ zeroeps
  |   ^
lto1: internal compiler error: in warn_types_mismatch, at ipa-devirt.c:995
0x626616 warn_types_mismatch(tree_node*, tree_node*, unsigned int, unsigned
int)
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:995
0x7e536c lto_symtab_merge_decls_2
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:722
0x7e536c lto_symtab_merge_decls_1
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:861
0x7e536c lto_symtab_merge_decls()
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:887
0x7f0f28 read_cgraph_and_symbols(unsigned int, char const**)
/home/marxin/Programming/gcc/gcc/lto/lto-common.c:2839
0x7d7702 lto_main()
/home/marxin/Programming/gcc/gcc/lto/lto.c:616

[Bug lto/91273] [7/8/9/10 Regression] ICE in warn_types_mismatch at ipa-devirt.c:995

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91273

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-27
 CC||hubicka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0, 7.4.0, 8.3.0, 9.1.0

[Bug target/91274] New: vec_splat_[us]64 missing for ppc

[cand at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91274

Bug ID: 91274
   Summary: vec_splat_[us]64 missing for ppc
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cand at gmx dot com
  Target Milestone: ---
  Host: ppc64le
Target: ppc64le

The 64-bit vector splats for ppc are missing. They are there for s390, and
supported in the IBM compiler.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #112 from dave.anglin at bell dot net ---
Hi Cameron,

We have to fix bootstrap compiler so we have a working g++ with one only
(.weak) support.

I think the offset in the branch relocation possibly comes from the fact that
on ia64-hpux we need a
.type declaration for external references.  We have in pa64-hpux.h:

/* The type of external references must be set correctly for the
   dynamic loader to work correctly.  This is equivalent to the
   HP assembler's .IMPORT directive but relates more directly to
   ELF object file types.  */
#undef ASM_OUTPUT_EXTERNAL
#define ASM_OUTPUT_EXTERNAL(FILE, DECL, NAME)   \
  pa_hpux_asm_output_external ((FILE), (DECL), (NAME))
#define ASM_OUTPUT_EXTERNAL_REAL(FILE, DECL, NAME)  \
do {    \
  if (FUNCTION_NAME_P (NAME))   \
    ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "function"); \
  else  \
    ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "object");   \
  default_elf_asm_output_external (FILE, DECL, NAME);   \
} while (0)

I suspect the branch tried to call an "object" rather than a "function".

You can check whether functions have correct type using nm.

Unfortunately, the above won't work directly because of the function name
encoding
used on pa.  Maybe you can look at aCC to see the assembly output it generates
to a
call to a weak function.

I don't have time today to figure out the linkonce issue below.

On 2019-07-26 10:57 p.m., cameron.heide at betasystems dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #111 from C. Heide  ---
> (In reply to dave.anglin from comment #110)
>> Okay, this is problem linkonce sections.  I think we need to figure out why
>> ia64_hpux_function_section
>> isn't working.  Maybe try return text_section in ia64_hpux_function_section.
> I gave that a try (just "return text_section;" in there) but it looks like
> something is still generating linkonce sections:
> Output (during compile of eh_alloc.cc):
>> /var/tmp//ccOX5Jzg.s: Assembler messages:
>> /var/tmp//ccOX5Jzg.s:8406: Error: can't resolve `.text' {.text section} - 
>> `.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev' {*UND* section}
>> /var/tmp//ccOX5Jzg.s:8407: Error: can't resolve `.text' {.text section} - 
>> `.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev' {*UND* section}
>> /var/tmp//ccOX5Jzg.s:8411: Error: can't resolve `.text' {.text section} - 
>> `.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev' {*UND* section}
> Generated assembly:
>> .file   "eh_alloc.cc"
>> .pred.safe_across_calls p1-p5,p16-p63
>> .section.text,  "ax",   "progbits"
>> .Ltext0:
>> .section
>> .gnu.linkonce.r._ZNK9__gnu_cxx24__concurrence_lock_error4whatEv.str1.8,"aMS",@progbits,1
>> .align 8
>> .LC1:
>> stringz "__gnu_cxx::__concurrence_lock_error"
>> .section.text,  "ax",   "progbits"
>> .align 16
>> .weak   _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv#
>> .proc _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv#
>> _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv:
>> etc...
> though I think the error is referring specifically to these (debug?) entries
> later on:
>> .LLST0:
>> data4.ua
>> .LVL6-.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev#
>> data4.ua
>> .LVL7-.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev#
>> data2.ua0x2
>> data1   0x90

[Bug c++/85137] [concepts] ICE with undeclared concept

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85137

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

[Bug ada/91268] [10 Regression] adaint.c:38: warning: "_REENTRANT" redefined

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91268

--- Comment #1 from dave.anglin at bell dot net ---
Another new issue:

In file included from ../../gcc/gcc/ada/adadecode.c:35:
../../gcc/gcc/ada/adadecode.c: In function 'void __gnat_decode(const char*,
char
*, int)':
../../gcc/gcc/ada/adadecode.c:260:34: error: array subscript has type 'char'
[-Werror=char-subscripts]
  260 | while (ISDIGIT (ada_name[last]) && last > 0)
  | ~^
../../gcc/gcc/ada/adadecode.c:260:12: note: in expansion of macro 'ISDIGIT'
  260 | while (ISDIGIT (ada_name[last]) && last > 0)
  |    ^~~
cc1plus: all warnings being treated as errors
Makefile:1118: recipe for target 'ada/adadecode.o' failed

[Bug c++/91264] modifying const-qual object in constexpr context not detected

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91264

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-27
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/91275] New: __builtin_crypto_vpmsumd gives different results -O[123] vs -O0

[cand at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275

Bug ID: 91275
   Summary: __builtin_crypto_vpmsumd gives different results
-O[123] vs -O0
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cand at gmx dot com
  Target Milestone: ---
  Host: ppc64le
Target: ppc64le

C:
#include 
#include 

int main() {

const unsigned long long r0l = 0x8e7dfceac070e3a0;
vector unsigned long long r0 = (vector unsigned long long) {r0l, 0}, v;
const vector unsigned long long pd = (vector unsigned long) {0xc2LLU <<
56, 0};

v = __builtin_crypto_vpmsumd((vector unsigned long long) {r0[0], 0},
pd);

printf("Got  %016lx %016lx\n", v[0], v[1]);
printf("Expected %016lx %016lx\n", 0x4000,
0x65bd7ab605a4a8ff);

return 0;
}

$ gcc -o bug bug.c && ./bug
Got  4000 65bd7ab605a4a8ff
Expected 4000 65bd7ab605a4a8ff

$ gcc -o bug bug.c -O1 && ./bug
Got  65bd7ab605a4a8ff 4000
Expected 4000 65bd7ab605a4a8ff

--

Note that I'm not sure which is wrong, -O0 or -O1-3, but certainly one of them
is.

[Bug other/91276] New: Doc typos in __builtin_crypto_vpmsum*

[cand at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91276

Bug ID: 91276
   Summary: Doc typos in __builtin_crypto_vpmsum*
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cand at gmx dot com
  Target Milestone: ---
  Host: ppc64le
Target: ppc64le

On the "PowerPC AltiVec Built-in Functions Available on ISA 3.0" page, there
are typos in the crypto vpmsum functions. All of them end in "b", when only the
char version should end in b. The u64 version should end in "d", and so on.
Code is correct, only the docs are wrong.

[Bug c++/91277] New: est.cpp:5:55: internal compiler error: in synthesize_implicit_template_parm, at cp/parser.c:41206

[mr...@courier-mta.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91277

Bug ID: 91277
   Summary: est.cpp:5:55: internal compiler error: in
synthesize_implicit_template_parm, at
cp/parser.c:41206
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mr...@courier-mta.com
  Target Milestone: ---

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

Compiled with

g++ -std=c++17 test.cpp -fconcepts -g -v

Originally reported by
https://stackoverflow.com/questions/57233950/is-this-a-bug-about-the-concept-lib-in-c

[Bug c++/91270] ice during GIMPLE pass: dce

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91270

--- Comment #2 from David Binderman  ---
(In reply to Marc Glisse from comment #1)
> Does this patch fix it for you?
> https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01644.html

Sadly, no.

bug538.cc
script.cc: In member function ‘void CInputScript::ParseDefineFont()’:
script.cc:1117:6: error: missing definition
script.cc:1117:6: error: no immediate_use list
for SSA_NAME: _37 in statement:
# .MEM_95 = VDEF <.MEM_49>
operator delete [] (_69, _37);
during GIMPLE pass: dce
script.cc:1117:6: internal compiler error: verify_ssa failed
0x1075d8c verify_ssa(bool, bool)
../../trunk/gcc/tree-ssa.c:1208

I've done one pass of range reduction and 273775 seems fine,
so range is 273775 to 273800.

[Bug c++/91270] ice during GIMPLE pass: dce

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91270

--- Comment #3 from David Binderman  ---
273788 seems fine, so range is 273788 to 273800.

[Bug fortran/88227] ICE in gfc_convert_boz, at fortran/target-memory.c:788

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88227

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #8)
> (In reply to kargl from comment #7)
> > (In reply to Dominique d'Humieres from comment #6)
> > > The following test giveS ALSO an ICE with -m32
> > > 
> > > % cat boz_10.f90
> > > print *, real(b'1010101001101',10)
> > > end
> > > % gfortran -m32 boz_10.f90
> > > f951: internal compiler error: Segmentation fault: 11
> > > libbacktrace could not find executable to open
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See  for instructions.
> > 
> > I've thought about this, and think it can be fixed by
> > removing the use gfc_max_integer_kind variable.  Simply
> > convert the BOZ to an GMP mpz_t with a suitable width.
> > As I don't use multilib or the precision promoting
> > options I cannot test the change.
> 
> In gfortran's current manifestation, it is not possible
> to support BOZ conversion when someone uses a rather 
> poor combination of options.  The following patch prevents
> the ICE.
> 
> Index: check.c
> ===
> --- check.c   (revision 273766)
> +++ check.c   (working copy)
> @@ -108,9 +108,8 @@ is_boz_constant (gfc_expr *a)
>  bool
>  gfc_boz2real (gfc_expr *x, int kind)
>  {
> -  extern int gfc_max_integer_kind;
>gfc_typespec ts;
> -  int len;
> +  int i, len;
>char *buf, *str;
>  
>if (!is_boz_constant (x))
> @@ -165,6 +164,11 @@ gfc_boz2real (gfc_expr *x, int kind)
>x->boz.str = XCNEWVEC (char, len + 1);
>strncpy (x->boz.str, buf, len);
>  
> +  i = gfc_validate_kind (BT_REAL, kind, false);
> +  if (gfc_real_kinds[i].mode_precision > 8 * gfc_max_integer_kind)
> +gfc_fatal_error ("Insufficient INTEGER kind required "
> +  "in BOZ conversion at %L!", &x->where);
> +
>/* Convert to widest possible integer.  */
>gfc_boz2int (x, gfc_max_integer_kind);
>ts.type = BT_REAL;

So, I looked at this a little closer, and one does not need
to use any combination of options to invoke the ICE.  One 
simply needs a 32-bit target (e.g., i586-*-freebsd) target.
gfortran uses the largest possible INTEGER to encode a BOZ.
On i586-*-freebsd, this is INTEGER(8), a 64-bit entity.  On
this target, gfortran supports REAL(10) and REAL(16), which
are 80-bit and 128-bit entities.

I have a work in progress for converting a BOZ without the
INTEGER(8) intermediate step.

the BOZ conversion.

[Bug c++/91278] New: Array arithmetic yields "is not a constant expression" error

[arthur.j.odwyer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91278

Bug ID: 91278
   Summary: Array arithmetic yields "is not a constant expression"
error
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

Bug 77911 might be related, I'm not sure.

// https://godbolt.org/z/UUb7kW
constexpr bool test() { 
int i[2] {};
int j[2] {};
return i+0 == j+1;
}
constexpr bool x = test();


:5:16: error: '(((int*)(& i)) == (((int*)(& j)) + 4))' is not a
constant expression
5 | return i+0 == j+1;
  |^~


There are two issues here. One is that the error shouldn't be happening at all;
it's totally cromulent to compare i+0 (i.e. &i[0]) with j+1 (i.e. &j[1]). `x`
should be initialized to `false`.

The other issue is cosmetic: this error is apparently happening very late in
the compiler, so that `j+1` (i.e. &j[1]) ends up getting pretty-printed as
`(((int*)(& j)) + 4))` (i.e. &j[4]). Seems like the compiler is remembering
SOME of the type information about `j` but not ALL of the type information.

[Bug c/91279] New: [10 Regression] gcc ICE on invalid code on x86_64-linux-gnu in "linemap_ordinary_map_lookup"

[shuo.d at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91279

Bug ID: 91279
   Summary: [10 Regression] gcc ICE on invalid code on
x86_64-linux-gnu in "linemap_ordinary_map_lookup"
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shuo.d at outlook dot com
  Target Milestone: ---

The following invalid code causes an ICE when compiled with the current gcc
trunk on x86_64-linux-gnu. I think it's a problem with the C compiler front
end, but I'm not sure.

gcc-9 works fine, so it appears to be a 10 regression.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190727 (experimental) [trunk revision 273844] (GCC) 


$ gcc-trunk src.c 
src.c:1:35: error: expected expression before ‘a’
1 | typedef char a ; f ( ) [ * sizeof a ] { }
  |   ^
src.c:1:35: internal compiler error: in linemap_ordinary_map_lookup, at
libcpp/line-map.c:985
0x178b153 linemap_ordinary_map_lookup
../../gcc/libcpp/line-map.c:985
0x178b696 get_range_from_loc(line_maps*, unsigned int)
../../gcc/libcpp/line-map.c:284
0x178b696 get_range_from_loc(line_maps*, unsigned int)
../../gcc/libcpp/line-map.c:273
0x176d310 get_finish
../../gcc/gcc/input.h:163
0x176d310 make_location(unsigned int, unsigned int, unsigned int)
../../gcc/gcc/input.c:894
0x89104e c_parser_unary_expression
../../gcc/gcc/c/c-parser.c:7320
0x89255f c_parser_cast_expression
../../gcc/gcc/c/c-parser.c:7245
0x8927d6 c_parser_binary_expression
../../gcc/gcc/c/c-parser.c:7048
0x893825 c_parser_conditional_expression
../../gcc/gcc/c/c-parser.c:6782
0x893e60 c_parser_expr_no_commas
../../gcc/gcc/c/c-parser.c:6699
0x89050e c_parser_direct_declarator_inner
../../gcc/gcc/c/c-parser.c:3850
0x8a6eb5 c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.c:2004
0x8af54f c_parser_external_declaration
../../gcc/gcc/c/c-parser.c:1658
0x8aff71 c_parser_translation_unit
../../gcc/gcc/c/c-parser.c:1539
0x8aff71 c_parse_file()
../../gcc/gcc/c/c-parser.c:20147
0x905f5b c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1160
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.



$ cat src.c 
typedef char a ; f ( ) [ * sizeof a ] { }

[Bug tree-optimization/91280] New: [8/9/10 Regression] ICE in get_constraint_for_component_ref, at tree-ssa-structalias.c:3259 since r260354

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91280

Bug ID: 91280
   Summary: [8/9/10 Regression] ICE in
get_constraint_for_component_ref, at
tree-ssa-structalias.c:3259 since r260354
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46632&action=edit
test-case

Following test-case causes ICE:

$ gcc-9 -O2 batch.ii -c
batch.ii: In lambda function:
batch.ii:246:54: warning: no return statement in function returning non-void
[-Wreturn-type]
  246 | I registrar__body__1__object([](int *) -> A * { K(); });
  |  ^
during GIMPLE pass: alias
batch.ii: In constructor ‘K::K()’:
batch.ii:233:3: internal compiler error: in get_constraint_for_component_ref,
at tree-ssa-structalias.c:3259
  233 |   K() : A(&BatchMatMul_context) {
  |   ^
0x7f34ecbccbca __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/91280] [8/9/10 Regression] ICE in get_constraint_for_component_ref, at tree-ssa-structalias.c:3259 since r260354

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91280

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-28
  Known to work||8.3.0
 Ever confirmed|0   |1
  Known to fail||10.0, 9.1.0