Skip to content

ICE on invalid array with size determined by sizeof incomplete type #1227

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
nlewycky opened this issue Jul 30, 2006 · 15 comments
Closed

ICE on invalid array with size determined by sizeof incomplete type #1227

nlewycky opened this issue Jul 30, 2006 · 15 comments
Assignees
@isanbard
Labels
bugzilla Issues migrated from bugzilla crash-on-invalid llvm-tools All llvm tools that do not have corresponding tag

Comments

@nlewycky
Copy link
Contributor

Bugzilla Link 855
Resolution FIXED
Resolved on Mar 06, 2010 14:00
Version trunk
OS Linux
CC @lattner

Extended Description

$ llvm-gcc 025.c -c -o 025
025.c:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct
poll_table_entry’
025.c:1: warning: division by zero
025.c:1: error: array type has incomplete element type
025.c:1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in grokdeclarator, at c-decl.c:4356
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://llvm.org/bugs for instructions.
$ cat 025.c
struct poll_table_entry inline_entries[((832 - 256) / sizeof(struct
poll_table_entry))];
$
@nlewycky
Copy link
Contributor Author

assigned to @isanbard

@isanbard
Copy link
Contributor

Hi Nick,

Which version of llvm-gcc are you using? It doesn't ICE on this version:

[Gaz:llvm] llvm-gcc --version
llvm-gcc (GCC) 3.4-llvm 20051104 (LLVM 1.7cvs)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

@nlewycky
Copy link
Contributor Author

$ llvm-gcc --version
llvm-gcc (GCC) 4.0.1 LLVM (Apple Computer, Inc. build 5400)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Latest out of the subversion repository last night.

@lattner
Copy link
Collaborator

lattner commented Jul 31, 2006

I'll take a look tomorrow unless someone beats me to it.

@lattner
Copy link
Collaborator

lattner commented Jul 31, 2006

This appears to be a problem with the generic GCC code llvm-gcc is based on.

@isanbard
Copy link
Contributor

Merged some code from mainline GCC to c-decl.c. Essentially, if there is an array with an incomplete type,
it sets the type to an error type. But then we were trying to do things with that type.

Submitted a fix for this to the llvmdev mailing list.

@isanbard
Copy link
Contributor

A quick test with the gcc 4.0.1 compiler on a Mac Intel machine (without the apple local patches) and it
doesn't ICE.

@nlewycky
Copy link
Contributor Author

I can verify that this patch works on my x86-linux build, and still passes
dejagnu's frontend tests. The patch itself looks minimal to me (though I'm no
gcc hacker).

I think it should be applied. Chris?

@isanbard
Copy link
Contributor

Mystery Of The Kind-of Working Compiler!

Here's what's happening. In LLVM's GCC, the crashing line resolves to this after preprocessing:

if (size_varies)
(extension ({ const tree __t = (type); if (tree_code_type[(int) (((enum tree_code) (__t)-

common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "../../llvm-
gcc4/gcc/c-decl.c", 4358, FUNCTION); __t; })->type.lang_flag_1) = 1;

With TOT in positron, it comes out as:

if (size_varies)
((type)->type.lang_flag_1) = 1;

So, basically, when tree checking is enabled, we get the ICE. Otherwise, it goes away.

@lattner
Copy link
Collaborator

lattner commented Sep 22, 2006

Ahh, so this fails with a non-llvm checking-enabled positron compiler as well?

-Chris

@isanbard
Copy link
Contributor

That's my next check. :-) I'll generate the new compiler now and make sure that the failure's there too.

@isanbard
Copy link
Contributor

Holy crap! When "--enable-checking" is used during configuration with non-LLVM gcc, we get the same
ICE.

Hott!

I'll submit the patch.

@lattner
Copy link
Collaborator

lattner commented Sep 22, 2006

Whoa, that even makes sense! :)

Thanks Bill,

-Chris

@isanbard
Copy link
Contributor

Fixed:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060918/038091.html

Also patched llvm-gcc.

@lattner
Copy link
Collaborator

lattner commented Sep 22, 2006

Thanks Bill!

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
jeanPerier pushed a commit to jeanPerier/llvm-project that referenced this issue Jan 4, 2022
@schweitzpgi
Refactor component handling and generate shape information earlier. (l…

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode
8c0a31c 
…lvm#1227)

* Refactor component handling and generate shape information earlier.

This merges all component handling back to a common path. Arrays, WHERE
constructs, and FORALL constructs all share the share common code to
derive the component path and any implicit iteration space shape
information. This refactoring causes generated code to appear in a
different order, so many tests were updated to reflect the changes. The
forall tests were split into individual tests.

  - Adds a component path collector to manage gathering and using a path
    of components.
  - Eliminates passing context information by this pointer, which
    fixes some bugs.
  - Fixes an off-by-one correctness bug.
  - Fixes some bugs with malformed iteration spaces, which resulted
    in assertion failures.
  - Fixes d7b abd d7c.

The todos left over:

  - Does not correctly deal with stemming the array properties relative
    to a path. This is a long standing issue with some hacks like
    componentToExtendedValue() that need to be replaced. This is related
    to the inability to handle component lower bounds, properly thread
    type parameters, etc.
  - There is still old prototype code to be removed.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@isanbard isanbard

Labels
bugzilla Issues migrated from bugzilla crash-on-invalid llvm-tools All llvm tools that do not have corresponding tag
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nlewycky @isanbard @lattner