This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 05 Mar 2013 09:05:04 +0000
- Subject: [Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
- Auto-submitted: auto-generated
- References: <bug-56474-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> 2013-03-05 09:05:04 UTC ---
On Mon, 4 Mar 2013, ebotcazou at gcc dot gnu.org wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474
>
> --- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-03-04 16:18:21 UTC ---
> > So, can the Ada FE be changed to use that? Hacks like this belong with a
> > comment in the FE that needs them IMHO.
>
> The 2 other related hacks are in stor-layout.c line 2214 and 2236 though and
> there are a lot of calls to size_binop in the Ada front-end. IMO this one is
> really benign compared to the others.
Note the hacks all boil down to the fact that FEs use signed array
domains but unsigned sizetype TYPE_DOMAIN. The C and C++ FE were
adjusted to use (unsigned) [1, 0] for zero-sized arrays - I believe
the current hacks are all because of Ada (and yes, I invented them
to not need to fiddle with the Ada FE when removing TYPE_IS_SIZETYPE).
There is still the Ada FE bug I opened that shows that arrays
with [0, USIZETYPE_MAX] vs. [SSIZETYPE_MIN, SSIZETYPE_MAX] do not
work. Independent of any hacks to fix the current error to address
that you need to work to fix the signedness issue (which may of
course require middle-end adjustments).
If you don't want overflow you can as well re-set TREE_OVERFLOW
on the result ... (just to give another option).