This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array


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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]